idnits 2.17.1 draft-ietf-calext-caldav-attachments-01.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 10, 2017) is 2604 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 1177 -- Looks like a reference, but probably isn't: '2' on line 1179 -- Looks like a reference, but probably isn't: '3' on line 1181 -- Looks like a reference, but probably isn't: '4' on line 1183 -- Looks like a reference, but probably isn't: '5' on line 1185 -- Looks like a reference, but probably isn't: '6' on line 1187 -- Looks like a reference, but probably isn't: '7' on line 1189 -- Looks like a reference, but probably isn't: '8' on line 1191 -- Looks like a reference, but probably isn't: '9' on line 1193 -- Looks like a reference, but probably isn't: '10' on line 1195 ** 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 11, 2017 Oracle 6 K. Murchison, Ed. 7 CMU 8 March 10, 2017 10 CalDAV Managed Attachments 11 draft-ietf-calext-caldav-attachments-01 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 September 11, 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. Additional Considerations . . . . . . . . . . . . . . . . 14 67 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16 68 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16 69 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 17 70 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17 71 5. Additional Message Header Fields . . . . . . . . . . . . . . 18 72 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 18 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 . . . . . . . . . . . 24 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . 25 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 Appendix A. Change History (To be removed by RFC Editor before 88 publication) . . . . . . . . . . . . . . . . . . . . 26 89 Appendix B. Example Involving Recurring Events . . . . . . . . . 28 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 field 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 field 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 field 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 field 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 header field 278 describing the media type of the attachment (as required by 279 HTTP). 281 E. The client SHOULD include a Content-Disposition header field 282 [RFC6266] with a "type" parameter set to "attachment", and a 283 "filename" parameter that indicates the name of the 284 attachment. 286 F. The client MAY include a Prefer header field [RFC7240] with 287 the "return=representation" preference to request that the 288 modified calendar object resource be returned as the body of 289 a successful response to the POST request. 291 2. When the server receives the POST request it does the following: 293 A. Validates that any recurrence instances referred to via the 294 "rid" query parameter are valid for the calendar object 295 resource being targeted. 297 B. Stores the supplied attachment data into a resource and 298 generates an appropriate URI for clients to access the 299 resource. 301 C. For each affected recurrence instance in the calendar object 302 resource targeted by the request, the server adds an "ATTACH" 303 property, whose value is the URI of the stored attachment. 304 The "ATTACH" property MUST contain a "MANAGED-ID" parameter 305 whose value is a unique identifier (within the context of the 306 server as a whole). The "ATTACH" property SHOULD contain an 307 "FMTTYPE" parameter whose value matches the Content-Type 308 header field value from the request. The "ATTACH" property 309 SHOULD contain an "FILENAME" parameter whose value matches 310 the Content-Disposition header field "filename" parameter 311 value from the request, taking into account the restrictions 312 expressed in Section 4.2. The "ATTACH" property SHOULD 313 include a "SIZE" parameter whose value represents the size in 314 octets of the attachment. If a specified recurrence instance 315 does not have a matching component in the calendar object 316 resource, then the server MUST modify the calendar object 317 resource to include an overridden component with the 318 appropriate "RECURRENCE-ID" property. 320 D. Upon successful creation of the attachment resource, and 321 modification of the targeted calendar object resource, the 322 server MUST return an appropriate HTTP success status 323 response and include a "Cal-Managed-ID" header field 324 containing the "MANAGED-ID" parameter value of the newly 325 created "ATTACH" property. The client can use the "Cal- 326 Managed-ID" header field value to correlate the attachment 327 with "ATTACH" properties added to the calendar object 328 resource. If the client included a Prefer header field with 329 the "return=representation" preference in the request, the 330 server SHOULD return the modified calendar object resource as 331 the body of the response. Otherwise, the server can expect 332 that the client will reload the calendar object resource with 333 a subsequent GET request to refresh any local cache. 335 In the following example, the client adds a new attachment to a non 336 recurring event and asks the server (via the Prefer [RFC7240] header 337 field) to return the modified version of that event in the response. 339 >> Request << 341 POST /events/64.ics?action=attachment-add HTTP/1.1 342 Host: cal.example.com 343 Content-Type: text/html; charset="utf-8" 344 Content-Disposition:attachment;filename=agenda.html 345 Content-Length: xxxx 346 Prefer: return=representation 348 349 350

