idnits 2.17.1 draft-ietf-calext-caldav-attachments-00.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 (October 17, 2016) is 2747 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 1149 -- Looks like a reference, but probably isn't: '2' on line 1151 -- Looks like a reference, but probably isn't: '3' on line 1153 -- Looks like a reference, but probably isn't: '4' on line 1155 -- Looks like a reference, but probably isn't: '5' on line 1157 -- Looks like a reference, but probably isn't: '6' on line 1159 -- Looks like a reference, but probably isn't: '7' on line 1161 -- Looks like a reference, but probably isn't: '8' on line 1163 -- Looks like a reference, but probably isn't: '9' on line 1165 -- Looks like a reference, but probably isn't: '10' on line 1167 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 2 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: April 20, 2017 Oracle 6 K. Murchison, Ed. 7 CMU 8 October 17, 2016 10 CalDAV Managed Attachments 11 draft-ietf-calext-caldav-attachments-00 13 Abstract 15 This specification defines an extension to the calendar access 16 protocol (CalDAV) to allow attachments associated with iCalendar 17 data, 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 April 20, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . 13 65 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 13 66 3.11. Additional Considerations . . . . . . . . . . . . . . . . 13 67 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16 68 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16 69 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 16 70 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17 71 5. Additional Message Header Fields . . . . . . . . . . . . . . 17 72 5.1. Cal-Managed-ID Response Header . . . . . . . . . . . . . 17 73 6. Additional WebDAV properties . . . . . . . . . . . . . . . . 18 74 6.1. CALDAV:managed-attachments-server-URL property . . . . . 18 75 6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 19 76 6.3. CALDAV:max-attachments-per-resource property . . . . . . 20 77 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 23 81 9.2. Message Header Field Registrations . . . . . . . . . . . 23 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . 25 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 Appendix A. Change History (To be removed by RFC Editor before 88 publication) . . . . . . . . . . . . . . . . . . . . 26 89 Appendix B. Example Involving Recurring Events . . . . . . . . . 27 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 92 1. Introduction 94 The iCalendar [RFC5545] data format is used to represent calendar 95 data and is used with iTIP [RFC5546] to handle scheduling operations 96 between calendar users. 98 [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP 99 [RFC7230], for accessing calendar data stored on a server. 101 Calendar users often want to include attachments with their calendar 102 data events or tasks (for example a copy of a presentation, or the 103 meeting agenda). iCalendar provides an "ATTACH" property whose value 104 is either the inline Base64 encoded attachment data, or a URL 105 specifying the location of the attachment data. 107 Use of inline attachment data is not ideal with CalDAV because the 108 data would need to be uploaded to the server each time a change to 109 the calendar data is done - even minor changes such as a change to 110 the summary. Whilst a client could choose to use a URL value 111 instead, the problem then becomes where and how the client discovers 112 an appropriate URL to use and how it ensures that only those 113 attendees listed in the event or task are able to access it. 115 This specification solves this problem by having the client send the 116 attachment to the server, separately from the iCalendar data, and the 117 server takes care of adding appropriate "ATTACH" properties in the 118 iCalendar data as well as managing access privileges . The server can 119 also provide additional information to the client about each 120 attachment in the iCalendar data, such as the size and an identifier. 122 2. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 The notation used in this memo is the ABNF notation of [RFC5234] as 130 used by iCalendar [RFC5545]. Any syntax elements shown below that 131 are not explicitly defined in this specification come from iCalendar 132 [RFC5545]. 134 3. Overview 136 There are four main operations a client needs to do with attachments 137 for calendar data: add, update, remove, and retrieve. The first 138 three operations are carried out by the client issuing an HTTP POST 139 request on the calendar object resource to which the attachment is 140 associated and specifying the appropriate "action" query parameter. 141 In the case of the remove operation, the client can alternatively 142 directly update the calendar object resource and remove the relevant 143 "ATTACH" properties. The retrieve operation is accomplished by 144 simply issuing an HTTP GET request targeting the attachment URI 145 specified by the calendar resource's "ATTACH" property. 147 iCalendar data stored in a CalDAV calendar object resource can 148 contain multiple components when recurrences are involved. In such a 149 situation, the client needs to be able to target a specific 150 recurrence instance or multiple instances when adding or deleting 151 attachments. As a result, the POST request needs to provide a way 152 for the client to specify which recurrence instances should be 153 targeted for the attachment operation. This is accomplished through 154 use of additional query parameters on the POST request-URI. 156 3.1. Requirements 158 A server that supports the features described in this specification 159 is REQUIRED to support the CalDAV "calendar-access" [RFC4791] 160 features. 162 In addition, such a server MUST support the "return=representation" 163 Prefer header value [RFC7240] on successful HTTP PUT and POST 164 requests targeting existing calendar object resources, by returning 165 the new representation of that calendar resource (including its new 166 Etag header value) in the response. 168 3.2. Discovering Support for Managed Attachments 170 A server supporting the features described in this specification MUST 171 include "calendar-managed-attachments" as a field in the DAV response 172 header from an OPTIONS request on a calendar home collection. 174 A server might choose to not support storing managed attachments on a 175 per-recurrence instance basis (i.e., they can only be added to all 176 instances as a whole). If that is the case, the server MUST include 177 "calendar-managed-attachments-no-recurrence" as a field in the DAV 178 response header from an OPTIONS request on a calendar home 179 collection. When that field is present, clients MUST NOT attempt any 180 managed attachment operations that target specific recurrence 181 instances. 183 3.3. POST Request for Managing Attachments 185 An HTTP POST request is used to add, update, or remove attachments. 186 The request-URI will contain various query parameters to specify the 187 behavior. 189 3.3.1. action= Query Parameter 191 The "action" query parameter is used to identify which attachment 192 operation the client is requesting. This parameter MUST be present 193 once on each POST request used to manage attachments. One of these 194 three values MUST be used: 196 attachment-add Indicates an operation that is adding an attachment 197 to a calendar object resource. See Section 3.4 for more details. 199 attachment-update Indicates an operation that is updating an 200 existing attachment on a calendar object resource. See 201 Section 3.5 for more details. 203 attachment-remove Indicates an operation that is removing an 204 attachment from a calendar object resource. See Section 3.6 for 205 more details. 207 Example: 209 http://calendar.example.com/events/1.ics?action=attachment-add 211 3.3.2. rid= Query Parameter 213 The "rid" query parameter is used to identify which recurrence 214 instances are being targeted by the client for the attachment 215 operation. This query parameter MUST contain one or more items, 216 separated by commas (0x2C). The item values can be in one of two 217 forms: 219 Master instance The value "M" (case-insensitive) refers to the 220 "master" recurrence instance, i.e., the component that does not 221 include a "RECURRENCE-ID" property. This item MUST be present 222 only once. 224 Specific instance A specific iCalendar instance is targeted by using 225 its "RECURRENCE-ID" value as the item value. That value MUST 226 correspond to the RECURRENCE-ID value as stored in the calendar 227 object resource (i.e. without any conversion to UTC). If multiple 228 items of this form are used, they MUST be unique values. 230 If the "rid" query parameter is not present, all recurrence instances 231 in the calendar object resource are targeted. 233 The "rid" query parameter MUST NOT be present in the case of an 234 update operation, or if the server chooses not to support per- 235 recurrence instance managed attachments (see Section 3.1). 237 Example: 239 http://calendar.example.com/events/1.ics? 240 action=attachment-add&rid=M,20111022T160000 242 3.3.3. managed-id= Query Parameter 244 The "managed-id" query parameter is used to identify which "ATTACH" 245 property is being updated or removed. The value of this query 246 parameter MUST match the "MANAGED-ID" property parameter value on the 247 "ATTACH" property in the calendar object resource instance(s) 248 targeted by the request. 250 The "managed-id" query parameter MUST NOT be present in the case of 251 an add operation. 253 Example: 255 http://calendar.example.com/events/1.ics? 256 action=attachment-update&managed-id=aUNhbGVuZGFy 258 3.4. Adding attachments 260 To add an attachment to an existing calendar object resource, the 261 following occurs: 263 1. The client issues a POST request targeted at the calendar object 264 resource. 266 A. The request-URI will include an "action" query parameter with 267 the value "attachment-add" (see Section 3.3.1). 269 B. If all recurrence instances are having an attachment added, 270 the "rid" query parameter is not present in the request-URI. 271 If one or more specific recurrence instances are targeted, 272 then the request-URI will include a "rid" query parameter 273 containing the list of instances (see Section 3.3.2). 275 C. The body of the request contains the data for the attachment. 277 D. The client MUST include a valid Content-Type HTTP header 278 describing the media type of the attachment (as required by 279 HTTP). 281 E. The client SHOULD include a Content-Disposition HTTP header 282 [RFC6266] with a "type" parameter set to "attachment", and a 283 "filename" parameter that indicates the name of the 284 attachment. 286 2. When the server receives the POST request it does the following: 288 A. Validates that any recurrence instances referred to via the 289 "rid" query parameter are valid for the calendar object 290 resource being targeted. 292 B. Stores the supplied attachment data into a resource and 293 generates an appropriate URI for clients to access the 294 resource. 296 C. For each affected recurrence instance in the calendar object 297 resource targeted by the request, the server adds an "ATTACH" 298 property, whose value is the URI of the stored attachment. 299 The "ATTACH" property MUST contain a "MANAGED-ID" parameter 300 whose value is a unique identifier (within the context of the 301 server as a whole). The "ATTACH" property SHOULD contain an 302 "FMTTYPE" parameter whose value matches the Content-Type 303 header value from the request. The "ATTACH" property SHOULD 304 contain an "FILENAME" parameter whose value matches the 305 Content-Disposition header "filename" parameter value from 306 the request, taking into account the restrictions expressed 307 in Section 4.2. The "ATTACH" property SHOULD include a 308 "SIZE" parameter whose value represents the size in octets of 309 the attachment. If a specified recurrence instance does not 310 have a matching component in the calendar object resource, 311 then the server MUST modify the calendar object resource to 312 include the overridden component with the appropriate 313 "RECURRENCE-ID" property included. 315 D. Upon successful creation of the attachment resource, and 316 modification of the targeted calendar object resource, the 317 server MUST return an appropriate HTTP success status 318 response and include a "Cal-Managed-ID" HTTP header 319 containing the "MANAGED-ID" parameter value of the newly 320 created "ATTACH" property. The client can use the "Cal- 321 Managed-ID" header value to correlate the attachment with 322 "ATTACH" properties added to the calendar object resource. 323 It is expected that the client will immediately reload the 324 calendar object resource to refresh any local cache, or use 325 the Prefer header "return=representation" option [RFC7240] to 326 have the server return the modified calendar object resource 327 data in the HTTP response. 329 In the following example, the client adds a new attachment to a non 330 recurring event and asks the server (via the Prefer [RFC7240] HTTP 331 header) to return the updated version of that event in the response. 333 >> Request << 335 POST /events/64.ics?action=attachment-add HTTP/1.1 336 Host: cal.example.com 337 Content-Type: text/html; charset="utf-8" 338 Content-Disposition:attachment;filename=agenda.html 339 Content-Length: xxxx 340 Prefer: return=representation 342 343 344

