draft-ietf-calext-caldav-attachments-03.txt   draft-ietf-calext-caldav-attachments-04.txt 
Calendering Extensions C. Daboo Calendering Extensions C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Informational A. Quillaud Intended status: Informational A. Quillaud
Expires: January 24, 2018 Oracle Expires: September 6, 2019 Oracle
K. Murchison, Ed. K. Murchison, Ed.
FastMail FastMail
July 23, 2017 March 5, 2019
CalDAV Managed Attachments CalDAV Managed Attachments
draft-ietf-calext-caldav-attachments-03 draft-ietf-calext-caldav-attachments-04
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 This specification documents existing code deployed by multiple
vendors. It is published as an Informational specification rather vendors. It is published as an Informational specification rather
than Standards-Track due to its non-standard method of updating an than Standards Track due to its noncompliance with multiple best
existing resource via HTTP. current practices of 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 https://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 January 24, 2018. This Internet-Draft will expire on September 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 1.1. Rationale for Informational Status . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Discovering Support for Managed Attachments . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovering Support for Managed Attachments . . . . . . . 5
3.3. POST Request for Managing Attachments . . . . . . . . . . 5 3.3. POST Request for Managing Attachments . . . . . . . . . . 5
3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6 3.3.1. action= Query Parameter . . . . . . . . . . . . . . . 6
3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9 3.3.2. rid= Query Parameter . . . . . . . . . . . . . . . . 6
3.6. Removing Attachments via POST . . . . . . . . . . . . . . 12 3.3.3. managed-id= Query Parameter . . . . . . . . . . . . . 7
3.7. Adding Existing Managed Attachments via PUT . . . . . . . 14 3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 7
3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 14 3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 10
3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14 3.6. Removing Attachments via POST . . . . . . . . . . . . . . 13
3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14 3.7. Adding Existing Managed Attachments via PUT . . . . . . . 15
3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 15 3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 15
3.12. Additional Considerations . . . . . . . . . . . . . . . . 16 3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 15
4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 17 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 16
4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 17 3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 18 3.12. Additional Considerations . . . . . . . . . . . . . . . . 17
4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 18 3.12.1. Quotas . . . . . . . . . . . . . . . . . . . . . . . 17
5. Additional Message Header Fields . . . . . . . . . . . . . . 19 3.12.2. Access Control . . . . . . . . . . . . . . . . . . . 17
5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 19 3.12.3. Redirects . . . . . . . . . . . . . . . . . . . . . 18
6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 19 3.12.4. Processing Time . . . . . . . . . . . . . . . . . . 18
6.1. CALDAV:managed-attachments-server-URL property . . . . . 19 3.12.5. Automatic Clean-Up by Servers . . . . . . . . . . . 18
6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 20 3.12.6. Sending Scheduling Messages with Attachments . . . . 18
6.3. CALDAV:max-attachments-per-resource property . . . . . . 21 3.12.7. Migrating Calendar Data . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 19
9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 24 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 20
9.2. Message Header Field Registrations . . . . . . . . . . . 24 5. Additional Message Header Fields . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 6.1. CALDAV:managed-attachments-server-URL property . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 26 6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 22
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.3. CALDAV:max-attachments-per-resource property . . . . . . 23
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 26
9.2. Message Header Field Registrations . . . . . . . . . . . 26
9.2.1. Cal-Managed-ID . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 28
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 27 publication) . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Example Involving Recurring Events . . . . . . . . . 29 Appendix B. Example Involving Recurring Events . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 iCalendar Transport-independent
between calendar users. Interoperability Protocol (iTIP) [RFC5546] to handle scheduling
operations between calendar users.
[RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP [RFC4791] defines the Calendaring Extensions to WebDAV (CalDAV),
[RFC7230], for accessing calendar data stored on a server. based on HTTP [RFC7230], for accessing calendar data stored on a
server.
Calendar users often want to include attachments with their calendar Calendar users often want to include attachments with their calendar
data events or tasks (for example a copy of a presentation, or the data events or tasks (for example a copy of a presentation, or the
meeting agenda). iCalendar provides an "ATTACH" property whose value meeting agenda). iCalendar provides an "ATTACH" property whose value
is either the inline Base64 encoded attachment data, or a URL is either the inline Base64 encoded attachment data, or a URL
specifying the location of the attachment data. specifying the location of the attachment data.
Use of inline attachment data is not ideal with CalDAV because the Use of inline attachment data is not ideal with CalDAV because the
data would need to be uploaded to the server each time a change to data would need to be uploaded to the server each time a change to
the calendar data is done - even minor changes such as a change to the calendar data is done - even minor changes such as a change to
the summary. Whilst a client could choose to use a URL value the summary. Whilst a client could choose to use a URL value
instead, the problem then becomes where and how the client discovers instead, the problem then becomes where and how the client discovers
an appropriate URL to use and how it ensures that only those an appropriate URL to use and how it ensures that only those
attendees listed in the event or task are able to access it. attendees listed in the event or task are able to access it.
This specification solves this problem by having the client send the This specification solves this problem by having the client send the
attachment to the server, separately from the iCalendar data, and the attachment to the server, separately from the iCalendar data, and the
server takes care of adding appropriate "ATTACH" properties in the server takes care of adding appropriate "ATTACH" properties in the
iCalendar data as well as managing access privileges . The server can iCalendar data as well as managing access privileges. The server can
also provide additional information to the client about each also provide additional information to the client about each
attachment in the iCalendar data, such as the size and an identifier. attachment in the iCalendar data, such as the size and an identifier.
1.1. Rationale for Informational Status
Although this extension to CalDAV has wide deployment, its design
does not comply with some of the best current practices of HTTP,
namely:
o All operations on attachments are modeled as HTTP POST operations,
where the actual type of operation is specified using a query
parameter, instead of using separate HTTP POST, PUT, and DELETE
methods where appropriate.
o Specific query strings are hardwired into the protocol in
violation of Section 2.4 of [RFC7320].
Additionally, this extension misuses the Content-Disposition header
field [RFC6266] as a request header field to convey a filename for an
attachment rather than using an existing request header field
suitable for that purpose, such as "Slug" (see Section 9.7 of
[RFC5023]).
Rather than creating interoperability problems with deployed code by
updating the design of this extension to be compliant with best
current practices and to allow this specification to be placed on the
Standards Track, it was decided to simply document how existing
implementations interoperate and to publish the document as
Informational.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The notation used in this memo is the ABNF notation of [RFC5234] as The notation used in this memo is the ABNF notation of [RFC5234] as
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
skipping to change at page 4, line 36 skipping to change at page 5, line 34
In addition, such a server SHOULD support the "return=representation" In addition, such a server SHOULD support the "return=representation"
Prefer header field [RFC7240] preference on successful HTTP PUT and Prefer header field [RFC7240] preference on successful HTTP PUT and
POST requests targeting existing calendar object resources, by POST requests targeting existing calendar object resources, by
returning the new representation of that calendar resource (including returning the new representation of that calendar resource (including
its new 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 token in the DAV response
header field from an OPTIONS request on a calendar home collection. header field (as defined in Section 10.1 of [RFC4918]) 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 also
"calendar-managed-attachments-no-recurrence" as a field in the DAV include "calendar-managed-attachments-no-recurrence" as a token in
response header field from an OPTIONS request on a calendar home the DAV response header field from an OPTIONS request on a calendar
collection. When that field is present, clients MUST NOT attempt any home collection. When that field is present, clients MUST NOT
managed attachment operations that target specific recurrence attempt any managed attachment operations that target specific
instances. recurrence instances.
3.3. POST Request for Managing Attachments 3.3. POST Request for Managing Attachments
An HTTP POST request is used to add, update, or remove attachments. An HTTP POST request is used to add, update, or remove attachments.
The request-URI will contain various query parameters to specify the These requests are subject to the preconditions listed in
behavior. Section 3.11. The request-URI will contain various query parameters
to specify the behavior.
3.3.1. action= Query Parameter 3.3.1. action= Query Parameter
The "action" query parameter is used to identify which attachment The "action" query parameter is used to identify which attachment
operation the client is requesting. This parameter MUST be present operation the client is requesting. This parameter MUST be present
once on each POST request used to manage attachments. One of these once on each POST request used to manage attachments. One of these
three values MUST be used: three values MUST be used:
attachment-add Indicates an operation that is adding an attachment attachment-add Indicates an operation that is adding an attachment
to a calendar object resource. See Section 3.4 for more details. to a calendar object resource. See Section 3.4 for more details.
skipping to change at page 5, line 31 skipping to change at page 6, line 27
attachment-update Indicates an operation that is updating an attachment-update Indicates an operation that is updating an
existing attachment on a calendar object resource. See existing attachment on a calendar object resource. See
Section 3.5 for more details. Section 3.5 for more details.
attachment-remove Indicates an operation that is removing an attachment-remove Indicates an operation that is removing an
attachment from a calendar object resource. See Section 3.6 for attachment from a calendar object resource. See Section 3.6 for
more details. more details.
Example: Example:
http://calendar.example.com/events/1.ics?action=attachment-add https://calendar.example.com/events/1.ics?action=attachment-add
3.3.2. rid= Query Parameter 3.3.2. rid= Query Parameter
The "rid" query parameter is used to identify which recurrence The "rid" query parameter is used to identify which recurrence
instances are being targeted by the client for the attachment instances are being targeted by the client for the attachment
operation. This query parameter MUST contain one or more items, operation. This query parameter MUST contain one or more items,
separated by commas (0x2C). The item values can be in one of two separated by commas (0x2C). The item values can be in one of two
forms: forms:
Master instance The value "M" (case-insensitive) refers to the Master instance The value "M" (case-insensitive) refers to the
"master" recurrence instance, i.e., the component that does not "master" recurrence instance, i.e., the component that does not
include a "RECURRENCE-ID" property. This item MUST be present include a "RECURRENCE-ID" property. This item MUST be present
only once. only once.
Specific instance A specific iCalendar instance is targeted by using Specific instance A specific iCalendar instance is targeted by using
its "RECURRENCE-ID" value as the item value. That value MUST its "RECURRENCE-ID" value as the item value. That value MUST
correspond to the RECURRENCE-ID value as stored in the calendar correspond to the RECURRENCE-ID value as stored in the calendar
object resource (i.e. without any conversion to UTC). If multiple object resource (i.e. without any conversion to UTC). If multiple
items of this form are used, they MUST be unique values. items of this form are used, they MUST be unique values. For
example, to target a recurrence defined by property RECURRENCE-
ID;TZID=America/Montreal:20111022T160000, the query parameter
rid=20111022T160000 would be used.
If the "rid" query parameter is not present, all recurrence instances If the "rid" query parameter is not present, all recurrence instances
in the calendar object resource are targeted. in the calendar object resource are targeted.
The "rid" query parameter MUST NOT be present in the case of an The "rid" query parameter MUST NOT be present in the case of an
update operation, or if the server chooses not to support per- update operation, or if the server chooses not to support per-
recurrence instance managed attachments (see Section 3.1). recurrence instance managed attachments (see Section 3.1).
Example: Example (targeting the master instance and a specific overridden
instance):
http://calendar.example.com/events/1.ics? https://calendar.example.com/events/1.ics?
action=attachment-add&rid=M,20111022T160000 action=attachment-add&rid=M,20111022T160000
3.3.3. managed-id= Query Parameter 3.3.3. managed-id= Query Parameter
The "managed-id" query parameter is used to identify which "ATTACH" The "managed-id" query parameter is used to identify which "ATTACH"
property is being updated or removed. The value of this query property is being updated or removed. The value of this query
parameter MUST match the "MANAGED-ID" property parameter value on the parameter MUST match the "MANAGED-ID" (Section 4.3) property
"ATTACH" property in the calendar object resource instance(s) parameter value on the "ATTACH" property in the calendar object
targeted by the request. resource instance(s) targeted by the request.
The "managed-id" query parameter MUST NOT be present in the case of The "managed-id" query parameter MUST NOT be present in the case of
an add operation. an add operation.
Example: Example:
http://calendar.example.com/events/1.ics? https://calendar.example.com/events/1.ics?
action=attachment-update&managed-id=aUNhbGVuZGFy action=attachment-update&managed-id=aUNhbGVuZGFy
3.4. Adding attachments 3.4. Adding attachments
To add an attachment to an existing calendar object resource, the To add an attachment to an existing calendar object resource, the
following occurs: following occurs:
1. The client issues a POST request targeted at the calendar object 1. The client issues a POST request targeted at the calendar object
resource. resource.
skipping to change at page 7, line 12 skipping to change at page 8, line 12
C. The body of the request contains the data for the attachment. C. The body of the request contains the data for the attachment.
D. The client MUST include a valid Content-Type header field D. The client MUST include a valid Content-Type header field
describing the media type of the attachment (as required by describing the media type of the attachment (as required by
HTTP). HTTP).
E. The client SHOULD include a Content-Disposition header field E. The client SHOULD include a Content-Disposition header field
[RFC6266] with a "type" parameter set to "attachment", and a [RFC6266] with a "type" parameter set to "attachment", and a
"filename" parameter that indicates the name of the "filename" parameter that indicates the name of the
attachment. attachment. Note that the use of Content-Disposition as a
request header field is nonstandard and specific to this
protocol.
F. The client MAY include a Prefer header field [RFC7240] with F. The client MAY include a Prefer header field [RFC7240] with
the "return=representation" preference to request that the the "return=representation" preference to request that the
modified calendar object resource be returned as the body of modified calendar object resource be returned as the body of
a successful response to the POST request. a successful response to the POST request.
2. When the server receives the POST request it does the following: 2. When the server receives the POST request it does the following:
A. Validates that any recurrence instances referred to via the A. Validates that any recurrence instances referred to via the
"rid" query parameter are valid for the calendar object "rid" query parameter are valid for the calendar object
skipping to change at page 9, line 9 skipping to change at page 10, line 9
<html> <html>
<body> <body>
<h1>Agenda</h1> <h1>Agenda</h1>
</body> </body>
</html> </html>
>> Response << >> 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/64.ics Content-Location: https://cal.example.com/events/64.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
PRODID:-//Example Corp.//CalDAV Server//EN PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z DTSTART:20120714T170000Z
skipping to change at page 12, line 9 skipping to change at page 13, line 9
<body> <body>
<h1>Agenda</h1> <h1>Agenda</h1>
<p>Discuss attachment draft</p> <p>Discuss attachment draft</p>
</body> </body>
</html> </html>
>> Response << >> Response <<
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/calendar; charset="utf-8" Content-Type: text/calendar; charset="utf-8"
Content-Length: yyyz Content-Length: yyyz
Content-Location: http://cal.example.com/events/64.ics Content-Location: https://cal.example.com/events/64.ics
Cal-Managed-ID: 98S Cal-Managed-ID: 98S
ETag: "123456789-000-222" ETag: "123456789-000-222"
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VEVENT BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com UID:20010712T182145Z-123401@example.com
DTSTAMP:20120201T203412Z DTSTAMP:20120201T203412Z
DTSTART:20120714T170000Z DTSTART:20120714T170000Z
skipping to change at page 14, line 20 skipping to change at page 15, line 20
>> Response << >> Response <<
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Content-Length: 0 Content-Length: 0
3.7. Adding Existing Managed Attachments via PUT 3.7. Adding Existing Managed Attachments via PUT
Clients can make use of existing managed attachments by adding the Clients can make use of existing managed attachments by adding the
corresponding "ATTACH" property to calendar object resources (subject corresponding "ATTACH" property to calendar object resources (subject
to the restrictions described in Section 3.12.2). When this occurs, to the restrictions described in Section 3.12.2)
If a managed attachment is used in more than calendar resource,
servers SHOULD NOT change either the "MANAGED-ID" parameter value or servers SHOULD NOT change either the "MANAGED-ID" parameter value or
the "ATTACH" property value for any managed attachments - this the "ATTACH" property value for these attachments - this ensures that
ensures that clients do not have to download the attachment data clients do not have to download the attachment data again if they
again if they already have it cached, because it is used in another already have it cached. Additionally, servers SHOULD validate "SIZE"
calendar resource. parameter values and replace incorrect values with the actual sizes
of existing attachments.
These PUT requests are subject to the preconditions listed in
Section 3.11.
3.8. Updating Attachments via PUT 3.8. Updating Attachments via PUT
Servers MUST NOT allow clients to update attachment data directly via Servers MUST NOT allow clients to update attachment data directly via
a PUT on the attachment URI (or via any other HTTP method that a PUT on the attachment URI (or via any other HTTP method that
modifies content). Instead, attachments can only be updated via use modifies content). Instead, attachments can only be updated via use
of POST requests on the calendar data. of POST requests on the calendar data.
3.9. Removing Attachments via PUT 3.9. Removing Attachments via PUT
skipping to change at page 15, line 24 skipping to change at page 16, line 31
the CALDAV:max-attachment-size property value (Section 6.2) on the the CALDAV:max-attachment-size property value (Section 6.2) on the
calendar collection of the target calendar resource; calendar collection of the target calendar resource;
(CALDAV:max-attachments-per-resource): The addition of the (CALDAV:max-attachments-per-resource): The addition of the
attachment submitted in the POST request MUST result in the target attachment submitted in the POST request MUST result in the target
calendar resource having a number of managed attachments less than calendar resource having a number of managed attachments less than
or equal to the value of the CALDAV:max-attachments-per-resource or equal to the value of the CALDAV:max-attachments-per-resource
property value (Section 6.3) on the calendar collection of the property value (Section 6.3) on the calendar collection of the
target calendar resource; target calendar resource;
(CALDAV:valid-action): The action query parameter in the POST
request MUST contain one of "attachment-add", "attachment-update",
or "attachment-remove".
(CALDAV:valid-rid): The rid query parameter in the POST request
MUST NOT be present for an attachment-update action, and MUST
contain the value "M" and/or values corresponding to "RECURRENCE-
ID" property values in the iCalendar data targeted by the request.
(CALDAV:valid-managed-id): The managed-id query parameter in the (CALDAV:valid-managed-id): The managed-id query parameter in the
POST request MUST contain a value corresponding to a "MANAGED-ID" POST request MUST NOT be present for an attachment-add action, and
property parameter value in the iCalendar data targeted by the MUST contain a value corresponding to a "MANAGED-ID" property
request. parameter value in the iCalendar data targeted by the request.
A POST request to add, modify, or delete a managed attachment results A POST request to add, modify, or delete a managed attachment results
in an implicit modification of the targeted calendar resource in an implicit modification of the targeted calendar resource
(equivalent of a PUT). As a consequence, clients should also be (equivalent of a PUT). As a consequence, clients should also be
prepared to handle preconditions associated with this implicit PUT. prepared to handle preconditions associated with this implicit PUT.
This includes (but is not limited to): This includes (but is not limited to):
(CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791])
(DAV:quota-not-exceeded) (from Section 6 of [RFC4331]) (DAV:quota-not-exceeded) (from Section 6 of [RFC4331])
(DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) (DAV:sufficient-disk-space) (from Section 6 of [RFC4331])
A PUT request to add or modify and existing calendar object resource A PUT request to add or modify and existing calendar object resource
can make reference to an existing managed attachment. The following can make reference to an existing managed attachment. The following
new preconditions is defined: new preconditions is defined:
(CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property
parameter value in the iCalendar data in the PUT request is not parameter value in the iCalendar data in the PUT request is not
skipping to change at page 16, line 5 skipping to change at page 17, line 16
(DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) (DAV:sufficient-disk-space) (from Section 6 of [RFC4331])
A PUT request to add or modify and existing calendar object resource A PUT request to add or modify and existing calendar object resource
can make reference to an existing managed attachment. The following can make reference to an existing managed attachment. The following
new preconditions is defined: new preconditions is defined:
(CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property
parameter value in the iCalendar data in the PUT request is not parameter value in the iCalendar data in the PUT request is not
valid (e.g., does not match any existing managed attachment). valid (e.g., does not match any existing managed attachment).
If a precondition for a request is not satisfied:
1. The response status of the request MUST either be 403
(Forbidden), if the request should not be repeated because it
will always fail, or 409 (Conflict), if it is expected that the
user might be able to resolve the conflict and resubmit the
request.
2. The appropriate XML element MUST be returned as the child of a
top-level DAV:error element in the response body.
3.12. Additional Considerations 3.12. Additional Considerations
3.12.1. Quotas 3.12.1. Quotas
The WebDAV Quotas [RFC4331] specification defines two live WebDAV The WebDAV Quotas [RFC4331] specification defines two live WebDAV
properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to
communicate storage quota information to clients. Server communicate storage quota information to clients. Server
implementations MAY choose to include managed attachments sizes when implementations MAY choose to include managed attachments sizes when
calculating the amount of storage used by a particular resource. calculating the amount of storage used by a particular resource.
skipping to change at page 16, line 37 skipping to change at page 18, line 11
This specification only allows organizers of scheduled events to add This specification only allows organizers of scheduled events to add
managed attachments. Servers MUST prevent attendees of scheduled managed attachments. Servers MUST prevent attendees of scheduled
events from adding, updating or removing managed attachments. In events from adding, updating or removing managed attachments. In
addition, the server MUST prevent a calendar user from re-using a addition, the server MUST prevent a calendar user from re-using a
managed attachment (based on its managed-id value), unless that user managed attachment (based on its managed-id value), unless that user
is the one who originally created the managed attachment. is the one who originally created the managed attachment.
3.12.3. Redirects 3.12.3. Redirects
For POST requests that add or update attachment data, the server MAY For POST requests that add or update attachment data, the server MAY
issue an HTTP redirect to require the client to re-issue the POST issue a 307 (Temporary Redirect) [RFC7231] or 308 (Permanent
request using a different request-URI. As a result, it is always Redirect) [RFC7538] response to require the client to re-issue the
best for clients to use the "100-continue" expectation defined in POST request using a different request-URI. As a result, clients
Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a SHOULD use the "100-continue" expectation defined in Section 5.1.1 of
redirect does occur, the client does not needlessly send the [RFC7231]. Using this mechanism ensures that, if a redirect does
attachment data. occur, the client does not needlessly send the 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
skipping to change at page 17, line 52 skipping to change at page 19, line 27
; positive integers ; positive integers
Description: This property parameter MAY be specified on "ATTACH" Description: This property parameter MAY be specified on "ATTACH"
properties. It indicates the size in octets of the corresponding properties. It indicates the size in octets of the corresponding
attachment data. Since iCalendar integer values are restricted to attachment data. Since iCalendar integer values are restricted to
a maximum value of 2147483647, the current parameter is defined as a maximum value of 2147483647, the current parameter is defined as
text to allow an extended range to be used. text to allow an extended range to be used.
Example: Example:
ATTACH;SIZE=1234:http://attachments.example.com/abcd.txt ATTACH;SIZE=1234:https://attachments.example.com/abcd.txt
4.2. FILENAME Property Parameter 4.2. FILENAME Property Parameter
Parameter Name: FILENAME Parameter Name: FILENAME
Purpose: To specify the file name of a managed attachment. Purpose: To specify the file name of a managed attachment.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
skipping to change at page 18, line 28 skipping to change at page 20, line 5
provides information on how to construct a filename for storing provides information on how to construct a filename for storing
the attachment data. This parameter is very similar in nature to the attachment data. This parameter is very similar in nature to
the Content-Disposition HTTP header field "filename" parameter and the Content-Disposition HTTP header field "filename" parameter and
exposes the same security risks. As a consequence, clients MUST exposes the same security risks. As a consequence, clients MUST
follow the guidelines expressed in Section 4.3 of [RFC6266] when follow the guidelines expressed in Section 4.3 of [RFC6266] when
consuming this parameter value. Similarly, servers MUST follow consuming this parameter value. Similarly, servers MUST follow
those same guidelines before storing a value. those same guidelines before storing a value.
Example: Example:
ATTACH;FILENAME=agenda.html:http://attachments.example.c ATTACH;FILENAME=agenda.html:https://attachments.example.c
om/rt452S om/rt452S
4.3. MANAGED-ID Property Parameter 4.3. MANAGED-ID Property Parameter
Parameter Name: MANAGED-ID Parameter Name: MANAGED-ID
Purpose: To uniquely identify a managed attachment. Purpose: To uniquely identify a managed attachment.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
managedidparam = "MANAGED-ID" "=" paramtext managedidparam = "MANAGED-ID" "=" paramtext
Description: This property parameter MUST be specified on "ATTACH" Description: This property parameter MUST be specified on "ATTACH"
properties corresponding to managed attachments. Its value is properties corresponding to managed attachments. Its value is
generated by the server and uniquely identifies a managed generated by the server and uniquely identifies a managed
attachment. This property parameter MUST NOT be present in the attachment within the scope of the CalDAV server. This property
case of non-managed attachments. parameter MUST NOT be present in the case of non-managed
attachments.
Example: Example:
ATTACH;MANAGED-ID=aUNhbGVuZGFy:http://attachments.example.c ATTACH;MANAGED-ID=aUNhbGVuZGFy:https://attachments.example.c
om/abcd.txt om/abcd.txt
5. Additional Message Header Fields 5. Additional Message Header Fields
5.1. Cal-Managed-ID Response Header Field 5.1. Cal-Managed-ID Response Header Field
The Cal-Managed-ID response header field provides the value of the The Cal-Managed-ID response header field provides the value of the
MANAGED-ID parameter corresponding to a newly added ATTACH property. MANAGED-ID parameter corresponding to a newly added ATTACH property.
It MUST be sent only in response to a successful POST request with an
action set to attachment-add or attachment-update. ABNF:
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
The Cal-Managed-ID header field MUST only be sent by an origin server
in response to a successful POST request with an action set to
attachment-add or attachment-update. It MUST only appear once in a
response and MUST NOT appear in trailers.
The Cal-Managed-ID header field is end to end and MUST be forwarded
by intermediaries. Intermediaries MUST NOT insert, delete, or modify
a Cal-Managed-ID header field.
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 22, line 16 skipping to change at page 23, line 50
<!-- PCDATA value: a numeric value (positive decimal integer) --> <!-- PCDATA value: a numeric value (positive decimal integer) -->
Example: Example:
<C:max-attachments-per-resource <C:max-attachments-per-resource
xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:C="urn:ietf:params:xml:ns:caldav"
>12</C:max-attachments-per-resource> >12</C:max-attachments-per-resource>
7. Implementation Status 7. Implementation Status
< RFC Editor: before publication please remove this section and the < RFC Editor: before publication please remove this section, the
reference to [RFC7942] > reference to [RFC7942], and any resulting "URIs" references sub-
section. >
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
skipping to change at page 22, line 41 skipping to change at page 24, line 26
According to [RFC7942], "this will allow reviewers and working groups According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
7.1. Calendar and Contacts Server 7.1. Calendar and Contacts Server
The open source Calendar and Contacts Server [1] project is a The open source Calendar and Contacts Server [2] project is a
standards-compliant server implementing the CalDAV protocol. This standards-compliant server implementing the CalDAV protocol. This
production level implementation supports all of the requirements production level implementation supports all of the requirements
described in this document and successfully interoperates with the described in this document and successfully interoperates with the
Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations
described below. This implementation is freely distributable under described below. This implementation is freely distributable under
the terms of the Apache License, Version 2.0 [2]. the terms of the Apache License, Version 2.0 [3].
7.2. Cyrus Server 7.2. Cyrus Server
The open source Cyrus Server [3] project is a highly scalable The open source Cyrus Server [4] project is a highly scalable
enterprise mail system which also supports calendaring. This enterprise mail system which also supports calendaring. This
production level CalDAV implementation supports all of the production level CalDAV implementation supports all of the
requirements described in this document and successfully requirements described in this document and successfully
interoperates with the Apple Calendar and CalDAVTester client interoperates with the Apple Calendar and CalDAVTester client
implementations described below. This implementation is freely implementations described below. This implementation is freely
distributable under a BSD style license from Computing Services at distributable under a BSD style license from Computing Services at
Carnegie Mellon University [4]. Carnegie Mellon University [5].
7.3. Oracle Communications Calendar Server 7.3. Oracle Communications Calendar Server
The Oracle Communications Calendar Server [5] project is a standards- The Oracle Communications Calendar Server [6] project is a standards-
compliant, scalable, enterprise-ready calendaring solution. This compliant, scalable, enterprise-ready calendaring solution. This
production level CalDAV implementation supports all of the production level CalDAV implementation supports all of the
requirements described in this document and successfully requirements described in this document and successfully
interoperates with the Apple Calendar and CalDAVTester client interoperates with the Apple Calendar and CalDAVTester client
implementations described below. This implementation is proprietary implementations described below. This implementation is proprietary
and available for a free trial and/or purchase from the vendor. and available for a free trial and/or purchase from the vendor.
7.4. Apple Calendar 7.4. Apple Calendar
The widely used Apple Calendar [6] client is a standards-compliant The widely used Apple Calendar [7] client is a standards-compliant
client implementing the CalDAV protocol. This production level client implementing the CalDAV protocol. This production level
implementation supports all the requirements described in this implementation supports all the requirements described in this
document and successfully interoperates with the document and successfully interoperates with the
Calendar and Contacts Server, Cyrus Server, and Calendar and Contacts Server, Cyrus Server, and
Oracle Communications Calendar Server implementations described Oracle Communications Calendar Server implementations described
above. This client implementation is proprietary and is distributed above. This client implementation is proprietary and is distributed
as part of Apple's desktop operating systems. as part of Apple's desktop operating systems.
7.5. BusyCal 7.5. BusyCal
BusyCal [7] is a standards-compliant calendar client for MacOS BusyCal [8] is a standards-compliant calendar client for MacOS
implementing the CalDAV protocol. This implementation supports all implementing the CalDAV protocol. This implementation supports all
of the requirements described in this document and successfully of the requirements described in this document and successfully
interoperates with the Calendar and Contacts Server and Cyrus Server interoperates with the Calendar and Contacts Server and Cyrus Server
implementations described above. This implementation is proprietary implementations described above. This implementation is proprietary
and available for a free trial and/or purchase from the vendor. and available for a free trial and/or purchase from the vendor.
7.6. CalDAVTester 7.6. CalDAVTester
CalDAVTester [8] is an open source test and performance application CalDAVTester [9] is an open source test and performance application
designed to work with CalDAV servers and tests various aspects of designed to work with CalDAV servers and tests various aspects of
their protocol handling as well as performance. This widely used their protocol handling as well as performance. This widely used
implementation supports all of the requirements described in this implementation supports all of the requirements described in this
document and successfully interoperates with the server document and successfully interoperates with the server
implementations described above. This implementation is freely implementations described above. This implementation is freely
distributable under the terms of the Apache License, Version 2.0 [9]. distributable under the terms of the Apache License, Version 2.0
[10].
7.7. 2Do 7.7. 2Do
2Do [10] is a standards-complient calendar client for iOS which uses 2Do [11] is a standards-complient calendar client for iOS which uses
the CalDAV standard for communication. This implementation supports the CalDAV standard for communication. This implementation supports
all of the requirements described in this document and successfully all of the requirements described in this document and successfully
interoperates with the Calendar and Contacts Server implementation interoperates with the Calendar and Contacts Server implementation
described above. This implementation is proprietary and available described above. This implementation is proprietary and available
for purchase from the vendor. for purchase from the vendor.
8. Security Considerations 8. Security Considerations
Malicious content could be introduced into the Calendar Server by way The security considerations in [RFC4791] and [RFC4918] apply to this
extension. Additionally, servers need to be aware that a client
could attack underlying storage by POSTing extremely large
attachments and could attack processing time by uploading a recurring
event with a large number of overrides and then repeatedly adding,
updating, and deleting attachments.
Malicious content could be introduced into the calendar server by way
of a managed attachment, and propagated to many end users via of a managed attachment, and propagated to many end users via
scheduling. Servers SHOULD check managed attachments for malicious scheduling. Servers SHOULD check managed attachments for malicious
or inappropriate content. Upon detecting of such content, servers or inappropriate content. Upon detecting of such content, servers
SHOULD remove the attachment, following the rules described in SHOULD remove the attachment, following the rules described in
Section 3.12.5. Section 3.12.5.
9. IANA Considerations 9. IANA Considerations
9.1. Parameter Registrations 9.1. Parameter Registrations
skipping to change at page 25, line 25 skipping to change at page 27, line 18
Scheduling Consortium. Thanks in particular to Mike Douglass and Scheduling Consortium. Thanks in particular to Mike Douglass and
Eric York. Eric York.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring -- Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
<http://www.rfc-editor.org/info/rfc2518>. <https://www.rfc-editor.org/info/rfc2518>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
[RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties
for Distributed Authoring and Versioning (DAV) for Distributed Authoring and Versioning (DAV)
Collections", RFC 4331, DOI 10.17487/RFC4331, February Collections", RFC 4331, DOI 10.17487/RFC4331, February
2006, <http://www.rfc-editor.org/info/rfc4331>. 2006, <https://www.rfc-editor.org/info/rfc4331>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007, DOI 10.17487/RFC4791, March 2007,
<http://www.rfc-editor.org/info/rfc4791>. <https://www.rfc-editor.org/info/rfc4791>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009, RFC 5545, DOI 10.17487/RFC5545, September 2009,
<http://www.rfc-editor.org/info/rfc5545>. <https://www.rfc-editor.org/info/rfc5545>.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
DOI 10.17487/RFC6266, June 2011, DOI 10.17487/RFC6266, June 2011,
<http://www.rfc-editor.org/info/rfc6266>. <https://www.rfc-editor.org/info/rfc6266>.
[RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
<http://www.rfc-editor.org/info/rfc6638>. <https://www.rfc-editor.org/info/rfc6638>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
DOI 10.17487/RFC7240, June 2014, DOI 10.17487/RFC7240, June 2014,
<http://www.rfc-editor.org/info/rfc7240>. <https://www.rfc-editor.org/info/rfc7240>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
October 2007, <https://www.rfc-editor.org/info/rfc5023>.
[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>. <https://www.rfc-editor.org/info/rfc5546>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>.
[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>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8144] Murchison, K., "Use of the Prefer Header Field in Web [RFC8144] Murchison, K., "Use of the Prefer Header Field in Web
Distributed Authoring and Versioning (WebDAV)", RFC 8144, Distributed Authoring and Versioning (WebDAV)", RFC 8144,
DOI 10.17487/RFC8144, April 2017, DOI 10.17487/RFC8144, April 2017,
<http://www.rfc-editor.org/info/rfc8144>. <https://www.rfc-editor.org/info/rfc8144>.
11.3. URIs 11.3. URIs
[1] http://calendarserver.org/ [1] https://tools.ietf.org/html/bcp14
[2] http://www.apache.org/licenses/LICENSE-2.0.html [2] http://calendarserver.org/
[3] http://www.cyrusimap.org/ [3] http://www.apache.org/licenses/LICENSE-2.0.html
[4] http://www.cmu.edu/computing/ [4] http://www.cyrusimap.org/
[5] http://www.cyrusimap.org/ [5] http://www.cmu.edu/computing/
[6] http://www.apple.com/macos/ [6] http://www.cyrusimap.org/
[7] http://www.busymac.com/busycal/ [7] http://www.apple.com/macos/
[8] http://calendarserver.org/wiki/CalDAVTester [8] http://www.busymac.com/busycal/
[9] http://www.apache.org/licenses/LICENSE-2.0.html [9] http://calendarserver.org/wiki/CalDAVTester
[10] http://www.2doapp.com/ [10] http://www.apache.org/licenses/LICENSE-2.0.html
[11] 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-04:
1. Added text explaining why this document is being published as
Informational.
2. Further specified Cal-Managed-ID per Section 8.3.1 of RFC 7231.
3. Specified that the MANAGED-ID parameter value is unique within
the scope of the server.
4. Added more text regarding preconditions.
5. Added text about specific DoS attack vectors.
6. Editorial changes from Gren Elliot and Phillip Kewisch.
7. Editorial changes from Adam Roach.
8. Editorial changes from Alexey Melnikov.
9. Added reference to RFC4918.
10. Minor editorial changes.
Changes in calext-03: Changes in calext-03:
1. Changed to Informational based on feedback regarding non-standard 1. Changed to Informational based on feedback regarding non-standard
method of updating an existing resource. method of updating an existing resource.
2. Added references to sub-sections in Overview. 2. Added references to sub-sections in Overview.
3. Made support for Prefer header field a SHOULD for servers. 3. Made support for Prefer header field a SHOULD for servers.
4. Expanded recurring event examples to use conditional requests and 4. Expanded recurring event examples to use conditional requests and
skipping to change at page 31, line 9 skipping to change at page 34, line 9
Content-Disposition: attachment;filename=agenda.html Content-Disposition: attachment;filename=agenda.html
Content-Length: xxxx Content-Length: xxxx
If-Match: "abcdefg-000" If-Match: "abcdefg-000"
Expect: 100-continue Expect: 100-continue
Prefer: return=representation Prefer: return=representation
>> Final Response << >> Final Response <<
HTTP/1.1 412 Precondition Failed HTTP/1.1 412 Precondition Failed
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: https://cal.example.com/events/65.ics
ETag: "123456789-000-000" ETag: "123456789-000-000"
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z LAST-MODIFIED:20040110T032845Z
TZID:America/Montreal TZID:America/Montreal
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:20000404T020000 DTSTART:20000404T020000
skipping to change at page 33, line 9 skipping to change at page 36, line 9
<body> <body>
<h1>Agenda</h1> <h1>Agenda</h1>
<p>As usual</p> <p>As usual</p>
</body> </body>
</html> </html>
>> Final 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: https://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
PRODID:-//Example Corp.//CalDAV Server//EN PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z LAST-MODIFIED:20040110T032845Z
TZID:America/Montreal TZID:America/Montreal
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
skipping to change at page 34, line 6 skipping to change at page 37, 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. Note that the server takes significant specifying the rid parameter. Note that an overridden instance is
time to complete the request and notifies the client accordingly. created with the RECURRENCE-ID property value matching the value of
the "rid" query parameter in the request. Also 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" If-Match: "123456789-000-111"
Expect: 100-continue Expect: 100-continue
skipping to change at page 34, line 42 skipping to change at page 37, line 45
>> Interim Response << >> Interim Response <<
HTTP/1.1 102 Processing HTTP/1.1 102 Processing
>> Final 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: https://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
PRODID:-//Example Corp.//CalDAV Server//EN PRODID:-//Example Corp.//CalDAV Server//EN
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
LAST-MODIFIED:20040110T032845Z LAST-MODIFIED:20040110T032845Z
TZID:America/Montreal TZID:America/Montreal
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:20000404T020000 DTSTART:20000404T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZNAME:EDT TZNAME:EDT
skipping to change at page 36, line 31 skipping to change at page 39, line 35
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)
FastMail Pty Ltd. FastMail US LLC
Level 1, 91 William Street 1429 Walnut St, Suite 1201
Melbourne, VIC 3000 Philadephia, PA 19102
Australia USA
Email: murch@fastmail.com Email: murch@fastmailteam.com
URI: http://www.fastmail.com/ URI: http://www.fastmail.com/
 End of changes. 87 change blocks. 
145 lines changed or deleted 287 lines changed or added

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