Agenda

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

Agenda

480

Discuss attachment draft

481 482 484 >> Response << 486 HTTP/1.1 200 OK 487 Content-Type: text/calendar; charset="utf-8" 488 Content-Length: yyyz 489 Content-Location: http://cal.example.com/events/64.ics 490 Cal-Managed-ID: 98S 491 ETag: "123456789-000-222" 493 BEGIN:VCALENDAR 494 VERSION:2.0 495 PRODID:-//Example Corp.//CalDAV Server//EN 496 BEGIN:VEVENT 497 UID:20010712T182145Z-123401@example.com 498 DTSTAMP:20120201T203412Z 499 DTSTART:20120714T170000Z 500 DTEND:20120715T040000Z 501 SUMMARY:One-off meeting 502 ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=xxxy; 503 FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R 504 END:VEVENT 505 END:VCALENDAR 507 3.6. Removing Attachments via POST 509 To remove an existing attachment from a calendar object, the 510 following occurs: 512 1. The client issues a POST request targeted at the calendar object 513 resource. 515 A. The request-URI will include an "action" query parameter with 516 the value "attachment-remove" (see Section 3.3.1). 518 B. If all recurrence instances are having an attachment removed, 519 the "rid" query parameter is not present in the request-URI. 520 If one or more specific recurrence instances are targeted, 521 then the request-URI will include a "rid" query parameter 522 containing the list of instances (see Section 3.3.2). 524 C. The request-URI will include a "managed-id" query parameter 525 with the value matching that of the "MANAGED-ID" property 526 parameter for the "ATTACH" property being removed (see 527 Section 3.3.3). 529 D. The body of the request will be empty. 531 E. The client MAY include a Prefer header field [RFC7240] with 532 the "return=representation" preference to request that the 533 modified calendar object resource be returned as the body of 534 a successful response to the POST request. 536 2. When the server receives the POST request it does the following: 538 A. Validates that any recurrence instances referred to via the 539 "rid" query parameter are valid for the calendar object 540 resource being targeted. 542 B. Validates that the "managed-id" query parameter is valid for 543 the calendar object resource and specific instances being 544 targeted. 546 C. For each affected recurrence instance in the calendar object 547 resource targeted by the request, the server removes the 548 matching "ATTACH" property. Note that if a specified 549 recurrence instance does not have a matching component in the 550 calendar object resource, then the server MUST modify the 551 calendar object resource to include an overridden component 552 with the appropriate "RECURRENCE-ID" property, and the 553 matching "ATTACH" property removed. This later case is 554 actually valid only if the master component does include the 555 referenced "ATTACH" property. 557 D. If the attachment resource is no longer referenced by any 558 instance of the calendar object resource, the server can 559 delete the attachment resource to free up storage space. 561 E. Upon successful removal of the attachment resource and 562 modification of the targeted calendar object resource, the 563 server MUST return an appropriate HTTP success status 564 response. If the client included a Prefer header field with 565 the "return=representation" preference in the request, the 566 server SHOULD return the modified calendar object resource as 567 the body of the response. Otherwise, the server can expect 568 that the client will reload the calendar object resource with 569 a subsequent GET request to refresh any local cache. 571 In the following example, the client deletes an existing attachment 572 by passing its managed-id in the request. The Prefer [RFC7240] 573 header field is not set in the request so the calendar object 574 resource data is not returned in the response. 576 >> Request << 578 POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1 579 Host: cal.example.com 580 Content-Length: 0 582 >> Response << 584 HTTP/1.1 204 No Content 585 Content-Length: 0 587 3.7. Adding Existing Managed Attachments via PUT 589 Clients can make use of existing managed attachments by adding the 590 corresponding "ATTACH" property to calendar object resources (subject 591 to the restrictions described in Section 3.11.3). When this occurs, 592 servers SHOULD NOT change either the "MANAGED-ID" parameter value or 593 the "ATTACH" property value for any managed attachments - this 594 ensures that clients do not have to download the attachment data 595 again if they already have it cached, because it is used in another 596 calendar resource. 598 3.8. Updating Attachments via PUT 600 Servers MUST NOT allow clients to update attachment data directly via 601 a PUT on the attachment URI (or via any other HTTP method that 602 modifies content). Instead, attachments can only be updated via use 603 of POST requests on the calendar data. 605 3.9. Removing Attachments via PUT 607 Clients can remove attachments by simply re-writing the calendar 608 object resource data to remove the appropriate "ATTACH" properties. 609 Servers MUST NOT allow clients to delete attachments directly via a 610 DELETE request on the attachment URI. 612 3.10. Retrieving Attachments 614 Clients retrieve attachments by issuing an HTTP GET request using the 615 value of the corresponding "ATTACH" property as the request-URI, 616 taking into account the substitution mechanism associated with the 617 "CALDAV:managed-attachments-server-URL" property (see Section 6.1). 619 3.11. Additional Considerations 621 3.11.1. Error Handling 623 This specification creates additional preconditions for the POST 624 method. 626 The new preconditions are: 628 (CALDAV:max-attachment-size): The attachment submitted in the POST 629 request MUST have an octet size less than or equal to the value of 630 the CALDAV:max-attachment-size property value (Section 6.2) on the 631 calendar collection of the target calendar resource; 633 (CALDAV:max-attachments-per-resource): The addition of the 634 attachment submitted in the POST request MUST result in the target 635 calendar resource having a number of managed attachments less than 636 or equal to the value of the CALDAV:max-attachments-per-resource 637 property value (Section 6.3) on the calendar collection of the 638 target calendar resource; 640 (CALDAV:valid-managed-id): The managed-id query parameter in the 641 POST request MUST contain a value corresponding to a "MANAGED-ID" 642 property parameter value in the iCalendar data targeted by the 643 request. 645 A POST request to add, modify, or delete a managed attachment results 646 in an implicit modification of the targeted calendar resource 647 (equivalent of a PUT). As a consequence, clients should also be 648 prepared to handle preconditions associated with this implicit PUT. 649 This includes (but is not limited to): 651 (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) 652 (DAV:quota-not-exceeded) (from Section 6 of [RFC4331]) 654 (DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) 656 A PUT request to add or modify and existing calendar object resource 657 can make reference to an existing managed attachment. The following 658 new preconditions is defined: 660 (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property 661 parameter value in the iCalendar data in the PUT request is not 662 valid (e.g., does not match any existing managed attachment). 664 3.11.2. Quotas 666 The WebDAV Quotas [RFC4331] specification defines two live WebDAV 667 properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to 668 communicate storage quota information to clients. Server 669 implementations MAY choose to include managed attachments sizes when 670 calculating the amount of storage used by a particular resource. 672 3.11.3. Access Control 674 Access to the managed attachments store in a calendar object resource 675 SHOULD be restricted to only those calendar users who have access to 676 that calendar object either directly, or indirectly (via being an 677 attendee who would receive a scheduling message). 679 When accessing a managed attachment, clients SHOULD be prepared to 680 authenticate with the server storing the attachment resource. The 681 credentials required to access the managed attachment store could be 682 different from the ones used to access the CalDAV server. 684 This specification only allows organizers of scheduled events to add 685 managed attachments. Servers MUST prevent attendees of scheduled 686 events from adding, updating or removing managed attachments. In 687 addition, the server MUST prevent a calendar user from re-using a 688 managed attachment (based on its managed-id value), unless that user 689 is the one who originally created the managed attachment. 691 3.11.4. Redirects 693 For POST requests that add or update attachment data, the server MAY 694 issue an HTTP redirect to require the client to re-issue the POST 695 request using a different request-URI. As a result, it is always 696 best for clients to use the "100-continue" expectation defined in 697 Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a 698 redirect does occur, the client does not needlessly send the 699 attachment data. 701 3.11.5. Automatic Clean-up by servers 703 Servers MAY automatically remove attachment data, for example to 704 regain the storage taken by unused attachments, or as the result of a 705 virus scanning. When doing so they SHOULD NOT modify calendar data 706 referencing those attachments. Instead they SHOULD respond with "410 707 (Gone)" to any request on the removed attachment URI. 709 3.11.6. Sending Scheduling Messages with Attachments 711 When a managed attachment is added, updated or removed from a 712 calendar object resource, the server MUST ensure that a scheduling 713 message is sent to update any attendees with the changes, as per 714 [RFC6638]. 716 3.11.7. Other Client Considerations 718 Clients can expect servers to take a while to respond to POST 719 requests that include large attachment bodies. Servers SHOULD use 720 the "102 (Processing)" interim response defined in Section 10.1 of 721 [RFC2518] to keep the client connection alive if the final response 722 will take some time. 724 When exporting calendar data from a CalDAV server supporting managed 725 attachments, clients SHOULD remove all "MANAGED-ID" property 726 parameters from "ATTACH" properties in the calendar data. Similarly 727 when importing calendar data from another source, clients SHOULD 728 remove any "MANAGED-ID" property parameters on "ATTACH" properties 729 (failure to do so will likely result in the server removing those 730 properties automatically). 732 4. Modifications to iCalendar Syntax 734 4.1. SIZE Property Parameter 736 Parameter Name: SIZE 738 Purpose: To specify the size of an attachment. 740 Format Definition: This property parameter is defined by the 741 following notation: 743 sizeparam = "SIZE" "=" paramtext 744 ; positive integers 746 Description: This property parameter MAY be specified on "ATTACH" 747 properties. It indicates the size in octets of the corresponding 748 attachment data. Since iCalendar integer values are restricted to 749 a maximum value of 2147483647, the current parameter is defined as 750 text to allow an extended range to be used. 752 Example: 754 ATTACH;SIZE=1234:http://attachments.example.com/abcd.txt 756 4.2. FILENAME Property Parameter 758 Parameter Name: FILENAME 760 Purpose: To specify the file name of a managed attachment. 762 Format Definition: This property parameter is defined by the 763 following notation: 765 filenameparam = "FILENAME" "=" paramtext 767 Description: This property parameter MAY be specified on "ATTACH" 768 properties corresponding to managed attachments. Its value 769 provides information on how to construct a filename for storing 770 the attachment data. This parameter is very similar in nature to 771 the Content-Disposition HTTP header field "filename" parameter and 772 exposes the same security risks. As a consequence, clients MUST 773 follow the guidelines expressed in Section 4.3 of [RFC6266] when 774 consuming this parameter value. Similarly, servers MUST follow 775 those same guidelines before storing a value. 777 Example: 779 ATTACH;FILENAME=agenda.html:http://attachments.example.c 780 om/rt452S 782 4.3. MANAGED-ID Property Parameter 784 Parameter Name: MANAGED-ID 786 Purpose: To uniquely identify a managed attachment. 788 Format Definition: This property parameter is defined by the 789 following notation: 791 managedidparam = "MANAGED-ID" "=" paramtext 793 Description: This property parameter MUST be specified on "ATTACH" 794 properties corresponding to managed attachments. Its value is 795 generated by the server and uniquely identifies a managed 796 attachment. This property parameter MUST NOT be present in the 797 case of non-managed attachments. 799 Example: 801 ATTACH;MANAGED-ID=aUNhbGVuZGFy:http://attachments.example.c 802 om/abcd.txt 804 5. Additional Message Header Fields 806 5.1. Cal-Managed-ID Response Header Field 808 The Cal-Managed-ID response header field provides the value of the 809 MANAGED-ID parameter corresponding to a newly added ATTACH property. 810 It MUST be sent only in response to a successful POST request with an 811 action set to attachment-add or attachment-update. 813 Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext 814 ; "paramtext" is defined in Section 3.1 of [RFC5545] 816 Example: 818 Cal-Managed-ID:aUNhbGVuZGFy 820 6. Additional WebDAV properties 822 6.1. CALDAV:managed-attachments-server-URL property 824 Name: managed-attachments-server-URL 826 Namespace: urn:ietf:params:xml:ns:caldav 828 Purpose: Specifies the server base URI to use when retrieving 829 managed attachments. 831 Protected: This property MUST be protected as only the server can 832 update the value. 834 COPY/MOVE behavior: This property is only defined on a calendar home 835 collection which cannot be moved or copied. 837 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 838 request. 840 Description: This property MAY be defined on a calendar home 841 collection. If present, it contains zero or one DAV:href XML 842 elements. 844 When one DAV:href element is present, its value MUST be an 845 absolute HTTP URI containing only the scheme (i.e. "https") and 846 authority (i.e. host and port) parts . Whenever a managed 847 attachment is to be retrieved via an HTTP GET, the client MUST 848 construct the actual URL of the attachment by substituting the 849 scheme and authority parts of the attachment URI (as stored in the 850 iCalendar "ATTACH" property) with the present WebDAV property 851 value. 853 When no DAV:href element is present, the client MUST substitute 854 the scheme and authority parts of the attachment URI with the 855 scheme and authority part of the calendar home collection absolute 856 URI. 858 In the absence of this property, the client can consider the 859 attachment URI as its actual URL. 861 Definition: 863 865 Example: 867 869 https://attachstore.example.com 870 872 6.2. CALDAV:max-attachment-size property 874 Name: max-attachment-size 876 Namespace: urn:ietf:params:xml:ns:caldav 878 Purpose: Provides a numeric value indicating the maximum attachment 879 size, in octets, that the server is willing to accept when a 880 managed attachment is stored on the server. 882 Protected: MUST be protected as it indicates limits provided by the 883 server. 885 COPY/MOVE behavior: This property value MUST be preserved in COPY 886 and MOVE operations. 888 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 889 request. 891 Description: The CALDAV:max-attachment-size property is used to 892 specify a numeric value that represents the maximum attachment 893 size, in octets, that the server is willing to accept when a 894 managed attachment is stored on the server. The property is 895 defined on the parent collection of the calendar object resource 896 to which the attachment is associated. Any attempt to store a 897 managed attachment exceeding this size MUST result in an error, 898 with the CALDAV:max-attachment-size precondition (Section 3.11.1) 899 being violated. In the absence of this property, the client can 900 assume that the server will allow storing an attachment of any 901 reasonable size. 903 Definition: 905 906 908 Example: 910 102400000 913 6.3. CALDAV:max-attachments-per-resource property 915 Name: max-attachments-per-resource 917 Namespace: urn:ietf:params:xml:ns:caldav 919 Purpose: Provides a numeric value indicating the maximum number of 920 managed attachments across all instances of a calendar object 921 resource stored in a calendar collection. 923 Protected: MUST be protected as it indicates limits provided by the 924 server. 926 COPY/MOVE behavior: This property value MUST be preserved in COPY 927 and MOVE operations. 929 allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop 930 request. 932 Description: The CALDAV:max-attachments-per-resource property is 933 used to specify a numeric value that represents the maximum number 934 of managed attachments across all instances of a calendar object 935 resource stored in a calendar collection. Non-managed attachments 936 are not counted toward that limit. The property is defined on the 937 parent collection of the calendar object resource to which the 938 attachment is associated. Any attempt to add a managed attachment 939 that would cause the calendar resource to exceed this limit MUST 940 result in an error, with the CALDAV:max-attachments-per-resource 941 precondition (Section 3.11.1) being violated. In the absence of 942 this property, the client can assume that the server can handle 943 any number of managed attachments per calendar resource. 945 Definition: 947 948 950 Example: 952 12 956 7. Implementation Status 958 < RFC Editor: before publication please remove this section and the 959 reference to [RFC7942] > 961 This section records the status of known implementations of the 962 protocol defined by this specification at the time of posting of this 963 Internet-Draft, and is based on a proposal described in [RFC7942]. 964 The description of implementations in this section is intended to 965 assist the IETF in its decision processes in progressing drafts to 966 RFCs. Please note that the listing of any individual implementation 967 here does not imply endorsement by the IETF. Furthermore, no effort 968 has been spent to verify the information presented here that was 969 supplied by IETF contributors. This is not intended as, and must not 970 be construed to be, a catalog of available implementations or their 971 features. Readers are advised to note that other implementations may 972 exist. 974 According to [RFC7942], "this will allow reviewers and working groups 975 to assign due consideration to documents that have the benefit of 976 running code, which may serve as evidence of valuable experimentation 977 and feedback that have made the implemented protocols more mature. 978 It is up to the individual working groups to use this information as 979 they see fit". 981 7.1. Calendar and Contacts Server 983 The open source Calendar and Contacts Server [1] project is a 984 standards-compliant server implementing the CalDAV protocol. This 985 production level implementation supports all of the requirements 986 described in this document and successfully interoperates with the 987 Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations 988 described below. This implementation is freely distributable under 989 the terms of the Apache License, Version 2.0 [2]. 991 7.2. Cyrus Server 993 The open source Cyrus Server [3] project is a highly scalable 994 enterprise mail system which also supports calendaring. This 995 production level CalDAV implementation supports all of the 996 requirements described in this document and successfully 997 interoperates with the Apple Calendar and CalDAVTester client 998 implementations described below. This implementation is freely 999 distributable under a BSD style license from Computing Services at 1000 Carnegie Mellon University [4]. 1002 7.3. Oracle Communications Calendar Server 1004 The Oracle Communications Calendar Server [5] project is a standards- 1005 compliant, scalable, enterprise-ready calendaring solution. This 1006 production level CalDAV implementation supports all of the 1007 requirements described in this document and successfully 1008 interoperates with the Apple Calendar and CalDAVTester client 1009 implementations described below. This implementation is proprietary 1010 and available for a free trial and/or purchase from the vendor. 1012 7.4. Apple Calendar 1014 The widely used Apple Calendar [6] client is a standards-compliant 1015 client implementing the CalDAV protocol. This production level 1016 implementation supports all the requirements described in this 1017 document and successfully interoperates with the 1018 Calendar and Contacts Server, Cyrus Server, and 1019 Oracle Communications Calendar Server implementations described 1020 above. This client implementation is proprietary and is distributed 1021 as part of Apple's desktop operating systems. 1023 7.5. BusyCal 1025 BusyCal [7] is a standards-compliant calendar client for MacOS 1026 implementing the CalDAV protocol. This implementation supports all 1027 of the requirements described in this document and successfully 1028 interoperates with the Calendar and Contacts Server and Cyrus Server 1029 implementations described above. This implementation is proprietary 1030 and available for a free trial and/or purchase from the vendor. 1032 7.6. CalDAVTester 1034 CalDAVTester [8] is an open source test and performance application 1035 designed to work with CalDAV servers and tests various aspects of 1036 their protocol handling as well as performance. This widely used 1037 implementation supports all of the requirements described in this 1038 document and successfully interoperates with the server 1039 implementations described above. This implementation is freely 1040 distributable under the terms of the Apache License, Version 2.0 [9]. 1042 7.7. 2Do 1044 2Do [10] is a standards-complient calendar client for iOS which uses 1045 the CalDAV standard for communication. This implementation supports 1046 all of the requirements described in this document and successfully 1047 interoperates with the Calendar and Contacts Server implementation 1048 described above. This implementation is proprietary and available 1049 for purchase from the vendor. 1051 8. Security Considerations 1053 Malicious content could be introduced into the Calendar Server by way 1054 of a managed attachment, and propagated to many end users via 1055 scheduling. Servers SHOULD check managed attachments for malicious 1056 or inappropriate content. Upon detecting of such content, servers 1057 SHOULD remove the attachment, following the rules described in 1058 Section 3.11.5. 1060 9. IANA Considerations 1062 9.1. Parameter Registrations 1064 This specification defines the following new iCalendar property 1065 parameters to be added to the registry defined in Section 8.2.3 of 1066 [RFC5545]: 1068 +--------------------+---------+----------------------+ 1069 | Property Parameter | Status | Reference | 1070 +--------------------+---------+----------------------+ 1071 | SIZE | Current | RFCXXXX, Section 4.1 | 1072 | FILENAME | Current | RFCXXXX, Section 4.2 | 1073 | MANAGED-ID | Current | RFCXXXX, Section 4.3 | 1074 +--------------------+---------+----------------------+ 1076 9.2. Message Header Field Registrations 1078 The message header fields below should be added to the Permanent 1079 Message Header Field Registry (see [RFC3864]). 1081 9.2.1. Cal-Managed-ID 1083 Header field name: Cal-Managed-ID 1085 Applicable protocol: http 1087 Status: standard 1089 Author/Change controller: IETF 1091 Specification document(s): this specification (Section 5.1) 1093 Related information: none 1095 10. Acknowledgments 1097 This specification came about via discussions at the Calendaring and 1098 Scheduling Consortium. Thanks in particular to Mike Douglass and 1099 Eric York. 1101 11. References 1103 11.1. Normative References 1105 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1106 Requirement Levels", BCP 14, RFC 2119, 1107 DOI 10.17487/RFC2119, March 1997, 1108 . 1110 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 1111 Jensen, "HTTP Extensions for Distributed Authoring -- 1112 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 1113 . 1115 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1116 Procedures for Message Header Fields", BCP 90, RFC 3864, 1117 DOI 10.17487/RFC3864, September 2004, 1118 . 1120 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties 1121 for Distributed Authoring and Versioning (DAV) 1122 Collections", RFC 4331, DOI 10.17487/RFC4331, February 1123 2006, . 1125 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 1126 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 1127 DOI 10.17487/RFC4791, March 2007, 1128 . 1130 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1131 Specifications: ABNF", STD 68, RFC 5234, 1132 DOI 10.17487/RFC5234, January 2008, 1133 . 1135 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 1136 Scheduling Core Object Specification (iCalendar)", 1137 RFC 5545, DOI 10.17487/RFC5545, September 2009, 1138 . 1140 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field 1141 in the Hypertext Transfer Protocol (HTTP)", RFC 6266, 1142 DOI 10.17487/RFC6266, June 2011, 1143 . 1145 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 1146 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 1147 . 1149 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1150 Protocol (HTTP/1.1): Message Syntax and Routing", 1151 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1152 . 1154 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1155 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1156 DOI 10.17487/RFC7231, June 2014, 1157 . 1159 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 1160 DOI 10.17487/RFC7240, June 2014, 1161 . 1163 11.2. Informative References 1165 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 1166 Interoperability Protocol (iTIP)", RFC 5546, 1167 DOI 10.17487/RFC5546, December 2009, 1168 . 1170 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1171 Code: The Implementation Status Section", BCP 205, 1172 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1173 . 1175 11.3. URIs 1177 [1] http://calendarserver.org/ 1179 [2] http://www.apache.org/licenses/LICENSE-2.0.html 1181 [3] http://www.cyrusimap.org/ 1183 [4] http://www.cmu.edu/computing/ 1185 [5] http://www.cyrusimap.org/ 1187 [6] http://www.apple.com/macos/ 1189 [7] http://www.busymac.com/busycal/ 1191 [8] http://calendarserver.org/wiki/CalDAVTester 1193 [9] http://www.apache.org/licenses/LICENSE-2.0.html 1195 [10] http://www.2doapp.com/ 1197 Appendix A. Change History (To be removed by RFC Editor before 1198 publication) 1200 Changes in calext-01: 1202 1. Changed all instances of "header" to "header field". 1204 2. Reworked wording of Prefer header field handling. 1206 3. Switched to recommending 102 (Processing) interim response to 1207 keep the client connection alive. 1209 4. Fixed description of Cal-Managed-ID response header field to 1210 state that it is also required in responses to successful 1211 attachment-update. 1213 5. Minor editorial changes. 1215 Changes in calext-00: 1217 1. Added Murchison as editor. 1219 2. Updated HTTP references to RFC7230 and RFC7231. 1221 3. Updated Prefer header field references to RFC7240. 1223 4. Added Implementation Status section. 1225 5. Minor editorial changes. 1227 Changes in daboo-03: 1229 1. Fixed some examples. 1231 2. Fixed return-representation -> return=representation. 1233 3. Added statement that servers must not allow clients to DELETE 1234 attachments directly. 1236 4. Added new preconditions for valid managed-id values. 1238 5. Filled out Access Control section. 1240 6. Allow servers to not support per-instance attachments and 1241 advertise that fact to clients. 1243 Changes in daboo-02: 1245 1. MANAGED-ID changes on PUT. 1247 2. MTAG has been removed. 1249 3. Error pre-conditions added. 1251 4. Interaction with WebDAV QUOTA discussed. 1253 5. max-attachment-* limits added. 1255 6. Updated references. 1257 7. Removed MUST for specific 2xx codes in favor of generic success 1258 code. 1260 Changes in daboo-01: 1262 1. Tweaked OPTIONS capability wording. 1264 2. Added section on clients expecting 100-Continue for delayed 1265 response. 1267 3. Added text for clean-up and use of HTTP 410 on orphans. 1269 4. Added text on removing "MANAGED-ID" when exporting/importing 1270 calendar data. 1272 5. Added protocol examples. 1274 6. Added MTAG property parameter on ATTACH property 1276 7. Added FILENAME property parameter on ATTACH property 1278 8. "id" query parameter is now "managed-id". 1280 9. Use of Cal-Managed-ID header instead of Location header in 1281 responses. 1283 10. rid query param MUST contain RECURRENCE-ID without any 1284 conversion to UTC (case of floating events). 1286 11. Introduced CALDAV:managed-attachments-server-URL property 1288 12. Made support for Prefer header a MUST for servers. 1290 Appendix B. Example Involving Recurring Events 1292 In the following example, the organizer of a recurring meeting adds 1293 an agenda (HTML attachment) to the corresponding calendar resource. 1294 Attendees of the meeting are granted read access to the newly created 1295 attachment resource. Their own copy of the meeting is updated to 1296 include the new ATTACH property pointing to the attachment resource 1297 and they are notified of the change via their scheduling inbox. 1299 >> Request << 1301 POST /events/65.ics?action=attachment-add HTTP/1.1 1302 Host: cal.example.com 1303 Content-Type: text/html; charset="utf-8" 1304 Content-Disposition:attachment;filename=agenda.html 1305 Content-Length: xxxx 1306 Prefer: return=representation 1308 1309 1310

Agenda

1311

As usual

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

Agenda

1378

Something different, for a change

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