Agenda

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

Agenda

465

Discuss attachment draft

466 467 468 >> Response << 470 HTTP/1.1 200 OK 471 Content-Type: text/calendar; charset="utf-8" 472 Content-Length: yyyz 473 Content-Location: http://cal.example.com/events/64.ics 474 Cal-Managed-ID: 98S 475 ETag: "123456789-000-222" 477 BEGIN:VCALENDAR 478 VERSION:2.0 479 PRODID:-//Example Corp.//CalDAV Server//EN 480 BEGIN:VEVENT 481 UID:20010712T182145Z-123401@example.com 482 DTSTAMP:20120201T203412Z 483 DTSTART:20120714T170000Z 484 DTEND:20120715T040000Z 485 SUMMARY:One-off meeting 486 ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=xxxy; 487 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R 488 END:VEVENT 489 END:VCALENDAR 491 3.6. Removing Attachments via POST 493 To remove an existing attachment from a calendar object, the 494 following occurs: 496 1. The client issues a POST request targeted at the calendar object 497 resource. 499 A. The request-URI will include an "action" query parameter with 500 the value "attachment-remove" (see Section 3.3.1). 502 B. If all recurrence instances are having an attachment removed, 503 the "rid" query parameter is not present in the request-URI. 504 If one or more specific recurrence instances are targeted, 505 then the request-URI will include a "rid" query parameter 506 containing the list of instances (see Section 3.3.2). 508 C. The request-URI will include a "managed-id" query parameter 509 with the value matching that of the "MANAGED-ID" property 510 parameter for the "ATTACH" property being removed (see 511 Section 3.3.3). 513 D. The body of the request will be empty. 515 2. When the server receives the POST request it does the following: 517 A. Validates that any recurrence instances referred to via the 518 "rid" query parameter are valid for the calendar object 519 resource being targeted. 521 B. Validates that the "managed-id" query parameter is valid for 522 the calendar object resource and specific instances being 523 targeted. 525 C. For each affected recurrence instance in the calendar object 526 resource targeted by the request, the server removes the 527 matching "ATTACH" property. Note that if a specified 528 recurrence instance does not have a matching component in the 529 calendar object resource, then the server MUST modify the 530 calendar object resource to include the overridden component 531 with the appropriate "RECURRENCE-ID" property included, and 532 the matching "ATTACH" property removed. This later case is 533 actually valid only if the master component does include the 534 referenced "ATTACH" property. 536 D. If the attachment resource is no longer referenced by any 537 instance of the calendar object resource, the server can 538 delete the attachment resource to free up storage space. 540 E. Upon successful removal of the attachment resource and 541 modification of the targeted calendar object resource, the 542 server MUST return an appropriate HTTP success status 543 response. It is expected that the client will immediately 544 reload the calendar object resource to refresh any local 545 cache, or use the Prefer header "return=representation" 546 option [RFC7240] to have the server return the modified 547 calendar object resource data in the HTTP response. 549 In the following example, the client deletes an existing attachment 550 by passing its managed-id in the request. The Prefer [RFC7240] HTTP 551 header is not set in the request so the calendar object resource data 552 is not returned in the response. 554 >> Request << 556 POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1 557 Host: cal.example.com 558 Content-Length: 0 559 >> Response << 561 HTTP/1.1 204 No Content 562 Content-Length: 0 564 3.7. Adding Existing Managed Attachments via PUT 566 Clients can make use of existing managed attachments by adding the 567 corresponding "ATTACH" property to calendar object resources (subject 568 to the restrictions described in Section 3.11.3). When this occurs, 569 servers SHOULD NOT change either the "MANAGED-ID" parameter value or 570 the "ATTACH" property value for any managed attachments - this 571 ensures that clients do not have to download the attachment data 572 again if they already have it cached, because it is used in another 573 calendar resource. 575 3.8. Updating Attachments via PUT 577 Servers MUST NOT allow clients to update attachment data directly via 578 a PUT on the attachment URI (or via any other HTTP method that 579 modifies content). Instead, attachments can only be manipulated via 580 use of POST requests on the calendar data. 582 3.9. Removing Attachments via PUT 584 Clients can remove attachments by simply re-writing the calendar 585 object resource data to remove the appropriate "ATTACH" properties. 586 Servers MUST NOT allow clients to delete attachments directly via a 587 DELETE request on the attachment URI. 589 3.10. Retrieving Attachments 591 Clients retrieve attachments by issuing an HTTP GET request using the 592 value of the corresponding "ATTACH" property as the request-URI, 593 taking into account the substitution mechanism associated with the 594 "CALDAV:managed-attachments-server-URL" property (see Section 6.1). 596 3.11. Additional Considerations 598 3.11.1. Error Handling 600 This specification creates additional preconditions for the POST 601 method. 603 The new preconditions are: 605 (CALDAV:max-attachment-size): The attachment submitted in the POST 606 request MUST have an octet size less than or equal to the value of 607 the CALDAV:max-attachment-size property value (Section 6.2) on the 608 calendar collection of the target calendar resource; 610 (CALDAV:max-attachments-per-resource): The addition of the 611 attachment submitted in the POST request MUST result in the target 612 calendar resource having a number of managed attachments less than 613 or equal to the value of the CALDAV:max-attachments-per-resource 614 property value (Section 6.3) on the calendar collection of the 615 target calendar resource; 617 (CALDAV:valid-managed-id): The managed-id POST request query 618 parameter MUST contain a value corresponding to a "MANAGED-ID" 619 property parameter value in the iCalendar data targeted by the 620 request. 622 A POST request to add, modify, or delete a managed attachment results 623 in an implicit modification of the targeted calendar resource 624 (equivalent of a PUT). As a consequence, clients should also be 625 prepared to handle preconditions associated with this implicit PUT. 626 This includes (but is not limited to): 628 (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) 630 (DAV:quota-not-exceeded) (from Section 6 of [RFC4331]) 632 (DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) 634 A PUT request to add or modify and existing calendar object resource 635 can make reference to a managed attachment. The following new 636 preconditions is defined: 638 (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property 639 parameter value in the iCalendar data in the PUT request is not 640 valid (e.g., does not match any existing managed attachment). 642 3.11.2. Quotas 644 The WebDAV Quotas [RFC4331] specification defines two live WebDAV 645 properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to 646 communicate storage quota information to clients. Server 647 implementations MAY choose to include managed attachments sizes when 648 calculating the amount of storage used by a particular resource. 650 3.11.3. Access Control 652 Access to the managed attachments store in a calendar object resource 653 SHOULD be restricted to only those calendar users who have access to 654 that calendar object either directly, or indirectly (via being an 655 attendee who would receive a scheduling message). 657 When accessing a managed attachment, clients SHOULD be prepared to 658 authenticate with the server storing the attachment resource. The 659 credentials required to access the managed attachment store could be 660 different from the ones used to access the CalDAV server. 662 This specification only allows organizers of scheduled events to add 663 managed attachments. Servers MUST prevent attendees of scheduled 664 events from adding, updating or removing managed attachments. In 665 addition, the server MUST prevent a calendar user from re-using a 666 managed attachment (based on its managed-id value), unless that user 667 is the one who originally created the managed attachment. 669 3.11.4. Redirects 671 For POST requests that add or update attachment data, the server MAY 672 issue an HTTP redirect to require the client to re-issue the POST 673 request using a different request-URI. As a result, it is always 674 best for clients to use the "100 Continue" behavior defined in 675 Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a 676 redirect does occur, the client does not needlessly send the 677 attachment data. 679 3.11.5. Automatic Clean-up by servers 681 Servers MAY automatically remove attachment data, for example to 682 regain the storage taken by unused attachments, or as the result of a 683 virus scanning. When doing so they SHOULD NOT modify calendar data 684 referencing those attachments. Instead they SHOULD return a 410 HTTP 685 status response to any request on the removed attachment URI. 687 3.11.6. Sending Scheduling Messages with Attachments 689 When a managed attachment is added, updated or removed from a 690 calendar object resource, the server MUST ensure that a scheduling 691 message is sent to update any attendees with the changes, as per 692 [RFC6638]. 694 3.11.7. Other Client Considerations 696 Clients can expect servers to take a while to respond to POST 697 requests that include large attachment bodies. Servers SHOULD use 698 the "100 Continue" behavior defined in Section 5.1.1 of [RFC7231] to 699 keep the client connection alive if the response will take some time. 701 When exporting calendar data from a CalDAV server supporting managed 702 attachments, clients SHOULD remove all "MANAGED-ID" property 703 parameters from "ATTACH" properties in the calendar data. Similarly 704 when importing calendar data from another source, clients SHOULD 705 remove any "MANAGED-ID" property parameters on "ATTACH" properties 706 (failure to do so will likely result in the server removing those 707 properties automatically). 709 4. Modifications to iCalendar Syntax 711 4.1. SIZE Property Parameter 713 Parameter Name: SIZE 715 Purpose: To specify the size of an attachment. 717 Format Definition: This property parameter is defined by the 718 following notation: 720 sizeparam = "SIZE" "=" paramtext 721 ; positive integers 723 Description: This property parameter MAY be specified on "ATTACH" 724 properties. It indicates the size in octets of the corresponding 725 attachment data. Since iCalendar integer values are restricted to 726 a maximum value of 2147483647, the current parameter is defined as 727 text to allow an extended range to be used. 729 Example: 731 ATTACH;SIZE=1234:http://attachments.example.com/abcd.txt 733 4.2. FILENAME Property Parameter 735 Parameter Name: FILENAME 737 Purpose: To specify the file name of a managed attachment. 739 Format Definition: This property parameter is defined by the 740 following notation: 742 filenameparam = "FILENAME" "=" paramtext 744 Description: This property parameter MAY be specified on "ATTACH" 745 properties corresponding to managed attachments. Its value 746 provides information on how to construct a filename for storing 747 the attachment data. This parameter is very similar in nature to 748 the Content-Disposition HTTP header "filename" parameter and 749 exposes the same security risks. As a consequence, clients MUST 750 follow the guidelines expressed in Section 4.3 of [RFC6266] when 751 consuming this parameter value. Similarly, servers MUST follow 752 those same guidelines before storing a value. 754 Example: 756 ATTACH;FILENAME=agenda.html:http://attachments.example.c 757 om/rt452S 759 4.3. MANAGED-ID Property Parameter 761 Parameter Name: MANAGED-ID 763 Purpose: To uniquely identify a managed attachment. 765 Format Definition: This property parameter is defined by the 766 following notation: 768 managedidparam = "MANAGED-ID" "=" paramtext 770 Description: This property parameter MUST be specified on "ATTACH" 771 properties corresponding to managed attachments. Its value is 772 generated by the server and uniquely identifies a managed 773 attachment. This property parameter MUST NOT be present in the 774 case of non managed attachments. 776 Example: 778 ATTACH;MANAGED-ID=aUNhbGVuZGFy:http://attachments.example.c 779 om/abcd.txt 781 5. Additional Message Header Fields 783 5.1. Cal-Managed-ID Response Header 785 The Cal-Managed-ID response header provides the value of the MANAGED- 786 ID parameter corresponding to a newly added ATTACH property. It MUST 787 be sent only in response to a successful POST request with an action 788 set to attachment-add. 790 Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext 791 ; "paramtext" is defined in Section 3.1 of [RFC5545] 793 Example: 795 Cal-Managed-ID:aUNhbGVuZGFy 797 6. Additional WebDAV properties 799 6.1. CALDAV:managed-attachments-server-URL property 801 Name: managed-attachments-server-URL 803 Namespace: urn:ietf:params:xml:ns:caldav 805 Purpose: Specifies the server base URI to use when retrieving 806 managed attachments. 808 Protected: This property MUST be protected as only the server can 809 update the value. 811 COPY/MOVE behavior: This property is only defined on a calendar home 812 collection which cannot be moved or copied. 814 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 815 request. 817 Description: This property MAY be defined on a calendar home 818 collection. If present, it contains zero or one DAV:href XML 819 elements. 821 When one DAV:href element is present, its value MUST be an 822 absolute HTTP URI containing only the scheme (i.e. "https") and 823 authority (i.e. host and port) parts . Whenever a managed 824 attachment is to be retrieved via an HTTP GET, the client MUST 825 construct the actual URL of the attachment by substituting the 826 scheme and authority parts of the attachment URI (as stored in the 827 iCalendar "ATTACH" property) with the present WebDAV property 828 value. 830 When no DAV:href element is present, the client MUST substitute 831 the scheme and authority parts of the attachment URI with the 832 scheme and authority part of the calendar home collection absolute 833 URI. 835 In the absence of this property, the client can consider the 836 attachment URI as its actual URL. 838 Definition: 840 842 Example: 844 846 https://attachstore.example.com 847 849 6.2. CALDAV:max-attachment-size property 851 Name: max-attachment-size 853 Namespace: urn:ietf:params:xml:ns:caldav 855 Purpose: Provides a numeric value indicating the maximum attachment 856 size, in octets, that the server is willing to accept when a 857 managed attachment is stored on the server. 859 Protected: MUST be protected as it indicates limits provided by the 860 server. 862 COPY/MOVE behavior: This property value MUST be preserved in COPY 863 and MOVE operations. 865 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 866 request. 868 Description: The CALDAV:max-attachment-size property is used to 869 specify a numeric value that represents the maximum attachment 870 size, in octets, that the server is willing to accept when a 871 managed attachment is stored on the server. The property is 872 defined on the parent collection of the calendar object resource 873 to which the attachment is associated. Any attempt to store a 874 managed attachment exceeding this size MUST result in an error, 875 with the CALDAV:max-attachment-size precondition (Section 3.11.1) 876 being violated. In the absence of this property, the client can 877 assume that the server will allow storing an attachment of any 878 reasonable size. 880 Definition: 882 883 885 Example: 887 102400000 890 6.3. CALDAV:max-attachments-per-resource property 892 Name: max-attachments-per-resource 894 Namespace: urn:ietf:params:xml:ns:caldav 896 Purpose: Provides a numeric value indicating the maximum number of 897 managed attachments across all instances of a calendar object 898 resource stored in a calendar collection. 900 Protected: MUST be protected as it indicates limits provided by the 901 server. 903 COPY/MOVE behavior: This property value MUST be preserved in COPY 904 and MOVE operations. 906 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 907 request. 909 Description: The CALDAV:max-attachments-per-resource property is 910 used to specify a numeric value that represents the maximum number 911 of managed attachments across all instances of a calendar object 912 resource stored in a calendar collection. Non managed attachments 913 are not counted toward that limit. The property is defined on the 914 parent collection of the calendar object resource to which the 915 attachment is associated. Any attempt to add a managed attachment 916 that would cause the calendar resource to exceed this limit MUST 917 result in an error, with the CALDAV:max-attachments-per-resource 918 precondition (Section 3.11.1) being violated. In the absence of 919 this property, the client can assume that the server can handle 920 any number of managed attachments per calendar resource. 922 Definition: 924 925 927 Example: 929 12 933 7. Implementation Status 935 < RFC Editor: before publication please remove this section and the 936 reference to [RFC7942] > 938 This section records the status of known implementations of the 939 protocol defined by this specification at the time of posting of this 940 Internet-Draft, and is based on a proposal described in [RFC7942]. 941 The description of implementations in this section is intended to 942 assist the IETF in its decision processes in progressing drafts to 943 RFCs. Please note that the listing of any individual implementation 944 here does not imply endorsement by the IETF. Furthermore, no effort 945 has been spent to verify the information presented here that was 946 supplied by IETF contributors. This is not intended as, and must not 947 be construed to be, a catalog of available implementations or their 948 features. Readers are advised to note that other implementations may 949 exist. 951 According to [RFC7942], "this will allow reviewers and working groups 952 to assign due consideration to documents that have the benefit of 953 running code, which may serve as evidence of valuable experimentation 954 and feedback that have made the implemented protocols more mature. 955 It is up to the individual working groups to use this information as 956 they see fit". 958 7.1. Calendar and Contacts Server 960 The open source Calendar and Contacts Server [1] project is a 961 standards-compliant server implementing the CalDAV protocol. This 962 production level implementation supports all of the requirements 963 described in this document and successfully interoperates with the 964 Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations 965 described below. This implementation is freely distributable under 966 the terms of the Apache License, Version 2.0 [2]. 968 7.2. Cyrus Server 970 The open source Cyrus Server [3] project is a highly scalable 971 enterprise mail system which also supports calendaring. This 972 production level CalDAV implementation supports all of the 973 requirements described in this document and successfully 974 interoperates with the Apple Calendar and CalDAVTester client 975 implementations described below. This implementation is freely 976 distributable under a BSD style license from Computing Services at 977 Carnegie Mellon University [4]. 979 7.3. Oracle Communications Calendar Server 981 The Oracle Communications Calendar Server [5] project is a standards- 982 compliant, scalable, enterprise-ready calendaring solution. This 983 production level CalDAV implementation supports all of the 984 requirements described in this document and successfully 985 interoperates with the Apple Calendar and CalDAVTester client 986 implementations described below. This implementation is proprietary 987 and available for a free trial and/or purchase from the vendor. 989 7.4. Apple Calendar 991 The widely used Apple Calendar [6] client is a standards-compliant 992 client implementing the CalDAV protocol. This production level 993 implementation supports all the requirements described in this 994 document and successfully interoperates with the 995 Calendar and Contacts Server, Cyrus Server, and 996 Oracle Communications Calendar Server implementations described 997 above. This client implementation is proprietary and is distributed 998 as part of Apple's desktop operating systems. 1000 7.5. BusyCal 1002 BusyCal [7] is a standards-compliant calendar client for MacOS 1003 implementing the CalDAV protocol. This implementation supports all 1004 of the requirements described in this document and successfully 1005 interoperates with the Calendar and Contacts Server and Cyrus Server 1006 implementations described above. This implementation is proprietary 1007 and available for a free trial and/or purchase from the vendor. 1009 7.6. CalDAVTester 1011 CalDAVTester [8] is an open source test and performance application 1012 designed to work with CalDAV servers and tests various aspects of 1013 their protocol handling as well as performance. This widely used 1014 implementation supports all of the requirements described in this 1015 document and successfully interoperates with the server 1016 implementations described above. This implementation is freely 1017 distributable under the terms of the Apache License, Version 2.0 [9]. 1019 7.7. 2Do 1021 2Do [10] is a standards-complient calendar client for iOS which uses 1022 the CalDAV standard for communication. This implementation supports 1023 all of the requirements described in this document and successfully 1024 interoperates with the Calendar and Contacts Server implementation 1025 described above. This implementation is proprietary and available 1026 for purchase from the vendor. 1028 8. Security Considerations 1030 Malicious content could be introduced into the Calendar Server by way 1031 of a managed attachment, and propagated to many end users via 1032 scheduling. Servers SHOULD check managed attachments for malicious 1033 or inappropriate content. Upon detecting of such content, servers 1034 SHOULD remove the attachment, following the rules described in 1035 Section 3.11.5. 1037 9. IANA Considerations 1039 9.1. Parameter Registrations 1041 This specification defines the following new iCalendar property 1042 parameters to be added to the registry defined in Section 8.2.3 of 1043 [RFC5545]: 1045 +--------------------+---------+----------------------+ 1046 | Property Parameter | Status | Reference | 1047 +--------------------+---------+----------------------+ 1048 | SIZE | Current | RFCXXXX, Section 4.1 | 1049 | FILENAME | Current | RFCXXXX, Section 4.2 | 1050 | MANAGED-ID | Current | RFCXXXX, Section 4.3 | 1051 +--------------------+---------+----------------------+ 1053 9.2. Message Header Field Registrations 1055 The message header fields below should be added to the Permanent 1056 Message Header Field Registry (see [RFC3864]). 1058 9.2.1. Cal-Managed-ID 1060 Header field name: Cal-Managed-ID 1062 Applicable protocol: http 1064 Status: standard 1066 Author/Change controller: IETF 1068 Specification document(s): this specification (Section 5.1) 1070 Related information: none 1072 10. Acknowledgments 1074 This specification came about via discussions at the Calendaring and 1075 Scheduling Consortium. Thanks in particular to Mike Douglass and 1076 Eric York. 1078 11. References 1080 11.1. Normative References 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, 1084 DOI 10.17487/RFC2119, March 1997, 1085 . 1087 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1088 Procedures for Message Header Fields", BCP 90, RFC 3864, 1089 DOI 10.17487/RFC3864, September 2004, 1090 . 1092 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties 1093 for Distributed Authoring and Versioning (DAV) 1094 Collections", RFC 4331, DOI 10.17487/RFC4331, February 1095 2006, . 1097 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1098 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1099 DOI 10.17487/RFC4791, March 2007, 1100 . 1102 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1103 Specifications: ABNF", STD 68, RFC 5234, 1104 DOI 10.17487/RFC5234, January 2008, 1105 . 1107 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1108 Scheduling Core Object Specification (iCalendar)", 1109 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1110 . 1112 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1113 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1114 DOI 10.17487/RFC6266, June 2011, 1115 . 1117 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 1118 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 1119 . 1121 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1122 Protocol (HTTP/1.1): Message Syntax and Routing", 1123 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1124 . 1126 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1127 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1128 DOI 10.17487/RFC7231, June 2014, 1129 . 1131 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 1132 DOI 10.17487/RFC7240, June 2014, 1133 . 1135 11.2. Informative References 1137 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1138 Interoperability Protocol (iTIP)", RFC 5546, 1139 DOI 10.17487/RFC5546, December 2009, 1140 . 1142 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1143 Code: The Implementation Status Section", BCP 205, 1144 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1145 . 1147 11.3. URIs 1149 [1] http://calendarserver.org/ 1151 [2] http://www.apache.org/licenses/LICENSE-2.0.html 1153 [3] http://www.cyrusimap.org/ 1155 [4] http://www.cmu.edu/computing/ 1157 [5] http://www.cyrusimap.org/ 1159 [6] http://www.apple.com/macos/ 1161 [7] http://www.busymac.com/busycal/ 1163 [8] http://calendarserver.org/wiki/CalDAVTester 1165 [9] http://www.apache.org/licenses/LICENSE-2.0.html 1167 [10] http://www.2doapp.com/ 1169 Appendix A. Change History (To be removed by RFC Editor before 1170 publication) 1172 Changes in calext-00: 1174 1. Added Murchison as editor. 1176 2. Updated HTTP references to RFC7230 and RFC7231. 1178 3. Updated Prefer header field references to RFC7240. 1180 4. Added Implementation Status section. 1182 5. Minor editorial changes. 1184 Changes in daboo-03: 1186 1. Fixed some examples. 1188 2. Fixed return-representation -> return=representation. 1190 3. Added statement that servers must not allow clients to DELETE 1191 attachments directly. 1193 4. Added new preconditions for valid managed-id values. 1195 5. Filled out Access Control section. 1197 6. Allow servers to not support per-instance attachments and 1198 advertise that fact to clients. 1200 Changes in daboo-02: 1202 1. MANAGED-ID changes on PUT. 1204 2. MTAG has been removed. 1206 3. Error pre-conditions added. 1208 4. Interaction with WebDAV QUOTA discussed. 1210 5. max-attachment-* limits added. 1212 6. Updated references. 1214 7. Removed MUST for specific 2xx codes in favor of generic success 1215 code. 1217 Changes in daboo-01: 1219 1. Tweaked OPTIONS capability wording. 1221 2. Added section on clients expecting 100-Continue for delayed 1222 response. 1224 3. Added text for clean-up and use of HTTP 410 on orphans. 1226 4. Added text on removing "MANAGED-ID" when exporting/importing 1227 calendar data. 1229 5. Added protocol examples. 1231 6. Added MTAG property parameter on ATTACH property 1233 7. Added FILENAME property parameter on ATTACH property 1235 8. "id" query parameter is now "managed-id". 1237 9. Use of Cal-Managed-ID header instead of Location header in 1238 responses. 1240 10. rid query param MUST contain RECURRENCE-ID without any 1241 conversion to UTC (case of floating events). 1243 11. Introduced CALDAV:managed-attachments-server-URL property 1245 12. Made support for Prefer header a MUST for servers. 1247 Appendix B. Example Involving Recurring Events 1249 In the following example, the organizer of a recurring meeting adds 1250 an agenda (HTML attachment) to the corresponding calendar resource. 1251 Attendees of the meeting are granted read access to the newly created 1252 attachment resource. Their own copy of the meeting is updated to 1253 include the new ATTACH property pointing to the attachment resource 1254 and they are notified of the change via their scheduling inbox. 1256 >> Request << 1258 POST /events/65.ics?action=attachment-add HTTP/1.1 1259 Host: cal.example.com 1260 Content-Type: text/html; charset="utf-8" 1261 Content-Disposition:attachment;filename=agenda.html 1262 Content-Length: xxxx 1263 Prefer: return=representation 1265 1266 1267

