draft-ietf-calext-caldav-attachments-02.txt   draft-ietf-calext-caldav-attachments-03.txt 
Calendering Extensions C. Daboo Calendering Extensions C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track A. Quillaud Intended status: Informational A. Quillaud
Expires: September 14, 2017 Oracle Expires: January 24, 2018 Oracle
K. Murchison, Ed. K. Murchison, Ed.
CMU FastMail
March 13, 2017 July 23, 2017
CalDAV Managed Attachments CalDAV Managed Attachments
draft-ietf-calext-caldav-attachments-02 draft-ietf-calext-caldav-attachments-03
Abstract Abstract
This specification defines an extension to the calendar access This specification defines an extension to the calendar access
protocol (CalDAV) to allow attachments associated with iCalendar data protocol (CalDAV) to allow attachments associated with iCalendar data
to be stored and managed on the server. to be stored and managed on the server.
This specification documents existing code deployed by multiple
vendors. It is published as an Informational specification rather
than Standards-Track due to its non-standard method of updating an
existing resource via HTTP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Discovering Support for Managed Attachments . . . . . . . 4 3.2. Discovering Support for Managed Attachments . . . . . . . 4
3.3. POST Request for Managing Attachments . . . . . . . . . . 4 3.3. POST Request for Managing Attachments . . . . . . . . . . 5
3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6 3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6
3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9 3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9
3.6. Removing Attachments via POST . . . . . . . . . . . . . . 11 3.6. Removing Attachments via POST . . . . . . . . . . . . . . 12
3.7. Adding Existing Managed Attachments via PUT . . . . . . . 13 3.7. Adding Existing Managed Attachments via PUT . . . . . . . 14
3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 13 3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 14
3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14 3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14
3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14
3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 15
3.12. Additional Considerations . . . . . . . . . . . . . . . . 15 3.12. Additional Considerations . . . . . . . . . . . . . . . . 16
4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 17
4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 17
4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 17 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 18
4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 18
5. Additional Message Header Fields . . . . . . . . . . . . . . 18 5. Additional Message Header Fields . . . . . . . . . . . . . . 19
5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 18 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 19
6. Additional WebDAV properties . . . . . . . . . . . . . . . . 18 6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 19
6.1. CALDAV:managed-attachments-server-URL property . . . . . 18 6.1. CALDAV:managed-attachments-server-URL property . . . . . 19
6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 19 6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 20
6.3. CALDAV:max-attachments-per-resource property . . . . . . 20 6.3. CALDAV:max-attachments-per-resource property . . . . . . 21
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 23 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 24
9.2. Message Header Field Registrations . . . . . . . . . . . 24 9.2. Message Header Field Registrations . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 26 publication) . . . . . . . . . . . . . . . . . . . . 27
Appendix B. Example Involving Recurring Events . . . . . . . . . 28 Appendix B. Example Involving Recurring Events . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The iCalendar [RFC5545] data format is used to represent calendar The iCalendar [RFC5545] data format is used to represent calendar
data and is used with iTIP [RFC5546] to handle scheduling operations data and is used with iTIP [RFC5546] to handle scheduling operations
between calendar users. between calendar users.
[RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP
[RFC7230], for accessing calendar data stored on a server. [RFC7230], for accessing calendar data stored on a server.
skipping to change at page 4, line 4 skipping to change at page 4, line 4
used by iCalendar [RFC5545]. Any syntax elements shown below that used by iCalendar [RFC5545]. Any syntax elements shown below that
are not explicitly defined in this specification come from iCalendar are not explicitly defined in this specification come from iCalendar
[RFC5545]. [RFC5545].
3. Overview 3. Overview
There are four main operations a client needs to do with attachments There are four main operations a client needs to do with attachments
for calendar data: add, update, remove, and retrieve. The first for calendar data: add, update, remove, and retrieve. The first
three operations are carried out by the client issuing an HTTP POST three operations are carried out by the client issuing an HTTP POST
request on the calendar object resource to which the attachment is request on the calendar object resource to which the attachment is
associated and specifying the appropriate "action" query parameter. associated and specifying the appropriate "action" query parameter
In the case of the remove operation, the client can alternatively (see Section 3.3). In the case of the remove operation, the client
directly update the calendar object resource and remove the relevant can alternatively directly update the calendar object resource and
"ATTACH" properties. The retrieve operation is accomplished by remove the relevant "ATTACH" properties (see Section 3.9). The
simply issuing an HTTP GET request targeting the attachment URI retrieve operation is accomplished by simply issuing an HTTP GET
specified by the calendar resource's "ATTACH" property. request targeting the attachment URI specified by the calendar
resource's "ATTACH" property (see Section 3.10).
iCalendar data stored in a CalDAV calendar object resource can iCalendar data stored in a CalDAV calendar object resource can
contain multiple components when recurrences are involved. In such a contain multiple components when recurrences are involved. In such a
situation, the client needs to be able to target a specific situation, the client needs to be able to target a specific
recurrence instance or multiple instances when adding or deleting recurrence instance or multiple instances when adding or deleting
attachments. As a result, the POST request needs to provide a way attachments. As a result, the POST request needs to provide a way
for the client to specify which recurrence instances should be for the client to specify which recurrence instances should be
targeted for the attachment operation. This is accomplished through targeted for the attachment operation. This is accomplished through
use of additional query parameters on the POST request-URI. use of additional query parameters on the POST request-URI.
3.1. Requirements 3.1. Requirements
A server that supports the features described in this specification A server that supports the features described in this specification
is REQUIRED to support the CalDAV "calendar-access" [RFC4791] is REQUIRED to support the CalDAV "calendar-access" [RFC4791]
features. features.
In addition, such a server MUST support the "return=representation" In addition, such a server SHOULD support the "return=representation"
Prefer header field value [RFC7240] on successful HTTP PUT and POST Prefer header field [RFC7240] preference on successful HTTP PUT and
requests targeting existing calendar object resources, by returning POST requests targeting existing calendar object resources, by
the new representation of that calendar resource (including its new returning the new representation of that calendar resource (including
ETag header field value) in the response. its new ETag header field value) in the response.
3.2. Discovering Support for Managed Attachments 3.2. Discovering Support for Managed Attachments
A server supporting the features described in this specification MUST A server supporting the features described in this specification MUST
include "calendar-managed-attachments" as a field in the DAV response include "calendar-managed-attachments" as a field in the DAV response
header field from an OPTIONS request on a calendar home collection. header field from an OPTIONS request on a calendar home collection.
A server might choose to not support storing managed attachments on a A server might choose to not support storing managed attachments on a
per-recurrence instance basis (i.e., they can only be added to all per-recurrence instance basis (i.e., they can only be added to all
instances as a whole). If that is the case, the server MUST include instances as a whole). If that is the case, the server MUST include
skipping to change at page 16, line 13 skipping to change at page 17, line 5
attachment data. attachment data.
3.12.4. Processing Time 3.12.4. Processing Time
Clients can expect servers to take a while to respond to POST Clients can expect servers to take a while to respond to POST
requests that include large attachment bodies. Servers SHOULD use requests that include large attachment bodies. Servers SHOULD use
the "102 (Processing)" interim response defined in Section 10.1 of the "102 (Processing)" interim response defined in Section 10.1 of
[RFC2518] to keep the client connection alive if the POST request [RFC2518] to keep the client connection alive if the POST request
will take significant time to complete. will take significant time to complete.
3.12.5. Automatic Clean-up by servers 3.12.5. Automatic Clean-Up by Servers
Servers MAY automatically remove attachment data, for example to Servers MAY automatically remove attachment data, for example to
regain the storage taken by unused attachments, or as the result of a regain the storage taken by unused attachments, or as the result of a
virus scanning. When doing so they SHOULD NOT modify calendar data virus scanning. When doing so they SHOULD NOT modify calendar data
referencing those attachments. Instead they SHOULD respond with "410 referencing those attachments. Instead they SHOULD respond with "410
(Gone)" to any request on the removed attachment URI. (Gone)" to any request on the removed attachment URI.
3.12.6. Sending Scheduling Messages with Attachments 3.12.6. Sending Scheduling Messages with Attachments
When a managed attachment is added, updated or removed from a When a managed attachment is added, updated or removed from a
skipping to change at page 18, line 31 skipping to change at page 19, line 21
It MUST be sent only in response to a successful POST request with an It MUST be sent only in response to a successful POST request with an
action set to attachment-add or attachment-update. action set to attachment-add or attachment-update.
Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext Cal-Managed-ID = "Cal-Managed-ID" ":" paramtext
; "paramtext" is defined in Section 3.1 of [RFC5545] ; "paramtext" is defined in Section 3.1 of [RFC5545]
Example: Example:
Cal-Managed-ID:aUNhbGVuZGFy Cal-Managed-ID:aUNhbGVuZGFy
6. Additional WebDAV properties 6. Additional WebDAV Properties
6.1. CALDAV:managed-attachments-server-URL property 6.1. CALDAV:managed-attachments-server-URL property
Name: managed-attachments-server-URL Name: managed-attachments-server-URL
Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies the server base URI to use when retrieving Purpose: Specifies the server base URI to use when retrieving
managed attachments. managed attachments.
skipping to change at page 26, line 10 skipping to change at page 26, line 45
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546, Interoperability Protocol (iTIP)", RFC 5546,
DOI 10.17487/RFC5546, December 2009, DOI 10.17487/RFC5546, December 2009,
<http://www.rfc-editor.org/info/rfc5546>. <http://www.rfc-editor.org/info/rfc5546>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<http://www.rfc-editor.org/info/rfc7942>. <http://www.rfc-editor.org/info/rfc7942>.
[RFC8144] Murchison, K., "Use of the Prefer Header Field in Web
Distributed Authoring and Versioning (WebDAV)", RFC 8144,
DOI 10.17487/RFC8144, April 2017,
<http://www.rfc-editor.org/info/rfc8144>.
11.3. URIs 11.3. URIs
[1] http://calendarserver.org/ [1] http://calendarserver.org/
[2] http://www.apache.org/licenses/LICENSE-2.0.html [2] http://www.apache.org/licenses/LICENSE-2.0.html
[3] http://www.cyrusimap.org/ [3] http://www.cyrusimap.org/
[4] http://www.cmu.edu/computing/ [4] http://www.cmu.edu/computing/
skipping to change at page 26, line 35 skipping to change at page 27, line 30
[8] http://calendarserver.org/wiki/CalDAVTester [8] http://calendarserver.org/wiki/CalDAVTester
[9] http://www.apache.org/licenses/LICENSE-2.0.html [9] http://www.apache.org/licenses/LICENSE-2.0.html
[10] http://www.2doapp.com/ [10] http://www.2doapp.com/
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) publication)
Changes in calext-03:
1. Changed to Informational based on feedback regarding non-standard
method of updating an existing resource.
2. Added references to sub-sections in Overview.
3. Made support for Prefer header field a SHOULD for servers.
4. Expanded recurring event examples to use conditional requests and
to include the Expect header field.
5. Minor editorial changes.
Changes in calext-02: Changes in calext-02:
1. Moved "Error Handling" into its own sub-section. 1. Moved "Error Handling" into its own sub-section.
2. Split "Other Client Considerations" into "Processing Time" and 2. Split "Other Client Considerations" into "Processing Time" and
"Migrating Calendar Data". "Migrating Calendar Data".
Changes in calext-01: Changes in calext-01:
1. Changed all instances of "header" to "header field". 1. Changed all instances of "header" to "header field".
skipping to change at page 28, line 40 skipping to change at page 29, line 46
10. rid query param MUST contain RECURRENCE-ID without any 10. rid query param MUST contain RECURRENCE-ID without any
conversion to UTC (case of floating events). conversion to UTC (case of floating events).
11. Introduced CALDAV:managed-attachments-server-URL property 11. Introduced CALDAV:managed-attachments-server-URL property
12. Made support for Prefer header a MUST for servers. 12. Made support for Prefer header a MUST for servers.
Appendix B. Example Involving Recurring Events Appendix B. Example Involving Recurring Events
In the following example, the organizer of a recurring meeting adds In the following example, the organizer of a recurring meeting makes
an agenda (HTML attachment) to the corresponding calendar resource. an unsuccessful attempt to add an agenda (HTML attachment) to the
Attendees of the meeting are granted read access to the newly created corresponding calendar resource with a conditional request. Note
that the client includes both the Expect and Prefer header fields in
the request, thereby preventing itself from needlessly sending the
attachment data, and requesting that the current resource be returned
in the failure response (see Section 3.2 of [RFC8144]).
>> Request <<
POST /events/65.ics?action=attachment-add HTTP/1.1
Host: cal.example.com
Content-Type: text/html; charset="utf-8"
Content-Disposition: attachment;filename=agenda.html
Content-Length: xxxx
If-Match: "abcdefg-000"
Expect: 100-continue
Prefer: return=representation
>> Final Response <<
HTTP/1.1 412 Precondition Failed
Content-Type: text/calendar; charset="utf-8"
Content-Length: yyyy
Content-Location: http://cal.example.com/events/65.ics
ETag: "123456789-000-000"
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z
TZID:America/Montreal
BEGIN:DAYLIGHT
DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20001026T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z
DTSTART;TZID=America/Montreal:20120206T100000
DURATION:PT1H
RRULE:FREQ=WEEKLY
SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
e.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
ple.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
mple.com
END:VEVENT
END:VCALENDAR
The organizer of a recurring meeting successfully adds an agenda
(HTML attachment) to the corresponding calendar resource. Attendees
of the meeting are granted read access to the newly created
attachment resource. Their own copy of the meeting is updated to attachment resource. Their own copy of the meeting is updated to
include the new ATTACH property pointing to the attachment resource include the new ATTACH property pointing to the attachment resource
and they are notified of the change via their scheduling inbox. and they are notified of the change via their scheduling inbox.
>> Request << >> Request <<
POST /events/65.ics?action=attachment-add HTTP/1.1 POST /events/65.ics?action=attachment-add HTTP/1.1
Host: cal.example.com Host: cal.example.com
Content-Type: text/html; charset="utf-8" Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda.html Content-Disposition: attachment;filename=agenda.html
Content-Length: xxxx Content-Length: xxxx
If-Match: "123456789-000-000"
Expect: 100-continue
Prefer: return=representation Prefer: return=representation
>> Interim Response <<
HTTP/1.1 100 Continue
>> Request Body <<
<html> <html>
<body> <body>
<h1>Agenda</h1> <h1>Agenda</h1>
<p>As usual</p> <p>As usual</p>
</body> </body>
</html> </html>
>> Response << >> Final Response <<
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8" Content-Type: text/calendar; charset="utf-8"
Content-Length: yyyy Content-Length: yyyy
Content-Location: http://cal.example.com/events/65.ics Content-Location: http://cal.example.com/events/65.ics
ETag: "123456789-000-111" ETag: "123456789-000-111"
Cal-Managed-ID: 97S Cal-Managed-ID: 97S
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
skipping to change at page 31, line 6 skipping to change at page 34, line 6
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exam
ple.com ple.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@exa
mple.com mple.com
ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx;
FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The organizer has a more specific agenda for the 20th of February The organizer has a more specific agenda for the 20th of February
meeting. It is added to that particular instance of the meeting by meeting. It is added to that particular instance of the meeting by
specifying the rid parameter. specifying the rid parameter. Note that the server takes significant
time to complete the request and notifies the client accordingly.
>> Request << >> Request <<
POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1 POST /events/65.ics?action=attachment-add&rid=20120220T100000 HTTP/1.1
Host: cal.example.com Host: cal.example.com
Content-Type: text/html; charset="utf-8" Content-Type: text/html; charset="utf-8"
Content-Disposition:attachment;filename=agenda0220.html Content-Disposition: attachment;filename=agenda0220.html
Content-Length: xxxx Content-Length: xxxx
If-Match: "123456789-000-111"
Expect: 100-continue
Prefer: return=representation Prefer: return=representation
<html> >> Interim Response <<
<body>
<h1>Agenda</h1>
<p>Something different, for a change</p>
</body>
</html>
>> Response << HTTP/1.1 100 Continue
>> Request Body <<
<html>
<body>
<h1>Agenda</h1>
<p>Something different, for a change</p>
</body>
</html>
>> Interim Response <<
HTTP/1.1 102 Processing
>> Final Response <<
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: text/calendar; charset="utf-8" Content-Type: text/calendar; charset="utf-8"
Content-Length: yyyy Content-Length: yyyy
Content-Location: http://cal.example.com/events/65.ics Content-Location: http://cal.example.com/events/65.ics
ETag: "123456789-000-222" ETag: "123456789-000-222"
Cal-Managed-ID: 33225 Cal-Managed-ID: 33225
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
skipping to change at page 33, line 14 skipping to change at page 36, line 31
Arnaud Quillaud Arnaud Quillaud
Oracle Corporation Oracle Corporation
180, Avenue de l'Europe 180, Avenue de l'Europe
Saint Ismier cedex 38334 Saint Ismier cedex 38334
France France
Email: arnaud.quillaud@oracle.com Email: arnaud.quillaud@oracle.com
URI: http://www.oracle.com/ URI: http://www.oracle.com/
Kenneth Murchison (editor) Kenneth Murchison (editor)
Carnegie Mellon University FastMail Pty Ltd.
5000 Forbes Avenue Level 1, 91 William Street
Pittsburgh, PA 15213 Melbourne, VIC 3000
USA Australia
Email: murch@andrew.cmu.edu Email: murch@fastmail.com
URI: http://www.cmu.edu/ URI: http://www.fastmail.com/
 End of changes. 28 change blocks. 
65 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/