idnits 2.17.1 draft-ietf-calext-caldav-attachments-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1178 -- Looks like a reference, but probably isn't: '2' on line 1180 -- Looks like a reference, but probably isn't: '3' on line 1182 -- Looks like a reference, but probably isn't: '4' on line 1184 -- Looks like a reference, but probably isn't: '5' on line 1186 -- Looks like a reference, but probably isn't: '6' on line 1188 -- Looks like a reference, but probably isn't: '7' on line 1190 -- Looks like a reference, but probably isn't: '8' on line 1192 -- Looks like a reference, but probably isn't: '9' on line 1194 -- Looks like a reference, but probably isn't: '10' on line 1196 ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendering Extensions C. Daboo 3 Internet-Draft Apple 4 Intended status: Standards Track A. Quillaud 5 Expires: September 14, 2017 Oracle 6 K. Murchison, Ed. 7 CMU 8 March 13, 2017 10 CalDAV Managed Attachments 11 draft-ietf-calext-caldav-attachments-02 13 Abstract 15 This specification defines an extension to the calendar access 16 protocol (CalDAV) to allow attachments associated with iCalendar data 17 to be stored and managed on the server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 14, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Discovering Support for Managed Attachments . . . . . . . 4 58 3.3. POST Request for Managing Attachments . . . . . . . . . . 4 59 3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6 60 3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9 61 3.6. Removing Attachments via POST . . . . . . . . . . . . . . 11 62 3.7. Adding Existing Managed Attachments via PUT . . . . . . . 13 63 3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 13 64 3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14 65 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14 66 3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 67 3.12. Additional Considerations . . . . . . . . . . . . . . . . 15 68 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16 69 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16 70 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 17 71 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17 72 5. Additional Message Header Fields . . . . . . . . . . . . . . 18 73 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 18 74 6. Additional WebDAV properties . . . . . . . . . . . . . . . . 18 75 6.1. CALDAV:managed-attachments-server-URL property . . . . . 18 76 6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 19 77 6.3. CALDAV:max-attachments-per-resource property . . . . . . 20 78 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 81 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 23 82 9.2. Message Header Field Registrations . . . . . . . . . . . 24 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 86 11.2. Informative References . . . . . . . . . . . . . . . . . 25 87 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Appendix A. Change History (To be removed by RFC Editor before 89 publication) . . . . . . . . . . . . . . . . . . . . 26 90 Appendix B. Example Involving Recurring Events . . . . . . . . . 28 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 The iCalendar [RFC5545] data format is used to represent calendar 96 data and is used with iTIP [RFC5546] to handle scheduling operations 97 between calendar users. 99 [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP 100 [RFC7230], for accessing calendar data stored on a server. 102 Calendar users often want to include attachments with their calendar 103 data events or tasks (for example a copy of a presentation, or the 104 meeting agenda). iCalendar provides an "ATTACH" property whose value 105 is either the inline Base64 encoded attachment data, or a URL 106 specifying the location of the attachment data. 108 Use of inline attachment data is not ideal with CalDAV because the 109 data would need to be uploaded to the server each time a change to 110 the calendar data is done - even minor changes such as a change to 111 the summary. Whilst a client could choose to use a URL value 112 instead, the problem then becomes where and how the client discovers 113 an appropriate URL to use and how it ensures that only those 114 attendees listed in the event or task are able to access it. 116 This specification solves this problem by having the client send the 117 attachment to the server, separately from the iCalendar data, and the 118 server takes care of adding appropriate "ATTACH" properties in the 119 iCalendar data as well as managing access privileges . The server can 120 also provide additional information to the client about each 121 attachment in the iCalendar data, such as the size and an identifier. 123 2. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 The notation used in this memo is the ABNF notation of [RFC5234] as 131 used by iCalendar [RFC5545]. Any syntax elements shown below that 132 are not explicitly defined in this specification come from iCalendar 133 [RFC5545]. 135 3. Overview 137 There are four main operations a client needs to do with attachments 138 for calendar data: add, update, remove, and retrieve. The first 139 three operations are carried out by the client issuing an HTTP POST 140 request on the calendar object resource to which the attachment is 141 associated and specifying the appropriate "action" query parameter. 142 In the case of the remove operation, the client can alternatively 143 directly update the calendar object resource and remove the relevant 144 "ATTACH" properties. The retrieve operation is accomplished by 145 simply issuing an HTTP GET request targeting the attachment URI 146 specified by the calendar resource's "ATTACH" property. 148 iCalendar data stored in a CalDAV calendar object resource can 149 contain multiple components when recurrences are involved. In such a 150 situation, the client needs to be able to target a specific 151 recurrence instance or multiple instances when adding or deleting 152 attachments. As a result, the POST request needs to provide a way 153 for the client to specify which recurrence instances should be 154 targeted for the attachment operation. This is accomplished through 155 use of additional query parameters on the POST request-URI. 157 3.1. Requirements 159 A server that supports the features described in this specification 160 is REQUIRED to support the CalDAV "calendar-access" [RFC4791] 161 features. 163 In addition, such a server MUST support the "return=representation" 164 Prefer header field value [RFC7240] on successful HTTP PUT and POST 165 requests targeting existing calendar object resources, by returning 166 the new representation of that calendar resource (including its new 167 ETag header field value) in the response. 169 3.2. Discovering Support for Managed Attachments 171 A server supporting the features described in this specification MUST 172 include "calendar-managed-attachments" as a field in the DAV response 173 header field from an OPTIONS request on a calendar home collection. 175 A server might choose to not support storing managed attachments on a 176 per-recurrence instance basis (i.e., they can only be added to all 177 instances as a whole). If that is the case, the server MUST include 178 "calendar-managed-attachments-no-recurrence" as a field in the DAV 179 response header field from an OPTIONS request on a calendar home 180 collection. When that field is present, clients MUST NOT attempt any 181 managed attachment operations that target specific recurrence 182 instances. 184 3.3. POST Request for Managing Attachments 186 An HTTP POST request is used to add, update, or remove attachments. 187 The request-URI will contain various query parameters to specify the 188 behavior. 190 3.3.1. action= Query Parameter 192 The "action" query parameter is used to identify which attachment 193 operation the client is requesting. This parameter MUST be present 194 once on each POST request used to manage attachments. One of these 195 three values MUST be used: 197 attachment-add Indicates an operation that is adding an attachment 198 to a calendar object resource. See Section 3.4 for more details. 200 attachment-update Indicates an operation that is updating an 201 existing attachment on a calendar object resource. See 202 Section 3.5 for more details. 204 attachment-remove Indicates an operation that is removing an 205 attachment from a calendar object resource. See Section 3.6 for 206 more details. 208 Example: 210 http://calendar.example.com/events/1.ics?action=attachment-add 212 3.3.2. rid= Query Parameter 214 The "rid" query parameter is used to identify which recurrence 215 instances are being targeted by the client for the attachment 216 operation. This query parameter MUST contain one or more items, 217 separated by commas (0x2C). The item values can be in one of two 218 forms: 220 Master instance The value "M" (case-insensitive) refers to the 221 "master" recurrence instance, i.e., the component that does not 222 include a "RECURRENCE-ID" property. This item MUST be present 223 only once. 225 Specific instance A specific iCalendar instance is targeted by using 226 its "RECURRENCE-ID" value as the item value. That value MUST 227 correspond to the RECURRENCE-ID value as stored in the calendar 228 object resource (i.e. without any conversion to UTC). If multiple 229 items of this form are used, they MUST be unique values. 231 If the "rid" query parameter is not present, all recurrence instances 232 in the calendar object resource are targeted. 234 The "rid" query parameter MUST NOT be present in the case of an 235 update operation, or if the server chooses not to support per- 236 recurrence instance managed attachments (see Section 3.1). 238 Example: 240 http://calendar.example.com/events/1.ics? 241 action=attachment-add&rid=M,20111022T160000 243 3.3.3. managed-id= Query Parameter 245 The "managed-id" query parameter is used to identify which "ATTACH" 246 property is being updated or removed. The value of this query 247 parameter MUST match the "MANAGED-ID" property parameter value on the 248 "ATTACH" property in the calendar object resource instance(s) 249 targeted by the request. 251 The "managed-id" query parameter MUST NOT be present in the case of 252 an add operation. 254 Example: 256 http://calendar.example.com/events/1.ics? 257 action=attachment-update&managed-id=aUNhbGVuZGFy 259 3.4. Adding attachments 261 To add an attachment to an existing calendar object resource, the 262 following occurs: 264 1. The client issues a POST request targeted at the calendar object 265 resource. 267 A. The request-URI will include an "action" query parameter with 268 the value "attachment-add" (see Section 3.3.1). 270 B. If all recurrence instances are having an attachment added, 271 the "rid" query parameter is not present in the request-URI. 272 If one or more specific recurrence instances are targeted, 273 then the request-URI will include a "rid" query parameter 274 containing the list of instances (see Section 3.3.2). 276 C. The body of the request contains the data for the attachment. 278 D. The client MUST include a valid Content-Type header field 279 describing the media type of the attachment (as required by 280 HTTP). 282 E. The client SHOULD include a Content-Disposition header field 283 [RFC6266] with a "type" parameter set to "attachment", and a 284 "filename" parameter that indicates the name of the 285 attachment. 287 F. The client MAY include a Prefer header field [RFC7240] with 288 the "return=representation" preference to request that the 289 modified calendar object resource be returned as the body of 290 a successful response to the POST request. 292 2. When the server receives the POST request it does the following: 294 A. Validates that any recurrence instances referred to via the 295 "rid" query parameter are valid for the calendar object 296 resource being targeted. 298 B. Stores the supplied attachment data into a resource and 299 generates an appropriate URI for clients to access the 300 resource. 302 C. For each affected recurrence instance in the calendar object 303 resource targeted by the request, the server adds an "ATTACH" 304 property, whose value is the URI of the stored attachment. 305 The "ATTACH" property MUST contain a "MANAGED-ID" parameter 306 whose value is a unique identifier (within the context of the 307 server as a whole). The "ATTACH" property SHOULD contain an 308 "FMTTYPE" parameter whose value matches the Content-Type 309 header field value from the request. The "ATTACH" property 310 SHOULD contain an "FILENAME" parameter whose value matches 311 the Content-Disposition header field "filename" parameter 312 value from the request, taking into account the restrictions 313 expressed in Section 4.2. The "ATTACH" property SHOULD 314 include a "SIZE" parameter whose value represents the size in 315 octets of the attachment. If a specified recurrence instance 316 does not have a matching component in the calendar object 317 resource, then the server MUST modify the calendar object 318 resource to include an overridden component with the 319 appropriate "RECURRENCE-ID" property. 321 D. Upon successful creation of the attachment resource, and 322 modification of the targeted calendar object resource, the 323 server MUST return an appropriate HTTP success status 324 response and include a "Cal-Managed-ID" header field 325 containing the "MANAGED-ID" parameter value of the newly 326 created "ATTACH" property. The client can use the "Cal- 327 Managed-ID" header field value to correlate the attachment 328 with "ATTACH" properties added to the calendar object 329 resource. If the client included a Prefer header field with 330 the "return=representation" preference in the request, the 331 server SHOULD return the modified calendar object resource as 332 the body of the response. Otherwise, the server can expect 333 that the client will reload the calendar object resource with 334 a subsequent GET request to refresh any local cache. 336 In the following example, the client adds a new attachment to a non 337 recurring event and asks the server (via the Prefer [RFC7240] header 338 field) to return the modified version of that event in the response. 340 >> Request << 342 POST /events/64.ics?action=attachment-add HTTP/1.1 343 Host: cal.example.com 344 Content-Type: text/html; charset="utf-8" 345 Content-Disposition:attachment;filename=agenda.html 346 Content-Length: xxxx 347 Prefer: return=representation 349 350 351