Agenda

1268

As usual

1269 1270 1272 >> Response << 1273 HTTP/1.1 201 Created 1274 Content-Type: text/calendar; charset="utf-8" 1275 Content-Length: yyyy 1276 Content-Location: http://cal.example.com/events/65.ics 1277 ETag: "123456789-000-111" 1278 Cal-Managed-ID: 97S 1280 BEGIN:VCALENDAR 1281 VERSION:2.0 1282 PRODID:-//Example Corp.//CalDAV Server//EN 1283 BEGIN:VTIMEZONE 1284 LAST-MODIFIED:20040110T032845Z 1285 TZID:America/Montreal 1286 BEGIN:DAYLIGHT 1287 DTSTART:20000404T020000 1288 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1289 TZNAME:EDT 1290 TZOFFSETFROM:-0500 1291 TZOFFSETTO:-0400 1292 END:DAYLIGHT 1293 BEGIN:STANDARD 1294 DTSTART:20001026T020000 1295 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1296 TZNAME:EST 1297 TZOFFSETFROM:-0400 1298 TZOFFSETTO:-0500 1299 END:STANDARD 1300 END:VTIMEZONE 1301 BEGIN:VEVENT 1302 UID:20010712T182145Z-123401@example.com 1303 DTSTAMP:20120201T203412Z 1304 DTSTART;TZID=America/Montreal:20120206T100000 1305 DURATION:PT1H 1306 RRULE:FREQ=WEEKLY 1307 SUMMARY:Planning Meeting 1308 ORGANIZER:mailto:cyrus@example.com 1309 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl 1310 e.com 1311 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam 1312 ple.com 1313 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa 1314 mple.com 1315 ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; 1316 FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R 1317 END:VEVENT 1318 END:VCALENDAR 1319 The organizer has a more specific agenda for the 20th of February 1320 meeting. It is added to that particular instance of the meeting by 1321 specifying the rid parameter. 1323 >> Request << 1325 POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1 1326 Host: cal.example.com 1327 Content-Type: text/html; charset="utf-8" 1328 Content-Disposition:attachment;filename=agenda0220.html 1329 Content-Length: xxxx 1330 Prefer: return=representation 1332 1333 1334

Agenda

1335

Something different, for a change

1336 1337 1339 >> Response << 1341 HTTP/1.1 201 Created 1342 Content-Type: text/calendar; charset="utf-8" 1343 Content-Length: yyyy 1344 Content-Location: http://cal.example.com/events/65.ics 1345 ETag: "123456789-000-222" 1346 Cal-Managed-ID: 33225 1348 BEGIN:VCALENDAR 1349 VERSION:2.0 1350 PRODID:-//Example Corp.//CalDAV Server//EN 1351 BEGIN:VTIMEZONE 1352 LAST-MODIFIED:20040110T032845Z 1353 TZID:America/Montreal 1354 BEGIN:DAYLIGHT 1355 DTSTART:20000404T020000 1356 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1357 TZNAME:EDT 1358 TZOFFSETFROM:-0500 1359 TZOFFSETTO:-0400 1360 END:DAYLIGHT 1361 BEGIN:STANDARD 1362 DTSTART:20001026T020000 1363 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1364 TZNAME:EST 1365 TZOFFSETFROM:-0400 1366 TZOFFSETTO:-0500 1367 END:STANDARD 1368 END:VTIMEZONE 1369 BEGIN:VEVENT 1370 UID:20010712T182145Z-123401@example.com 1371 DTSTAMP:20120201T203412Z 1372 DTSTART;TZID=America/Montreal:20120206T100000 1373 DURATION:PT1H 1374 RRULE:FREQ=WEEKLY 1375 SUMMARY:Planning Meeting 1376 ORGANIZER:mailto:cyrus@example.com 1377 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl 1378 e.com 1379 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam 1380 ple.com 1381 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa 1382 mple.com 1383 ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; 1384 FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R 1385 END:VEVENT 1386 BEGIN:VEVENT 1387 UID:20010712T182145Z-123401@example.com 1388 RECURRENCE-ID;TZID=America/Montreal:20120220T100000 1389 DTSTAMP:20120201T203412Z 1390 DTSTART;TZID=America/Montreal:20120220T100000 1391 DURATION:PT1H 1392 SUMMARY:Planning Meeting 1393 ORGANIZER:mailto:cyrus@example.com 1394 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example. 1395 com 1396 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl 1397 e.com 1398 ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp 1399 le.com 1400 ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=xxxx; 1401 FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225 1402 END:VEVENT 1403 END:VCALENDAR 1405 Authors' Addresses 1406 Cyrus Daboo 1407 Apple Inc. 1408 1 Infinite Loop 1409 Cupertino, CA 95014 1410 USA 1412 Email: cyrus@daboo.name 1413 URI: http://www.apple.com/ 1415 Arnaud Quillaud 1416 Oracle Corporation 1417 180, Avenue de l'Europe 1418 Saint Ismier cedex 38334 1419 France 1421 Email: arnaud.quillaud@oracle.com 1422 URI: http://www.oracle.com/ 1424 Kenneth Murchison (editor) 1425 Carnegie Mellon University 1426 5000 Forbes Avenue 1427 Pittsburgh, PA 15213 1428 USA 1430 Email: murch@andrew.cmu.edu 1431 URI: http://www.cmu.edu/