Agenda

352 353 355 >> Response << 357 HTTP/1.1 201 Created 358 Content-Type: text/calendar; charset="utf-8" 359 Content-Length: yyyy 360 Content-Location: http://cal.example.com/events/64.ics 361 ETag: "123456789-000-111" 362 Cal-Managed-ID: 97S 364 BEGIN:VCALENDAR 365 VERSION:2.0 366 PRODID:-//Example Corp.//CalDAV Server//EN 367 BEGIN:VEVENT 368 UID:20010712T182145Z-123401@example.com 369 DTSTAMP:20120201T203412Z 370 DTSTART:20120714T170000Z 371 DTEND:20120715T040000Z 372 SUMMARY:One-off meeting 373 ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; 374 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R 375 END:VEVENT 376 END:VCALENDAR 378 3.5. Updating Attachments 380 When an attachment is updated the server MUST change the associated 381 "MANAGED-ID" parameter and MAY change the "ATTACH" property value. 382 With this approach, clients are able to determine when an attachment 383 has been updated by some other client by looking for a change to 384 either the "ATTACH" property value, or the "MANAGED-ID" parameter 385 value. 387 To change the data of an existing managed attachment in a calendar 388 object resource, the following occurs: 390 1. The client issues a POST request targeted at the calendar object 391 resource. 393 A. The request-URI will include an "action" query parameter with 394 the value "attachment-update" (see Section 3.3.1). 396 B. The request-URI will include a "managed-id" query parameter 397 with the value matching that of the "MANAGED-ID" parameter 398 for the "ATTACH" property being updated (see Section 3.3.3). 400 C. The body of the request contains the updated data for the 401 attachment. 403 D. The client MUST include a valid Content-Type header field 404 describing the media type of the attachment (as required by 405 HTTP). 407 E. The client SHOULD include a Content-Disposition header field 408 [RFC6266] with a "type" parameter set to "attachment", and a 409 "filename" parameter that indicates the name of the 410 attachment. 412 F. The client MAY include a Prefer header field [RFC7240] with 413 the "return=representation" preference to request that the 414 modified calendar object resource be returned as the body of 415 a successful response to the POST request. 417 2. When the server receives the POST request it does the following: 419 A. Validates that the "managed-id" query parameter is valid for 420 the calendar object resource. 422 B. Updates the content of the attachment resource corresponding 423 to that managed-id with the supplied attachment data. 425 C. For each affected recurrence instance in the calendar object 426 resource targeted by the request, the server updates the 427 "ATTACH" property whose "MANAGED-ID" property parameter value 428 matches the "managed-id" query parameter. The "MANAGED-ID" 429 parameter value is changed to allow other clients to detect 430 the update, and the property value (attachment URI) might 431 also be changed. The "ATTACH" property SHOULD contain a 432 "FMTTYPE" parameter whose value matches the Content-Type 433 header field value from the request - this could differ from 434 the original value if the media type of the updated 435 attachment is different. The "ATTACH" property SHOULD 436 contain a "FILENAME" parameter whose value matches the 437 Content-Disposition header field "filename" parameter value 438 from the request, taking into account the restrictions 439 expressed in Section 4.2. The "ATTACH" property SHOULD 440 include a "SIZE" parameter whose value represents the size in 441 octets of the updated attachment. 443 D. Upon successful update of the attachment resource, and 444 modification of the targeted calendar object resource, the 445 server MUST return an appropriate HTTP success status 446 response, and include a "Cal-Managed-ID" header field 447 containing the new value of the "MANAGED-ID" parameter. The 448 client can use the "Cal-Managed-ID" header field value to 449 correlate the attachment with "ATTACH" properties added to 450 the calendar object resource. If the client included a 451 Prefer header field with the "return=representation" 452 preference in the request, the server SHOULD return the 453 modified calendar object resource as the body of the 454 response. Otherwise, the server can expect that the client 455 will reload the calendar object resource with a subsequent 456 GET request to refresh any local cache. 458 The update operation does not take a "rid" parameter and does not 459 add, or remove, any "ATTACH" property in the targeted calendar object 460 resource. To link an existing attachment to a new instance, the 461 client simply does a PUT on the calendar object resource, adding an 462 "ATTACH" property which duplicates the existing one (see 463 Section 3.7). 465 In the following example, the client updates an existing attachment 466 and asks the server (via the Prefer [RFC7240] header field) to return 467 the updated version of that event in the response. 469 >> Request << 471 POST /events/64.ics?action=attachment-update&managed-id=97S HTTP/1.1 472 Host: cal.example.com 473 Content-Type: text/html; charset="utf-8" 474 Content-Disposition:attachment;filename=agenda.html 475 Content-Length: xxxx 476 Prefer: return=representation 478 479 480

Agenda

481

Discuss attachment draft

482 483 485 >> Response << 487 HTTP/1.1 200 OK 488 Content-Type: text/calendar; charset="utf-8" 489 Content-Length: yyyz 490 Content-Location: http://cal.example.com/events/64.ics 491 Cal-Managed-ID: 98S 492 ETag: "123456789-000-222" 494 BEGIN:VCALENDAR 495 VERSION:2.0 496 PRODID:-//Example Corp.//CalDAV Server//EN 497 BEGIN:VEVENT 498 UID:20010712T182145Z-123401@example.com 499 DTSTAMP:20120201T203412Z 500 DTSTART:20120714T170000Z 501 DTEND:20120715T040000Z 502 SUMMARY:One-off meeting 503 ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=xxxy; 504 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R 505 END:VEVENT 506 END:VCALENDAR 508 3.6. Removing Attachments via POST 510 To remove an existing attachment from a calendar object, the 511 following occurs: 513 1. The client issues a POST request targeted at the calendar object 514 resource. 516 A. The request-URI will include an "action" query parameter with 517 the value "attachment-remove" (see Section 3.3.1). 519 B. If all recurrence instances are having an attachment removed, 520 the "rid" query parameter is not present in the request-URI. 521 If one or more specific recurrence instances are targeted, 522 then the request-URI will include a "rid" query parameter 523 containing the list of instances (see Section 3.3.2). 525 C. The request-URI will include a "managed-id" query parameter 526 with the value matching that of the "MANAGED-ID" property 527 parameter for the "ATTACH" property being removed (see 528 Section 3.3.3). 530 D. The body of the request will be empty. 532 E. The client MAY include a Prefer header field [RFC7240] with 533 the "return=representation" preference to request that the 534 modified calendar object resource be returned as the body of 535 a successful response to the POST request. 537 2. When the server receives the POST request it does the following: 539 A. Validates that any recurrence instances referred to via the 540 "rid" query parameter are valid for the calendar object 541 resource being targeted. 543 B. Validates that the "managed-id" query parameter is valid for 544 the calendar object resource and specific instances being 545 targeted. 547 C. For each affected recurrence instance in the calendar object 548 resource targeted by the request, the server removes the 549 matching "ATTACH" property. Note that if a specified 550 recurrence instance does not have a matching component in the 551 calendar object resource, then the server MUST modify the 552 calendar object resource to include an overridden component 553 with the appropriate "RECURRENCE-ID" property, and the 554 matching "ATTACH" property removed. This later case is 555 actually valid only if the master component does include the 556 referenced "ATTACH" property. 558 D. If the attachment resource is no longer referenced by any 559 instance of the calendar object resource, the server can 560 delete the attachment resource to free up storage space. 562 E. Upon successful removal of the attachment resource and 563 modification of the targeted calendar object resource, the 564 server MUST return an appropriate HTTP success status 565 response. If the client included a Prefer header field with 566 the "return=representation" preference in the request, the 567 server SHOULD return the modified calendar object resource as 568 the body of the response. Otherwise, the server can expect 569 that the client will reload the calendar object resource with 570 a subsequent GET request to refresh any local cache. 572 In the following example, the client deletes an existing attachment 573 by passing its managed-id in the request. The Prefer [RFC7240] 574 header field is not set in the request so the calendar object 575 resource data is not returned in the response. 577 >> Request << 579 POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1 580 Host: cal.example.com 581 Content-Length: 0 583 >> Response << 585 HTTP/1.1 204 No Content 586 Content-Length: 0 588 3.7. Adding Existing Managed Attachments via PUT 590 Clients can make use of existing managed attachments by adding the 591 corresponding "ATTACH" property to calendar object resources (subject 592 to the restrictions described in Section 3.12.2). When this occurs, 593 servers SHOULD NOT change either the "MANAGED-ID" parameter value or 594 the "ATTACH" property value for any managed attachments - this 595 ensures that clients do not have to download the attachment data 596 again if they already have it cached, because it is used in another 597 calendar resource. 599 3.8. Updating Attachments via PUT 601 Servers MUST NOT allow clients to update attachment data directly via 602 a PUT on the attachment URI (or via any other HTTP method that 603 modifies content). Instead, attachments can only be updated via use 604 of POST requests on the calendar data. 606 3.9. Removing Attachments via PUT 608 Clients can remove attachments by simply re-writing the calendar 609 object resource data to remove the appropriate "ATTACH" properties. 610 Servers MUST NOT allow clients to delete attachments directly via a 611 DELETE request on the attachment URI. 613 3.10. Retrieving Attachments 615 Clients retrieve attachments by issuing an HTTP GET request using the 616 value of the corresponding "ATTACH" property as the request-URI, 617 taking into account the substitution mechanism associated with the 618 "CALDAV:managed-attachments-server-URL" property (see Section 6.1). 620 3.11. Error Handling 622 This specification creates additional preconditions for the POST 623 method. 625 The new preconditions are: 627 (CALDAV:max-attachment-size): The attachment submitted in the POST 628 request MUST have an octet size less than or equal to the value of 629 the CALDAV:max-attachment-size property value (Section 6.2) on the 630 calendar collection of the target calendar resource; 632 (CALDAV:max-attachments-per-resource): The addition of the 633 attachment submitted in the POST request MUST result in the target 634 calendar resource having a number of managed attachments less than 635 or equal to the value of the CALDAV:max-attachments-per-resource 636 property value (Section 6.3) on the calendar collection of the 637 target calendar resource; 639 (CALDAV:valid-managed-id): The managed-id query parameter in the 640 POST request MUST contain a value corresponding to a "MANAGED-ID" 641 property parameter value in the iCalendar data targeted by the 642 request. 644 A POST request to add, modify, or delete a managed attachment results 645 in an implicit modification of the targeted calendar resource 646 (equivalent of a PUT). As a consequence, clients should also be 647 prepared to handle preconditions associated with this implicit PUT. 648 This includes (but is not limited to): 650 (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) 652 (DAV:quota-not-exceeded) (from Section 6 of [RFC4331]) 653 (DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) 655 A PUT request to add or modify and existing calendar object resource 656 can make reference to an existing managed attachment. The following 657 new preconditions is defined: 659 (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property 660 parameter value in the iCalendar data in the PUT request is not 661 valid (e.g., does not match any existing managed attachment). 663 3.12. Additional Considerations 665 3.12.1. Quotas 667 The WebDAV Quotas [RFC4331] specification defines two live WebDAV 668 properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to 669 communicate storage quota information to clients. Server 670 implementations MAY choose to include managed attachments sizes when 671 calculating the amount of storage used by a particular resource. 673 3.12.2. Access Control 675 Access to the managed attachments store in a calendar object resource 676 SHOULD be restricted to only those calendar users who have access to 677 that calendar object either directly, or indirectly (via being an 678 attendee who would receive a scheduling message). 680 When accessing a managed attachment, clients SHOULD be prepared to 681 authenticate with the server storing the attachment resource. The 682 credentials required to access the managed attachment store could be 683 different from the ones used to access the CalDAV server. 685 This specification only allows organizers of scheduled events to add 686 managed attachments. Servers MUST prevent attendees of scheduled 687 events from adding, updating or removing managed attachments. In 688 addition, the server MUST prevent a calendar user from re-using a 689 managed attachment (based on its managed-id value), unless that user 690 is the one who originally created the managed attachment. 692 3.12.3. Redirects 694 For POST requests that add or update attachment data, the server MAY 695 issue an HTTP redirect to require the client to re-issue the POST 696 request using a different request-URI. As a result, it is always 697 best for clients to use the "100-continue" expectation defined in 698 Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a 699 redirect does occur, the client does not needlessly send the 700 attachment data. 702 3.12.4. Processing Time 704 Clients can expect servers to take a while to respond to POST 705 requests that include large attachment bodies. Servers SHOULD use 706 the "102 (Processing)" interim response defined in Section 10.1 of 707 [RFC2518] to keep the client connection alive if the POST request 708 will take significant time to complete. 710 3.12.5. Automatic Clean-up by servers 712 Servers MAY automatically remove attachment data, for example to 713 regain the storage taken by unused attachments, or as the result of a 714 virus scanning. When doing so they SHOULD NOT modify calendar data 715 referencing those attachments. Instead they SHOULD respond with "410 716 (Gone)" to any request on the removed attachment URI. 718 3.12.6. Sending Scheduling Messages with Attachments 720 When a managed attachment is added, updated or removed from a 721 calendar object resource, the server MUST ensure that a scheduling 722 message is sent to update any attendees with the changes, as per 723 [RFC6638]. 725 3.12.7. Migrating Calendar Data 727 When exporting calendar data from a CalDAV server supporting managed 728 attachments, clients SHOULD remove all "MANAGED-ID" property 729 parameters from "ATTACH" properties in the calendar data. Similarly 730 when importing calendar data from another source, clients SHOULD 731 remove any "MANAGED-ID" property parameters on "ATTACH" properties 732 (failure to do so will likely result in the server removing those 733 properties automatically). 735 4. Modifications to iCalendar Syntax 737 4.1. SIZE Property Parameter 739 Parameter Name: SIZE 741 Purpose: To specify the size of an attachment. 743 Format Definition: This property parameter is defined by the 744 following notation: 746 sizeparam = "SIZE" "=" paramtext 747 ; positive integers 748 Description: This property parameter MAY be specified on "ATTACH" 749 properties. It indicates the size in octets of the corresponding 750 attachment data. Since iCalendar integer values are restricted to 751 a maximum value of 2147483647, the current parameter is defined as 752 text to allow an extended range to be used. 754 Example: 756 ATTACH;SIZE=1234:http://attachments.example.com/abcd.txt 758 4.2. FILENAME Property Parameter 760 Parameter Name: FILENAME 762 Purpose: To specify the file name of a managed attachment. 764 Format Definition: This property parameter is defined by the 765 following notation: 767 filenameparam = "FILENAME" "=" paramtext 769 Description: This property parameter MAY be specified on "ATTACH" 770 properties corresponding to managed attachments. Its value 771 provides information on how to construct a filename for storing 772 the attachment data. This parameter is very similar in nature to 773 the Content-Disposition HTTP header field "filename" parameter and 774 exposes the same security risks. As a consequence, clients MUST 775 follow the guidelines expressed in Section 4.3 of [RFC6266] when 776 consuming this parameter value. Similarly, servers MUST follow 777 those same guidelines before storing a value. 779 Example: 781 ATTACH;FILENAME=agenda.html:http://attachments.example.c 782 om/rt452S 784 4.3. MANAGED-ID Property Parameter 786 Parameter Name: MANAGED-ID 788 Purpose: To uniquely identify a managed attachment. 790 Format Definition: This property parameter is defined by the 791 following notation: 793 managedidparam = "MANAGED-ID" "=" paramtext 794 Description: This property parameter MUST be specified on "ATTACH" 795 properties corresponding to managed attachments. Its value is 796 generated by the server and uniquely identifies a managed 797 attachment. This property parameter MUST NOT be present in the 798 case of non-managed attachments. 800 Example: 802 ATTACH;MANAGED-ID=aUNhbGVuZGFy:http://attachments.example.c 803 om/abcd.txt 805 5. Additional Message Header Fields 807 5.1. Cal-Managed-ID Response Header Field 809 The Cal-Managed-ID response header field provides the value of the 810 MANAGED-ID parameter corresponding to a newly added ATTACH property. 811 It MUST be sent only in response to a successful POST request with an 812 action set to attachment-add or attachment-update. 814 Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext 815 ; "paramtext" is defined in Section 3.1 of [RFC5545] 817 Example: 819 Cal-Managed-ID:aUNhbGVuZGFy 821 6. Additional WebDAV properties 823 6.1. CALDAV:managed-attachments-server-URL property 825 Name: managed-attachments-server-URL 827 Namespace: urn:ietf:params:xml:ns:caldav 829 Purpose: Specifies the server base URI to use when retrieving 830 managed attachments. 832 Protected: This property MUST be protected as only the server can 833 update the value. 835 COPY/MOVE behavior: This property is only defined on a calendar home 836 collection which cannot be moved or copied. 838 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 839 request. 841 Description: This property MAY be defined on a calendar home 842 collection. If present, it contains zero or one DAV:href XML 843 elements. 845 When one DAV:href element is present, its value MUST be an 846 absolute HTTP URI containing only the scheme (i.e. "https") and 847 authority (i.e. host and port) parts . Whenever a managed 848 attachment is to be retrieved via an HTTP GET, the client MUST 849 construct the actual URL of the attachment by substituting the 850 scheme and authority parts of the attachment URI (as stored in the 851 iCalendar "ATTACH" property) with the present WebDAV property 852 value. 854 When no DAV:href element is present, the client MUST substitute 855 the scheme and authority parts of the attachment URI with the 856 scheme and authority part of the calendar home collection absolute 857 URI. 859 In the absence of this property, the client can consider the 860 attachment URI as its actual URL. 862 Definition: 864 866 Example: 868 870 https://attachstore.example.com 871 873 6.2. CALDAV:max-attachment-size property 875 Name: max-attachment-size 877 Namespace: urn:ietf:params:xml:ns:caldav 879 Purpose: Provides a numeric value indicating the maximum attachment 880 size, in octets, that the server is willing to accept when a 881 managed attachment is stored on the server. 883 Protected: MUST be protected as it indicates limits provided by the 884 server. 886 COPY/MOVE behavior: This property value MUST be preserved in COPY 887 and MOVE operations. 889 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 890 request. 892 Description: The CALDAV:max-attachment-size property is used to 893 specify a numeric value that represents the maximum attachment 894 size, in octets, that the server is willing to accept when a 895 managed attachment is stored on the server. The property is 896 defined on the parent collection of the calendar object resource 897 to which the attachment is associated. Any attempt to store a 898 managed attachment exceeding this size MUST result in an error, 899 with the CALDAV:max-attachment-size precondition (Section 3.11) 900 being violated. In the absence of this property, the client can 901 assume that the server will allow storing an attachment of any 902 reasonable size. 904 Definition: 906 907 909 Example: 911 102400000 914 6.3. CALDAV:max-attachments-per-resource property 916 Name: max-attachments-per-resource 918 Namespace: urn:ietf:params:xml:ns:caldav 920 Purpose: Provides a numeric value indicating the maximum number of 921 managed attachments across all instances of a calendar object 922 resource stored in a calendar collection. 924 Protected: MUST be protected as it indicates limits provided by the 925 server. 927 COPY/MOVE behavior: This property value MUST be preserved in COPY 928 and MOVE operations. 930 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 931 request. 933 Description: The CALDAV:max-attachments-per-resource property is 934 used to specify a numeric value that represents the maximum number 935 of managed attachments across all instances of a calendar object 936 resource stored in a calendar collection. Non-managed attachments 937 are not counted toward that limit. The property is defined on the 938 parent collection of the calendar object resource to which the 939 attachment is associated. Any attempt to add a managed attachment 940 that would cause the calendar resource to exceed this limit MUST 941 result in an error, with the CALDAV:max-attachments-per-resource 942 precondition (Section 3.11) being violated. In the absence of 943 this property, the client can assume that the server can handle 944 any number of managed attachments per calendar resource. 946 Definition: 948 949 951 Example: 953 12 957 7. Implementation Status 959 < RFC Editor: before publication please remove this section and the 960 reference to [RFC7942] > 962 This section records the status of known implementations of the 963 protocol defined by this specification at the time of posting of this 964 Internet-Draft, and is based on a proposal described in [RFC7942]. 965 The description of implementations in this section is intended to 966 assist the IETF in its decision processes in progressing drafts to 967 RFCs. Please note that the listing of any individual implementation 968 here does not imply endorsement by the IETF. Furthermore, no effort 969 has been spent to verify the information presented here that was 970 supplied by IETF contributors. This is not intended as, and must not 971 be construed to be, a catalog of available implementations or their 972 features. Readers are advised to note that other implementations may 973 exist. 975 According to [RFC7942], "this will allow reviewers and working groups 976 to assign due consideration to documents that have the benefit of 977 running code, which may serve as evidence of valuable experimentation 978 and feedback that have made the implemented protocols more mature. 979 It is up to the individual working groups to use this information as 980 they see fit". 982 7.1. Calendar and Contacts Server 984 The open source Calendar and Contacts Server [1] project is a 985 standards-compliant server implementing the CalDAV protocol. This 986 production level implementation supports all of the requirements 987 described in this document and successfully interoperates with the 988 Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations 989 described below. This implementation is freely distributable under 990 the terms of the Apache License, Version 2.0 [2]. 992 7.2. Cyrus Server 994 The open source Cyrus Server [3] project is a highly scalable 995 enterprise mail system which also supports calendaring. This 996 production level CalDAV implementation supports all of the 997 requirements described in this document and successfully 998 interoperates with the Apple Calendar and CalDAVTester client 999 implementations described below. This implementation is freely 1000 distributable under a BSD style license from Computing Services at 1001 Carnegie Mellon University [4]. 1003 7.3. Oracle Communications Calendar Server 1005 The Oracle Communications Calendar Server [5] project is a standards- 1006 compliant, scalable, enterprise-ready calendaring solution. This 1007 production level CalDAV implementation supports all of the 1008 requirements described in this document and successfully 1009 interoperates with the Apple Calendar and CalDAVTester client 1010 implementations described below. This implementation is proprietary 1011 and available for a free trial and/or purchase from the vendor. 1013 7.4. Apple Calendar 1015 The widely used Apple Calendar [6] client is a standards-compliant 1016 client implementing the CalDAV protocol. This production level 1017 implementation supports all the requirements described in this 1018 document and successfully interoperates with the 1019 Calendar and Contacts Server, Cyrus Server, and 1020 Oracle Communications Calendar Server implementations described 1021 above. This client implementation is proprietary and is distributed 1022 as part of Apple's desktop operating systems. 1024 7.5. BusyCal 1026 BusyCal [7] is a standards-compliant calendar client for MacOS 1027 implementing the CalDAV protocol. This implementation supports all 1028 of the requirements described in this document and successfully 1029 interoperates with the Calendar and Contacts Server and Cyrus Server 1030 implementations described above. This implementation is proprietary 1031 and available for a free trial and/or purchase from the vendor. 1033 7.6. CalDAVTester 1035 CalDAVTester [8] is an open source test and performance application 1036 designed to work with CalDAV servers and tests various aspects of 1037 their protocol handling as well as performance. This widely used 1038 implementation supports all of the requirements described in this 1039 document and successfully interoperates with the server 1040 implementations described above. This implementation is freely 1041 distributable under the terms of the Apache License, Version 2.0 [9]. 1043 7.7. 2Do 1045 2Do [10] is a standards-complient calendar client for iOS which uses 1046 the CalDAV standard for communication. This implementation supports 1047 all of the requirements described in this document and successfully 1048 interoperates with the Calendar and Contacts Server implementation 1049 described above. This implementation is proprietary and available 1050 for purchase from the vendor. 1052 8. Security Considerations 1054 Malicious content could be introduced into the Calendar Server by way 1055 of a managed attachment, and propagated to many end users via 1056 scheduling. Servers SHOULD check managed attachments for malicious 1057 or inappropriate content. Upon detecting of such content, servers 1058 SHOULD remove the attachment, following the rules described in 1059 Section 3.12.5. 1061 9. IANA Considerations 1063 9.1. Parameter Registrations 1065 This specification defines the following new iCalendar property 1066 parameters to be added to the registry defined in Section 8.2.3 of 1067 [RFC5545]: 1069 +--------------------+---------+----------------------+ 1070 | Property Parameter | Status | Reference | 1071 +--------------------+---------+----------------------+ 1072 | SIZE | Current | RFCXXXX, Section 4.1 | 1073 | FILENAME | Current | RFCXXXX, Section 4.2 | 1074 | MANAGED-ID | Current | RFCXXXX, Section 4.3 | 1075 +--------------------+---------+----------------------+ 1077 9.2. Message Header Field Registrations 1079 The message header fields below should be added to the Permanent 1080 Message Header Field Registry (see [RFC3864]). 1082 9.2.1. Cal-Managed-ID 1084 Header field name: Cal-Managed-ID 1086 Applicable protocol: http 1088 Status: standard 1090 Author/Change controller: IETF 1092 Specification document(s): this specification (Section 5.1) 1094 Related information: none 1096 10. Acknowledgments 1098 This specification came about via discussions at the Calendaring and 1099 Scheduling Consortium. Thanks in particular to Mike Douglass and 1100 Eric York. 1102 11. References 1104 11.1. Normative References 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1112 Jensen, "HTTP Extensions for Distributed Authoring -- 1113 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 1114 . 1116 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1117 Procedures for Message Header Fields", BCP 90, RFC 3864, 1118 DOI 10.17487/RFC3864, September 2004, 1119 . 1121 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties 1122 for Distributed Authoring and Versioning (DAV) 1123 Collections", RFC 4331, DOI 10.17487/RFC4331, February 1124 2006, . 1126 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1127 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1128 DOI 10.17487/RFC4791, March 2007, 1129 . 1131 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1132 Specifications: ABNF", STD 68, RFC 5234, 1133 DOI 10.17487/RFC5234, January 2008, 1134 . 1136 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1137 Scheduling Core Object Specification (iCalendar)", 1138 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1139 . 1141 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1142 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1143 DOI 10.17487/RFC6266, June 2011, 1144 . 1146 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 1147 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 1148 . 1150 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1151 Protocol (HTTP/1.1): Message Syntax and Routing", 1152 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1153 . 1155 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1156 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1157 DOI 10.17487/RFC7231, June 2014, 1158 . 1160 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 1161 DOI 10.17487/RFC7240, June 2014, 1162 . 1164 11.2. Informative References 1166 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1167 Interoperability Protocol (iTIP)", RFC 5546, 1168 DOI 10.17487/RFC5546, December 2009, 1169 . 1171 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1172 Code: The Implementation Status Section", BCP 205, 1173 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1174 . 1176 11.3. URIs 1178 [1] http://calendarserver.org/ 1180 [2] http://www.apache.org/licenses/LICENSE-2.0.html 1182 [3] http://www.cyrusimap.org/ 1184 [4] http://www.cmu.edu/computing/ 1186 [5] http://www.cyrusimap.org/ 1188 [6] http://www.apple.com/macos/ 1190 [7] http://www.busymac.com/busycal/ 1192 [8] http://calendarserver.org/wiki/CalDAVTester 1194 [9] http://www.apache.org/licenses/LICENSE-2.0.html 1196 [10] http://www.2doapp.com/ 1198 Appendix A. Change History (To be removed by RFC Editor before 1199 publication) 1201 Changes in calext-02: 1203 1. Moved "Error Handling" into its own sub-section. 1205 2. Split "Other Client Considerations" into "Processing Time" and 1206 "Migrating Calendar Data". 1208 Changes in calext-01: 1210 1. Changed all instances of "header" to "header field". 1212 2. Reworked wording of Prefer header field handling. 1214 3. Switched to recommending 102 (Processing) interim response to 1215 keep the client connection alive. 1217 4. Fixed description of Cal-Managed-ID response header field to 1218 state that it is also required in responses to successful 1219 attachment-update. 1221 5. Minor editorial changes. 1223 Changes in calext-00: 1225 1. Added Murchison as editor. 1227 2. Updated HTTP references to RFC7230 and RFC7231. 1229 3. Updated Prefer header field references to RFC7240. 1231 4. Added Implementation Status section. 1233 5. Minor editorial changes. 1235 Changes in daboo-03: 1237 1. Fixed some examples. 1239 2. Fixed return-representation -> return=representation. 1241 3. Added statement that servers must not allow clients to DELETE 1242 attachments directly. 1244 4. Added new preconditions for valid managed-id values. 1246 5. Filled out Access Control section. 1248 6. Allow servers to not support per-instance attachments and 1249 advertise that fact to clients. 1251 Changes in daboo-02: 1253 1. MANAGED-ID changes on PUT. 1255 2. MTAG has been removed. 1257 3. Error pre-conditions added. 1259 4. Interaction with WebDAV QUOTA discussed. 1261 5. max-attachment-* limits added. 1263 6. Updated references. 1265 7. Removed MUST for specific 2xx codes in favor of generic success 1266 code. 1268 Changes in daboo-01: 1270 1. Tweaked OPTIONS capability wording. 1272 2. Added section on clients expecting 100-Continue for delayed 1273 response. 1275 3. Added text for clean-up and use of HTTP 410 on orphans. 1277 4. Added text on removing "MANAGED-ID" when exporting/importing 1278 calendar data. 1280 5. Added protocol examples. 1282 6. Added MTAG property parameter on ATTACH property 1284 7. Added FILENAME property parameter on ATTACH property 1286 8. "id" query parameter is now "managed-id". 1288 9. Use of Cal-Managed-ID header instead of Location header in 1289 responses. 1291 10. rid query param MUST contain RECURRENCE-ID without any 1292 conversion to UTC (case of floating events). 1294 11. Introduced CALDAV:managed-attachments-server-URL property 1296 12. Made support for Prefer header a MUST for servers. 1298 Appendix B. Example Involving Recurring Events 1300 In the following example, the organizer of a recurring meeting adds 1301 an agenda (HTML attachment) to the corresponding calendar resource. 1302 Attendees of the meeting are granted read access to the newly created 1303 attachment resource. Their own copy of the meeting is updated to 1304 include the new ATTACH property pointing to the attachment resource 1305 and they are notified of the change via their scheduling inbox. 1307 >> Request << 1309 POST /events/65.ics?action=attachment-add HTTP/1.1 1310 Host: cal.example.com 1311 Content-Type: text/html; charset="utf-8" 1312 Content-Disposition:attachment;filename=agenda.html 1313 Content-Length: xxxx 1314 Prefer: return=representation 1316 1317 1318

Agenda

1319

As usual

1320 1321 1322 >> Response << 1324 HTTP/1.1 201 Created 1325 Content-Type: text/calendar; charset="utf-8" 1326 Content-Length: yyyy 1327 Content-Location: http://cal.example.com/events/65.ics 1328 ETag: "123456789-000-111" 1329 Cal-Managed-ID: 97S 1331 BEGIN:VCALENDAR 1332 VERSION:2.0 1333 PRODID:-//Example Corp.//CalDAV Server//EN 1334 BEGIN:VTIMEZONE 1335 LAST-MODIFIED:20040110T032845Z 1336 TZID:America/Montreal 1337 BEGIN:DAYLIGHT 1338 DTSTART:20000404T020000 1339 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1340 TZNAME:EDT 1341 TZOFFSETFROM:-0500 1342 TZOFFSETTO:-0400 1343 END:DAYLIGHT 1344 BEGIN:STANDARD 1345 DTSTART:20001026T020000 1346 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1347 TZNAME:EST 1348 TZOFFSETFROM:-0400 1349 TZOFFSETTO:-0500 1350 END:STANDARD 1351 END:VTIMEZONE 1352 BEGIN:VEVENT 1353 UID:20010712T182145Z-123401@example.com 1354 DTSTAMP:20120201T203412Z 1355 DTSTART;TZID=America/Montreal:20120206T100000 1356 DURATION:PT1H 1357 RRULE:FREQ=WEEKLY 1358 SUMMARY:Planning Meeting 1359 ORGANIZER:mailto:cyrus@example.com 1360 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl 1361 e.com 1362 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam 1363 ple.com 1364 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa 1365 mple.com 1366 ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; 1367 FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R 1368 END:VEVENT 1369 END:VCALENDAR 1370 The organizer has a more specific agenda for the 20th of February 1371 meeting. It is added to that particular instance of the meeting by 1372 specifying the rid parameter. 1374 >> Request << 1376 POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1 1377 Host: cal.example.com 1378 Content-Type: text/html; charset="utf-8" 1379 Content-Disposition:attachment;filename=agenda0220.html 1380 Content-Length: xxxx 1381 Prefer: return=representation 1383 1384 1385

Agenda

1386

Something different, for a change

1387 1388 1390 >> Response << 1392 HTTP/1.1 201 Created 1393 Content-Type: text/calendar; charset="utf-8" 1394 Content-Length: yyyy 1395 Content-Location: http://cal.example.com/events/65.ics 1396 ETag: "123456789-000-222" 1397 Cal-Managed-ID: 33225 1399 BEGIN:VCALENDAR 1400 VERSION:2.0 1401 PRODID:-//Example Corp.//CalDAV Server//EN 1402 BEGIN:VTIMEZONE 1403 LAST-MODIFIED:20040110T032845Z 1404 TZID:America/Montreal 1405 BEGIN:DAYLIGHT 1406 DTSTART:20000404T020000 1407 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1408 TZNAME:EDT 1409 TZOFFSETFROM:-0500 1410 TZOFFSETTO:-0400 1411 END:DAYLIGHT 1412 BEGIN:STANDARD 1413 DTSTART:20001026T020000 1414 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1415 TZNAME:EST 1416 TZOFFSETFROM:-0400 1417 TZOFFSETTO:-0500 1418 END:STANDARD 1419 END:VTIMEZONE 1420 BEGIN:VEVENT 1421 UID:20010712T182145Z-123401@example.com 1422 DTSTAMP:20120201T203412Z 1423 DTSTART;TZID=America/Montreal:20120206T100000 1424 DURATION:PT1H 1425 RRULE:FREQ=WEEKLY 1426 SUMMARY:Planning Meeting 1427 ORGANIZER:mailto:cyrus@example.com 1428 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl 1429 e.com 1430 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam 1431 ple.com 1432 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa 1433 mple.com 1434 ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; 1435 FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R 1436 END:VEVENT 1437 BEGIN:VEVENT 1438 UID:20010712T182145Z-123401@example.com 1439 RECURRENCE-ID;TZID=America/Montreal:20120220T100000 1440 DTSTAMP:20120201T203412Z 1441 DTSTART;TZID=America/Montreal:20120220T100000 1442 DURATION:PT1H 1443 SUMMARY:Planning Meeting 1444 ORGANIZER:mailto:cyrus@example.com 1445 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example. 1446 com 1447 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl 1448 e.com 1449 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp 1450 le.com 1451 ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=xxxx; 1452 FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225 1453 END:VEVENT 1454 END:VCALENDAR 1456 Authors' Addresses 1458 Cyrus Daboo 1459 Apple Inc. 1460 1 Infinite Loop 1461 Cupertino, CA 95014 1462 USA 1464 Email: cyrus@daboo.name 1465 URI: http://www.apple.com/ 1466 Arnaud Quillaud 1467 Oracle Corporation 1468 180, Avenue de l'Europe 1469 Saint Ismier cedex 38334 1470 France 1472 Email: arnaud.quillaud@oracle.com 1473 URI: http://www.oracle.com/ 1475 Kenneth Murchison (editor) 1476 Carnegie Mellon University 1477 5000 Forbes Avenue 1478 Pittsburgh, PA 15213 1479 USA 1481 Email: murch@andrew.cmu.edu 1482 URI: http://www.cmu.edu/