draft-ietf-calext-caldav-attachments-04.txt   rfc8607.txt 
Calendering Extensions C. Daboo Internet Engineering Task Force (IETF) C. Daboo
Internet-Draft Apple Request for Comments: 8607 Apple
Intended status: Informational A. Quillaud Category: Informational A. Quillaud
Expires: September 6, 2019 Oracle ISSN: 2070-1721 Oracle
K. Murchison, Ed. K. Murchison, Ed.
FastMail FastMail
March 5, 2019 June 2019
CalDAV Managed Attachments Calendaring Extensions to WebDAV (CalDAV): Managed Attachments
draft-ietf-calext-caldav-attachments-04
Abstract Abstract
This specification defines an extension to the calendar access This specification adds an extension to the Calendaring Extensions to
protocol (CalDAV) to allow attachments associated with iCalendar data WebDAV (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 noncompliance with multiple best than Standards Track due to its noncompliance with multiple best
current practices of HTTP. current practices of HTTP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on September 6, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8607.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 19 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Rationale for Informational Status . . . . . . . . . . . 4 1.1. Rationale for Informational Status . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Discovering Support for Managed Attachments . . . . . . . 5 3.2. Discovering Support for Managed Attachments . . . . . . . 5
3.3. POST Request for Managing Attachments . . . . . . . . . . 5 3.3. POST Request for Managing Attachments . . . . . . . . . . 6
3.3.1. action= Query Parameter . . . . . . . . . . . . . . . 6 3.3.1. action Query Parameter . . . . . . . . . . . . . . . 6
3.3.2. rid= Query Parameter . . . . . . . . . . . . . . . . 6 3.3.2. rid Query Parameter . . . . . . . . . . . . . . . . . 6
3.3.3. managed-id= Query Parameter . . . . . . . . . . . . . 7 3.3.3. managed-id Query Parameter . . . . . . . . . . . . . 7
3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 7 3.4. Adding Attachments . . . . . . . . . . . . . . . . . . . 7
3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 10 3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 10
3.6. Removing Attachments via POST . . . . . . . . . . . . . . 13 3.6. Removing Attachments via POST . . . . . . . . . . . . . . 13
3.7. Adding Existing Managed Attachments via PUT . . . . . . . 15 3.7. Adding Existing Managed Attachments via PUT . . . . . . . 15
3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 15 3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 15
3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 15 3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 15
3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 16 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 15
3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
3.12. Additional Considerations . . . . . . . . . . . . . . . . 17 3.12. Additional Considerations . . . . . . . . . . . . . . . . 17
3.12.1. Quotas . . . . . . . . . . . . . . . . . . . . . . . 17 3.12.1. Quotas . . . . . . . . . . . . . . . . . . . . . . . 17
3.12.2. Access Control . . . . . . . . . . . . . . . . . . . 17 3.12.2. Access Control . . . . . . . . . . . . . . . . . . . 17
3.12.3. Redirects . . . . . . . . . . . . . . . . . . . . . 18 3.12.3. Redirects . . . . . . . . . . . . . . . . . . . . . 18
3.12.4. Processing Time . . . . . . . . . . . . . . . . . . 18 3.12.4. Processing Time . . . . . . . . . . . . . . . . . . 18
3.12.5. Automatic Clean-Up by Servers . . . . . . . . . . . 18 3.12.5. Automatic Cleanup by Servers . . . . . . . . . . . . 18
3.12.6. Sending Scheduling Messages with Attachments . . . . 18 3.12.6. Sending Scheduling Messages with Attachments . . . . 18
3.12.7. Migrating Calendar Data . . . . . . . . . . . . . . 18 3.12.7. Migrating Calendar Data . . . . . . . . . . . . . . 18
4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 19 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 19
4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 19 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 19
4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 19 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 19
4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 20 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 20
5. Additional Message Header Fields . . . . . . . . . . . . . . 20 5. Additional Message Header Fields . . . . . . . . . . . . . . 20
5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 20 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 20
6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 21 6. Additional WebDAV Properties . . . . . . . . . . . . . . . . 21
6.1. CALDAV:managed-attachments-server-URL property . . . . . 21 6.1. CALDAV:managed-attachments-server-URL Property . . . . . 21
6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 22 6.2. CALDAV:max-attachment-size Property . . . . . . . . . . . 22
6.3. CALDAV:max-attachments-per-resource property . . . . . . 23 6.3. CALDAV:max-attachments-per-resource Property . . . . . . 23
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.1. Parameter Registrations . . . . . . . . . . . . . . . . . 24
9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 26 8.2. Message Header Field Registrations . . . . . . . . . . . 25
9.2. Message Header Field Registrations . . . . . . . . . . . 26 8.2.1. Cal-Managed-ID . . . . . . . . . . . . . . . . . . . 25
9.2.1. Cal-Managed-ID . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Example Involving Recurring Events . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Example Involving Recurring Events . . . . . . . . . 32
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 iCalendar Transport-independent data and is used with iCalendar Transport-independent
Interoperability Protocol (iTIP) [RFC5546] to handle scheduling Interoperability Protocol (iTIP) [RFC5546] to handle scheduling
operations between calendar users. operations between calendar users.
[RFC4791] defines the Calendaring Extensions to WebDAV (CalDAV), [RFC4791] defines the Calendaring Extensions to WebDAV (CalDAV),
based on HTTP [RFC7230], for accessing calendar data stored on a based on HTTP [RFC7230], for accessing calendar data stored on a
server. 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 made, even minor changes such as a change to the
the summary. Whilst a client could choose to use a URL value summary. Whilst a client could choose to use a URL value instead,
instead, the problem then becomes where and how the client discovers the problem then becomes where and how the client discovers an
an appropriate URL to use and how it ensures that only those appropriate URL to use and how it ensures that only those attendees
attendees listed in the event or task are able to access it. 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
server takes care of adding appropriate "ATTACH" properties in the having the server add appropriate "ATTACH" properties in the
iCalendar data as well as managing access privileges. The server can iCalendar data as well as manage 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 1.1. Rationale for Informational Status
Although this extension to CalDAV has wide deployment, its design Although this extension to CalDAV has wide deployment, its design
does not comply with some of the best current practices of HTTP, does not comply with some of the best current practices of HTTP,
namely: namely:
o All operations on attachments are modeled as HTTP POST operations, o All operations on attachments are modeled as HTTP POST operations,
where the actual type of operation is specified using a query where the actual type of operation is specified using a query
parameter, instead of using separate HTTP POST, PUT, and DELETE parameter instead of using separate HTTP POST, PUT, and DELETE
methods where appropriate. methods where appropriate.
o Specific query strings are hardwired into the protocol in o Specific query strings are hardwired into the protocol in
violation of Section 2.4 of [RFC7320]. violation of Section 2.4 of [RFC7320].
Additionally, this extension misuses the Content-Disposition header Additionally, this extension misuses the Content-Disposition header
field [RFC6266] as a request header field to convey a filename for an field [RFC6266] as a request header field to convey a filename for an
attachment rather than using an existing request header field attachment rather than using an existing request header field
suitable for that purpose, such as "Slug" (see Section 9.7 of suitable for that purpose, such as "Slug" (see Section 9.7 of
[RFC5023]). [RFC5023]).
skipping to change at page 4, line 36 skipping to change at page 4, line 36
updating the design of this extension to be compliant with best updating the design of this extension to be compliant with best
current practices and to allow this specification to be placed on the current practices and to allow this specification to be placed on the
Standards Track, it was decided to simply document how existing Standards Track, it was decided to simply document how existing
implementations interoperate and to publish the document as implementations interoperate and to publish the document as
Informational. 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 BCP "OPTIONAL" in this document are to be interpreted as described in
14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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 perform with
for calendar data: add, update, remove, and retrieve. The first attachments for calendar data: add, update, remove, and retrieve.
three operations are carried out by the client issuing an HTTP POST The first three operations are carried out by the client issuing an
request on the calendar object resource to which the attachment is HTTP POST request on the calendar object resource to which the
associated and specifying the appropriate "action" query parameter attachment is associated and specifying the appropriate "action"
(see Section 3.3). In the case of the remove operation, the client query parameter (see Section 3.3). In the case of the remove
can alternatively directly update the calendar object resource and operation, the client can alternatively directly update the calendar
remove the relevant "ATTACH" properties (see Section 3.9). The object resource and remove the relevant "ATTACH" properties (see
retrieve operation is accomplished by simply issuing an HTTP GET Section 3.9). The retrieve operation is accomplished by simply
request targeting the attachment URI specified by the calendar issuing an HTTP GET request targeting the attachment URI specified by
resource's "ATTACH" property (see Section 3.10). 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 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 token in the DAV response include "calendar-managed-attachments" as a token in the DAV response
header field (as defined in Section 10.1 of [RFC4918]) from an header field (as defined in Section 10.1 of [RFC4918]) from an
OPTIONS request on a calendar home collection. OPTIONS request on a calendar home collection.
A server might choose to not support storing managed attachments on a A server might choose not to support the storing of managed
per-recurrence instance basis (i.e., they can only be added to all attachments on a per-recurrence-instance basis (i.e., they can only
instances as a whole). If that is the case, the server MUST also be added to all instances as a whole). If that is the case, the
include "calendar-managed-attachments-no-recurrence" as a token in server MUST also include "calendar-managed-attachments-no-recurrence"
the DAV response header field from an OPTIONS request on a calendar as a token in the DAV response header field from an OPTIONS request
home collection. When that field is present, clients MUST NOT on a calendar home collection. When that field is present, clients
attempt any managed attachment operations that target specific MUST NOT attempt any managed attachment operations that target
recurrence instances. specific 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.
These requests are subject to the preconditions listed in These requests are subject to the preconditions listed in
Section 3.11. The request-URI will contain various query parameters Section 3.11. The Request-URI will contain various query parameters
to specify the behavior. 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.
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:
https://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 (denoted in ASCII as "0x2C"). The item values
forms: can be in one of two 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
its "RECURRENCE-ID" value as the item value. That value MUST using its "RECURRENCE-ID" value as the item value. That value
correspond to the RECURRENCE-ID value as stored in the calendar MUST correspond to the "RECURRENCE-ID" value as stored in the
object resource (i.e. without any conversion to UTC). If multiple calendar object resource (i.e., without any conversion to UTC).
items of this form are used, they MUST be unique values. For If multiple items of this form are used, they MUST be unique
example, to target a recurrence defined by property RECURRENCE- values. For example, to target a recurrence defined by property
ID;TZID=America/Montreal:20111022T160000, the query parameter RECURRENCE-ID;TZID=America/Montreal:20111022T160000, the query
rid=20111022T160000 would be used. 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.2).
Example (targeting the master instance and a specific overridden Example (targeting the master instance and a specific overridden
instance): instance):
https://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" (Section 4.3) property parameter MUST match the "MANAGED-ID" (Section 4.3) property
parameter value on the "ATTACH" property in the calendar object parameter value on the "ATTACH" property in the calendar object
resource instance(s) 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:
https://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 needs to occur:
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 structured as follows:
A. The request-URI will include an "action" query parameter with A. The Request-URI will include an "action" query parameter with
the value "attachment-add" (see Section 3.3.1). the value "attachment-add" (see Section 3.3.1).
B. If all recurrence instances are having an attachment added, B. If all recurrence instances are having an attachment added,
the "rid" query parameter is not present in the request-URI. the "rid" query parameter is not present in the Request-URI.
If one or more specific recurrence instances are targeted, If one or more specific recurrence instances are targeted,
then the request-URI will include a "rid" query parameter then the Request-URI will include a "rid" query parameter
containing the list of instances (see Section 3.3.2). containing the list of instances (see Section 3.3.2).
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. Note that the use of Content-Disposition as a attachment. Note that the use of Content-Disposition as a
request header field is nonstandard and specific to this request header field is nonstandard and specific to this
protocol. 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
resource being targeted. resource being targeted.
B. Stores the supplied attachment data into a resource and B. Stores the supplied attachment data into a resource and
generates an appropriate URI for clients to access the generates an appropriate URI for clients to access the
resource. resource.
C. For each affected recurrence instance in the calendar object C. For each affected recurrence instance in the calendar object
resource targeted by the request, the server adds an "ATTACH" resource targeted by the request, adds an "ATTACH" property
property, whose value is the URI of the stored attachment. whose value is the URI of the stored attachment. The
The "ATTACH" property MUST contain a "MANAGED-ID" parameter "ATTACH" property MUST contain a "MANAGED-ID" property
whose value is a unique identifier (within the context of the parameter whose value is a unique identifier (within the
server as a whole). The "ATTACH" property SHOULD contain an context of the server as a whole). The "ATTACH" property
"FMTTYPE" parameter whose value matches the Content-Type SHOULD contain an "FMTTYPE" property parameter whose value
header field value from the request. The "ATTACH" property matches the Content-Type header field value from the request.
SHOULD contain an "FILENAME" parameter whose value matches The "ATTACH" property SHOULD contain a "FILENAME" property
the Content-Disposition header field "filename" parameter parameter whose value matches the value of the Content-
value from the request, taking into account the restrictions Disposition header field "filename" parameter value from the
expressed in Section 4.2. The "ATTACH" property SHOULD request, taking into account the restrictions expressed in
include a "SIZE" parameter whose value represents the size in Section 4.2. The "ATTACH" property SHOULD include a "SIZE"
octets of the attachment. If a specified recurrence instance property parameter whose value represents the size in octets
does not have a matching component in the calendar object of the attachment. If a specified recurrence instance does
not have a matching component in the calendar object
resource, then the server MUST modify the calendar object resource, then the server MUST modify the calendar object
resource to include an overridden component with the resource to include an overridden component with the
appropriate "RECURRENCE-ID" property. appropriate "RECURRENCE-ID" property.
D. Upon successful creation of the attachment resource, and D. Upon successful creation of the attachment resource, and
modification of the targeted calendar object resource, the modification of the targeted calendar object resource, it
server MUST return an appropriate HTTP success status MUST return an appropriate HTTP success status response and
response and include a "Cal-Managed-ID" header field include a "Cal-Managed-ID" header field containing the
containing the "MANAGED-ID" parameter value of the newly "MANAGED-ID" property parameter value of the newly created
created "ATTACH" property. The client can use the "Cal- "ATTACH" property. The client can use the "Cal-Managed-ID"
Managed-ID" header field value to correlate the attachment header field value to correlate the attachment with "ATTACH"
with "ATTACH" properties added to the calendar object properties added to the calendar object resource. If the
resource. If the client included a Prefer header field with client included a Prefer header field with the
the "return=representation" preference in the request, the "return=representation" preference in the request, the server
server SHOULD return the modified calendar object resource as SHOULD return the modified calendar object resource as the
the body of the response. Otherwise, the server can expect body of the response. Otherwise, the server can expect that
that the client will reload the calendar object resource with the client will reload the calendar object resource with a
a subsequent GET request to refresh any local cache. subsequent GET request to refresh any local cache.
In the following example, the client adds a new attachment to a non In the following example, the client adds a new attachment to a
recurring event and asks the server (via the Prefer [RFC7240] header nonrecurring event and asks the server (via the Prefer header field
field) to return the modified version of that event in the response. [RFC7240]) to return the modified version of that event in the
response.
>> Request << >> Request <<
POST /events/64.ics?action=attachment-add HTTP/1.1 POST /events/64.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: 59
Prefer: return=representation Prefer: return=representation
<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: 371
Content-Location: https://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
DTEND:20120715T040000Z DTEND:20120715T040000Z
SUMMARY:One-off meeting SUMMARY:One-off meeting
ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=xxxx; ATTACH;MANAGED-ID=97S;FMTTYPE=text/html;SIZE=59;
FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
3.5. Updating Attachments 3.5. Updating Attachments
When an attachment is updated the server MUST change the associated When an attachment is updated, the server MUST change the associated
"MANAGED-ID" parameter and MAY change the "ATTACH" property value. "MANAGED-ID" property parameter and MAY change the "ATTACH" property
With this approach, clients are able to determine when an attachment value. With this approach, clients are able to determine when an
has been updated by some other client by looking for a change to attachment has been updated by some other client by looking for a
either the "ATTACH" property value, or the "MANAGED-ID" parameter change to either the "ATTACH" property value or the "MANAGED-ID"
value. property parameter value.
To change the data of an existing managed attachment in a calendar To change the data of an existing managed attachment in a calendar
object resource, the following occurs: object resource, the following needs to occur:
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 structured as follows:
A. The request-URI will include an "action" query parameter with A. The Request-URI will include an "action" query parameter with
the value "attachment-update" (see Section 3.3.1). the value "attachment-update" (see Section 3.3.1).
B. The request-URI will include a "managed-id" query parameter B. The Request-URI will include a "managed-id" query parameter
with the value matching that of the "MANAGED-ID" parameter with the value matching that of the "MANAGED-ID" property
for the "ATTACH" property being updated (see Section 3.3.3). parameter for the "ATTACH" property being updated (see
Section 3.3.3).
C. The body of the request contains the updated data for the C. The body of the request contains the updated data for the
attachment. 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.
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 the "managed-id" query parameter is valid for A. Validates that the "managed-id" query parameter is valid for
the calendar object resource. the calendar object resource.
B. Updates the content of the attachment resource corresponding B. Updates the content of the attachment resource corresponding
to that managed-id with the supplied attachment data. to that "managed-id" value with the supplied attachment data.
C. For each affected recurrence instance in the calendar object C. For each affected recurrence instance in the calendar object
resource targeted by the request, the server updates the resource targeted by the request, updates the "ATTACH"
"ATTACH" property whose "MANAGED-ID" property parameter value property whose "MANAGED-ID" property parameter value matches
matches the "managed-id" query parameter. The "MANAGED-ID" the "managed-id" query parameter. The "MANAGED-ID" property
parameter value is changed to allow other clients to detect parameter value is changed to allow other clients to detect
the update, and the property value (attachment URI) might the update, and the property value (attachment URI) might
also be changed. The "ATTACH" property SHOULD contain a also be changed. The "ATTACH" property SHOULD contain a
"FMTTYPE" parameter whose value matches the Content-Type "FMTTYPE" property parameter whose value matches the Content-
header field value from the request - this could differ from Type header field value from the request; this could differ
the original value if the media type of the updated from the original value if the media type of the updated
attachment is different. The "ATTACH" property SHOULD attachment is different. The "ATTACH" property SHOULD
contain a "FILENAME" parameter whose value matches the contain a "FILENAME" property parameter whose value matches
Content-Disposition header field "filename" parameter value the Content-Disposition header field "filename" parameter
from the request, taking into account the restrictions value from the request, taking into account the restrictions
expressed in Section 4.2. The "ATTACH" property SHOULD expressed in Section 4.2. The "ATTACH" property SHOULD
include a "SIZE" parameter whose value represents the size in include a "SIZE" property parameter whose value represents
octets of the updated attachment. the size in octets of the updated attachment.
D. Upon successful update of the attachment resource, and D. Upon successful update of the attachment resource, and
modification of the targeted calendar object resource, the modification of the targeted calendar object resource, it
server MUST return an appropriate HTTP success status MUST return an appropriate HTTP success status response and
response, and include a "Cal-Managed-ID" header field include a "Cal-Managed-ID" header field containing the new
containing the new value of the "MANAGED-ID" parameter. The value of the "MANAGED-ID" property parameter. The client can
client can use the "Cal-Managed-ID" header field value to use the "Cal-Managed-ID" header field value to correlate the
correlate the attachment with "ATTACH" properties added to attachment with "ATTACH" properties added to the calendar
the calendar object resource. If the client included a object resource. If the client included a Prefer header
Prefer header field with the "return=representation" field with the "return=representation" preference in the
preference in the request, the server SHOULD return the request, the server SHOULD return the modified calendar
modified calendar object resource as the body of the object resource as the body of the response. Otherwise, the
response. Otherwise, the server can expect that the client server can expect that the client will reload the calendar
will reload the calendar object resource with a subsequent object resource with a subsequent GET request to refresh any
GET request to refresh any local cache. local cache.
The update operation does not take a "rid" parameter and does not The update operation does not take a "rid" query parameter and does
add, or remove, any "ATTACH" property in the targeted calendar object not add, or remove, any "ATTACH" property in the targeted calendar
resource. To link an existing attachment to a new instance, the object resource. To link an existing attachment to a new instance,
client simply does a PUT on the calendar object resource, adding an the client simply does a PUT on the calendar object resource, adding
"ATTACH" property which duplicates the existing one (see an "ATTACH" property that duplicates the existing one (see
Section 3.7). Section 3.7).
In the following example, the client updates an existing attachment In the following example, the client updates an existing attachment
and asks the server (via the Prefer [RFC7240] header field) to return and asks the server (via the Prefer header field [RFC7240]) to return
the updated version of that event in the response. the updated version of that event in the response.
>> Request << >> Request <<
POST /events/64.ics?action=attachment-update&managed-id=97S HTTP/1.1 POST /events/64.ics?action=attachment-update&managed-id=97S 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: 96
Prefer: return=representation Prefer: return=representation
<html> <html>
<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: 371
Content-Location: https://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
DTEND:20120715T040000Z DTEND:20120715T040000Z
SUMMARY:One-off meeting SUMMARY:One-off meeting
ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=xxxy; ATTACH;MANAGED-ID=98S;FMTTYPE=text/html;SIZE=96;
FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R FILENAME=agenda.html:https://cal.example.com/attach/64/34X22R
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
3.6. Removing Attachments via POST 3.6. Removing Attachments via POST
To remove an existing attachment from a calendar object, the To remove an existing attachment from a calendar object, the
following occurs: following needs to occur:
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 structured as follows:
A. The request-URI will include an "action" query parameter with A. The Request-URI will include an "action" query parameter with
the value "attachment-remove" (see Section 3.3.1). the value "attachment-remove" (see Section 3.3.1).
B. If all recurrence instances are having an attachment removed, B. If all recurrence instances are having an attachment removed,
the "rid" query parameter is not present in the request-URI. the "rid" query parameter is not present in the Request-URI.
If one or more specific recurrence instances are targeted, If one or more specific recurrence instances are targeted,
then the request-URI will include a "rid" query parameter then the Request-URI will include a "rid" query parameter
containing the list of instances (see Section 3.3.2). containing the list of instances (see Section 3.3.2).
C. The request-URI will include a "managed-id" query parameter C. The Request-URI will include a "managed-id" query parameter
with the value matching that of the "MANAGED-ID" property with the value matching that of the "MANAGED-ID" property
parameter for the "ATTACH" property being removed (see parameter for the "ATTACH" property being removed (see
Section 3.3.3). Section 3.3.3).
D. The body of the request will be empty. D. The body of the request will be empty.
E. The client MAY include a Prefer header field [RFC7240] with E. 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
resource being targeted. resource being targeted.
B. Validates that the "managed-id" query parameter is valid for B. Validates that the "managed-id" query parameter is valid for
the calendar object resource and specific instances being the calendar object resource and specific instances being
targeted. targeted.
C. For each affected recurrence instance in the calendar object C. For each affected recurrence instance in the calendar object
resource targeted by the request, the server removes the resource targeted by the request, removes the matching
matching "ATTACH" property. Note that if a specified "ATTACH" property. Note that if a specified recurrence
recurrence instance does not have a matching component in the instance does not have a matching component in the calendar
calendar object resource, then the server MUST modify the object resource, then the server MUST modify the calendar
calendar object resource to include an overridden component object resource to include an overridden component with the
with the appropriate "RECURRENCE-ID" property, and the appropriate "RECURRENCE-ID" property and the matching
matching "ATTACH" property removed. This later case is "ATTACH" property removed. This latter case is actually
actually valid only if the master component does include the valid only if the master component does include the
referenced "ATTACH" property. referenced "ATTACH" property.
D. If the attachment resource is no longer referenced by any D. If the attachment resource is no longer referenced by any
instance of the calendar object resource, the server can instance of the calendar object resource, it can delete the
delete the attachment resource to free up storage space. attachment resource to free up storage space.
E. Upon successful removal of the attachment resource and E. Upon successful removal of the attachment resource and
modification of the targeted calendar object resource, the modification of the targeted calendar object resource, it
server MUST return an appropriate HTTP success status MUST return an appropriate HTTP success status response. If
response. If the client included a Prefer header field with the client included a Prefer header field with the
the "return=representation" preference in the request, the "return=representation" preference in the request, the server
server SHOULD return the modified calendar object resource as SHOULD return the modified calendar object resource as the
the body of the response. Otherwise, the server can expect body of the response. Otherwise, the server can expect that
that the client will reload the calendar object resource with the client will reload the calendar object resource with a
a subsequent GET request to refresh any local cache. subsequent GET request to refresh any local cache.
In the following example, the client deletes an existing attachment In the following example, the client deletes an existing attachment
by passing its managed-id in the request. The Prefer [RFC7240] by passing its "managed-id" value in the request. The Prefer header
header field is not set in the request so the calendar object field [RFC7240] is not set in the request so the calendar object
resource data is not returned in the response. resource data is not returned in the response.
>> Request << >> Request <<
POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1 POST /events/64.ics?action=attachment-remove&managed-id=98S HTTP/1.1
Host: cal.example.com Host: cal.example.com
Content-Length: 0 Content-Length: 0
>> 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) to the restrictions described in Section 3.12.2).
If a managed attachment is used in more than calendar resource, 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" property parameter
the "ATTACH" property value for these attachments - this ensures that value or the "ATTACH" property value for these attachments; this
clients do not have to download the attachment data again if they ensures that clients do not have to download the attachment data
already have it cached. Additionally, servers SHOULD validate "SIZE" again if they already have it cached. Additionally, servers SHOULD
parameter values and replace incorrect values with the actual sizes validate "SIZE" property parameter values and replace incorrect
of existing attachments. values with the actual sizes of existing attachments.
These PUT requests are subject to the preconditions listed in These PUT requests are subject to the preconditions listed in
Section 3.11. 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
Clients can remove attachments by simply re-writing the calendar Clients can remove attachments by simply rewriting the calendar
object resource data to remove the appropriate "ATTACH" properties. object resource data to remove the appropriate "ATTACH" properties.
Servers MUST NOT allow clients to delete attachments directly via a Servers MUST NOT allow clients to delete attachments directly via a
DELETE request on the attachment URI. DELETE request on the attachment URI.
3.10. Retrieving Attachments 3.10. Retrieving Attachments
Clients retrieve attachments by issuing an HTTP GET request using the Clients retrieve attachments by issuing an HTTP GET request using the
value of the corresponding "ATTACH" property as the request-URI, value of the corresponding "ATTACH" property as the Request-URI,
taking into account the substitution mechanism associated with the taking into account the substitution mechanism associated with the
"CALDAV:managed-attachments-server-URL" property (see Section 6.1). "CALDAV:managed-attachments-server-URL" property (see Section 6.1).
3.11. Error Handling 3.11. Error Handling
This specification creates additional preconditions for the POST This specification creates additional preconditions for the POST
method. method.
The new preconditions are: The new preconditions are:
(CALDAV:max-attachment-size): The attachment submitted in the POST (CALDAV:max-attachment-size): The attachment submitted in the POST
request MUST have an octet size less than or equal to the value of request MUST have an octet size less than or equal to the value of
the CALDAV:max-attachment-size property value (Section 6.2) on the the "CALDAV:max-attachment-size" property value (Section 6.2) on
calendar collection of the target calendar resource; the 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 (CALDAV:valid-action): The "action" query parameter in the POST
request MUST contain one of "attachment-add", "attachment-update", request MUST contain only one of the following three values:
or "attachment-remove". "attachment-add", "attachment-update", or "attachment-remove".
(CALDAV:valid-rid): The rid query parameter in the POST request (CALDAV:valid-rid): The "rid" query parameter in the POST request
MUST NOT be present for an attachment-update action, and MUST MUST NOT be present with an "action=attachment-update" query
contain the value "M" and/or values corresponding to "RECURRENCE- parameter and MUST contain the value "M" and/or values
ID" property values in the iCalendar data targeted by the request. 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 NOT be present for an attachment-add action, and POST request MUST NOT be present with an "action=attachment-add"
MUST contain a value corresponding to a "MANAGED-ID" property query parameter and MUST contain a value corresponding to a
parameter value in the iCalendar data targeted by the request. "MANAGED-ID" property 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 an 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 precondition 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: If a precondition for a request is not satisfied:
1. The response status of the request MUST either be 403 1. The response status of the request MUST either be 403 (Forbidden)
(Forbidden), if the request should not be repeated because it if the request should not be repeated because it will always
will always fail, or 409 (Conflict), if it is expected that the fail, or 409 (Conflict) if it is expected that the user might be
user might be able to resolve the conflict and resubmit the able to resolve the conflict and resubmit the request.
request.
2. The appropriate XML element MUST be returned as the child of a 2. The appropriate XML element MUST be returned as the child of a
top-level DAV:error element in the response body. 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 specification [RFC4331] 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 attachment sizes when
calculating the amount of storage used by a particular resource. calculating the amount of storage used by a particular resource.
3.12.2. Access Control 3.12.2. Access Control
Access to the managed attachments store in a calendar object resource Access to the managed attachments referenced in a calendar object
SHOULD be restricted to only those calendar users who have access to resource SHOULD be restricted to only those calendar users who have
that calendar object either directly, or indirectly (via being an access to that calendar object either directly or indirectly (via
attendee who would receive a scheduling message). being an attendee who would receive a scheduling message).
When accessing a managed attachment, clients SHOULD be prepared to When accessing a managed attachment, clients SHOULD be prepared to
authenticate with the server storing the attachment resource. The authenticate with the server storing the attachment resource. The
credentials required to access the managed attachment store could be credentials required to access the managed attachment store could be
different from the ones used to access the CalDAV server. different from the ones used to access the CalDAV server.
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 reusing a
managed attachment (based on its managed-id value), unless that user managed attachment (based on its "managed-id" value), unless that
is the one who originally created the managed attachment. user 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 a 307 (Temporary Redirect) [RFC7231] or 308 (Permanent issue a 307 (Temporary Redirect) [RFC7231] or 308 (Permanent
Redirect) [RFC7538] response to require the client to re-issue the Redirect) [RFC7538] response to require the client to reissue the
POST request using a different request-URI. As a result, clients POST request using a different Request-URI. As a result, clients
SHOULD use the "100-continue" expectation defined in Section 5.1.1 of SHOULD use the "100-continue" expectation defined in Section 5.1.1 of
[RFC7231]. Using this mechanism ensures that, if a redirect does [RFC7231]. Using this mechanism ensures that, if a redirect does
occur, the client does not needlessly send the 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 Cleanup 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
calendar object resource, the server MUST ensure that a scheduling calendar object resource, the server MUST ensure that a scheduling
message is sent to update any attendees with the changes, as per message is sent to update any attendees with the changes, as per
[RFC6638]. [RFC6638].
3.12.7. Migrating Calendar Data 3.12.7. Migrating Calendar Data
When exporting calendar data from a CalDAV server supporting managed When exporting calendar data from a CalDAV server supporting managed
attachments, clients SHOULD remove all "MANAGED-ID" property attachments, clients SHOULD remove all "MANAGED-ID" property
parameters from "ATTACH" properties in the calendar data. Similarly parameters from "ATTACH" properties in the calendar data. Similarly,
when importing calendar data from another source, clients SHOULD when importing calendar data from another source, clients SHOULD
remove any "MANAGED-ID" property parameters on "ATTACH" properties remove any "MANAGED-ID" property parameters on "ATTACH" properties
(failure to do so will likely result in the server removing those (failure to do so will likely result in the server removing those
properties automatically). properties automatically).
4. Modifications to iCalendar Syntax 4. Modifications to iCalendar Syntax
4.1. SIZE Property Parameter 4.1. SIZE Property Parameter
Parameter Name: SIZE Parameter Name: SIZE
Purpose: To specify the size of an attachment. Purpose: To specify the size of an attachment.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
sizeparam = "SIZE" "=" paramtext sizeparam = "SIZE" "=" paramtext
; 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 property parameter is
text to allow an extended range to be used. defined as text to allow an extended range to be used.
Example: Example:
ATTACH;SIZE=1234:https://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 filename 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:
filenameparam = "FILENAME" "=" paramtext filenameparam = "FILENAME" "=" paramtext
Description: This property parameter MAY be specified on "ATTACH" Description: This property parameter MAY be specified on "ATTACH"
properties corresponding to managed attachments. Its value properties corresponding to managed attachments. Its value
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 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 property parameter value. Similarly, servers MUST
those same guidelines before storing a value. follow those same guidelines before storing a value.
Example: Example:
ATTACH;FILENAME=agenda.html:https://attachments.example.c ATTACH;FILENAME=agenda.html:
om/rt452S https://attachments.example.com/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 within the scope of the CalDAV server. This property attachment within the scope of the CalDAV server. This property
parameter MUST NOT be present in the case of non-managed parameter MUST NOT be present in the case of unmanaged
attachments. attachments.
Example: Example:
ATTACH;MANAGED-ID=aUNhbGVuZGFy:https://attachments.example.c ATTACH;MANAGED-ID=aUNhbGVuZGFy:
om/abcd.txt https://attachments.example.com/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" property parameter corresponding to a newly added
"ATTACH" property.
ABNF: 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 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 in response to a successful POST request with an "action" query
attachment-add or attachment-update. It MUST only appear once in a parameter set to "attachment-add" or "attachment-update". It MUST
response and MUST NOT appear in trailers. 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 The Cal-Managed-ID header field is end to end and MUST be forwarded
by intermediaries. Intermediaries MUST NOT insert, delete, or modify by intermediaries. Intermediaries MUST NOT insert, delete, or modify
a Cal-Managed-ID header field. 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: This property specifies the server base URI to use when
managed attachments. retrieving managed attachments.
Protected: This property MUST be protected as only the server can Protected: This property MUST be protected as only the server can
update the value. update the value.
COPY/MOVE behavior: This property is only defined on a calendar home COPY/MOVE behavior: This property is only defined on a calendar home
collection which cannot be moved or copied. collection, which cannot be moved or copied.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop allprop behavior: This property SHOULD NOT be returned by a PROPFIND
request. DAV:allprop request.
Description: This property MAY be defined on a calendar home Description: This property MAY be defined on a calendar home
collection. If present, it contains zero or one DAV:href XML collection. If present, it contains either a single DAV:href XML
elements. element or none at all.
When one DAV:href element is present, its value MUST be an When one DAV:href element is present, its value MUST be an
absolute HTTP URI containing only the scheme (i.e. "https") and absolute HTTP URI containing only the scheme (i.e., "https") and
authority (i.e. host and port) parts . Whenever a managed authority (i.e., host and port) parts. Whenever a managed
attachment is to be retrieved via an HTTP GET, the client MUST attachment is to be retrieved via an HTTP GET, the client MUST
construct the actual URL of the attachment by substituting the construct the actual URL of the attachment by substituting the
scheme and authority parts of the attachment URI (as stored in the scheme and authority parts of the attachment URI (as stored in the
iCalendar "ATTACH" property) with the present WebDAV property iCalendar "ATTACH" property) with the present WebDAV property
value. value.
When no DAV:href element is present, the client MUST substitute When no DAV:href element is present, the client MUST substitute
the scheme and authority parts of the attachment URI with the the scheme and authority parts of the attachment URI with the
scheme and authority part of the calendar home collection absolute scheme and authority part of the calendar home collection absolute
URI. URI.
skipping to change at page 22, line 4 skipping to change at page 22, line 11
the scheme and authority parts of the attachment URI with the the scheme and authority parts of the attachment URI with the
scheme and authority part of the calendar home collection absolute scheme and authority part of the calendar home collection absolute
URI. URI.
In the absence of this property, the client can consider the In the absence of this property, the client can consider the
attachment URI as its actual URL. attachment URI as its actual URL.
Definition: Definition:
<!ELEMENT managed-attachments-server-URL (DAV:href?)> <!ELEMENT managed-attachments-server-URL (DAV:href?)>
Example: Example:
<C:managed-attachments-server-URL xmlns:D="DAV:" <C:managed-attachments-server-URL xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav"> xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>https://attachstore.example.com</D:href> <D:href>https://attachstore.example.com</D:href>
</C:managed-attachments-server-URL> </C:managed-attachments-server-URL>
6.2. CALDAV:max-attachment-size property 6.2. CALDAV:max-attachment-size Property
Name: max-attachment-size Name: max-attachment-size
Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Provides a numeric value indicating the maximum attachment Purpose: This property provides a numeric value indicating the
size, in octets, that the server is willing to accept when a maximum attachment size, in octets, that the server is willing to
managed attachment is stored on the server. accept when a managed attachment is stored on the server.
Protected: MUST be protected as it indicates limits provided by the Protected: This property MUST be protected as it indicates limits
server. provided by the server.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop allprop behavior: This property SHOULD NOT be returned by a PROPFIND
request. DAV:allprop request.
Description: The CALDAV:max-attachment-size property is used to Description: The "CALDAV:max-attachment-size" property is used to
specify a numeric value that represents the maximum attachment specify a numeric value that represents the maximum attachment
size, in octets, that the server is willing to accept when a size, in octets, that the server is willing to accept when a
managed attachment is stored on the server. The property is managed attachment is stored on the server. The property is
defined on the parent collection of the calendar object resource defined on the parent collection of the calendar object resource
to which the attachment is associated. Any attempt to store a to which the attachment is associated. Any attempt to store a
managed attachment exceeding this size MUST result in an error, managed attachment exceeding this size MUST result in an error,
with the CALDAV:max-attachment-size precondition (Section 3.11) with the CALDAV:max-attachment-size precondition (Section 3.11)
being violated. In the absence of this property, the client can being violated. In the absence of this property, the client can
assume that the server will allow storing an attachment of any assume that the server will allow storing an attachment of any
reasonable size. reasonable size.
skipping to change at page 23, line 5 skipping to change at page 23, line 15
Definition: Definition:
<!ELEMENT max-attachment-size (#PCDATA)> <!ELEMENT max-attachment-size (#PCDATA)>
<!-- PCDATA value: a numeric value (positive decimal integer) --> <!-- PCDATA value: a numeric value (positive decimal integer) -->
Example: Example:
<C:max-attachment-size xmlns:C="urn:ietf:params:xml:ns:caldav" <C:max-attachment-size xmlns:C="urn:ietf:params:xml:ns:caldav"
>102400000</C:max-attachment-size> >102400000</C:max-attachment-size>
6.3. CALDAV:max-attachments-per-resource property 6.3. CALDAV:max-attachments-per-resource Property
Name: max-attachments-per-resource Name: max-attachments-per-resource
Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Provides a numeric value indicating the maximum number of Purpose: This property provides a numeric value indicating the
managed attachments across all instances of a calendar object maximum number of managed attachments across all instances of a
resource stored in a calendar collection. calendar object resource stored in a calendar collection.
Protected: MUST be protected as it indicates limits provided by the Protected: This property MUST be protected as it indicates limits
server. provided by the server.
COPY/MOVE behavior: This property value MUST be preserved in COPY COPY/MOVE behavior: This property value MUST be preserved in COPY
and MOVE operations. and MOVE operations.
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop allprop behavior: This property SHOULD NOT be returned by a PROPFIND
request. DAV:allprop request.
Description: The CALDAV:max-attachments-per-resource property is Description: The "CALDAV:max-attachments-per-resource" property is
used to specify a numeric value that represents the maximum number used to specify a numeric value that represents the maximum number
of managed attachments across all instances of a calendar object of managed attachments across all instances of a calendar object
resource stored in a calendar collection. Non-managed attachments resource stored in a calendar collection. Unmanaged attachments
are not counted toward that limit. The property is defined on the are not counted toward that limit. The property is defined on the
parent collection of the calendar object resource to which the parent collection of the calendar object resource to which the
attachment is associated. Any attempt to add a managed attachment attachment is associated. Any attempt to add a managed attachment
that would cause the calendar resource to exceed this limit MUST that would cause the calendar resource to exceed this limit MUST
result in an error, with the CALDAV:max-attachments-per-resource result in an error, with the CALDAV:max-attachments-per-resource
precondition (Section 3.11) being violated. In the absence of precondition (Section 3.11) being violated. In the absence of
this property, the client can assume that the server can handle this property, the client can assume that the server can handle
any number of managed attachments per calendar resource. any number of managed attachments per calendar resource.
Definition: Definition:
skipping to change at page 23, line 41 skipping to change at page 24, line 4
that would cause the calendar resource to exceed this limit MUST that would cause the calendar resource to exceed this limit MUST
result in an error, with the CALDAV:max-attachments-per-resource result in an error, with the CALDAV:max-attachments-per-resource
precondition (Section 3.11) being violated. In the absence of precondition (Section 3.11) being violated. In the absence of
this property, the client can assume that the server can handle this property, the client can assume that the server can handle
any number of managed attachments per calendar resource. any number of managed attachments per calendar resource.
Definition: Definition:
<!ELEMENT max-attachments-per-resource (#PCDATA)> <!ELEMENT max-attachments-per-resource (#PCDATA)>
<!-- 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. Security Considerations
< RFC Editor: before publication please remove this section, the
reference to [RFC7942], and any resulting "URIs" references sub-
section. >
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
7.1. Calendar and Contacts Server
The open source Calendar and Contacts Server [2] project is a
standards-compliant server implementing the CalDAV protocol. This
production level implementation supports all of the requirements
described in this document and successfully interoperates with the
Apple Calendar, BusyCal, 2Do, and CalDAVTester client implementations
described below. This implementation is freely distributable under
the terms of the Apache License, Version 2.0 [3].
7.2. Cyrus Server
The open source Cyrus Server [4] project is a highly scalable
enterprise mail system which also supports calendaring. This
production level CalDAV implementation supports all of the
requirements described in this document and successfully
interoperates with the Apple Calendar and CalDAVTester client
implementations described below. This implementation is freely
distributable under a BSD style license from Computing Services at
Carnegie Mellon University [5].
7.3. Oracle Communications Calendar Server
The Oracle Communications Calendar Server [6] project is a standards-
compliant, scalable, enterprise-ready calendaring solution. This
production level CalDAV implementation supports all of the
requirements described in this document and successfully
interoperates with the Apple Calendar and CalDAVTester client
implementations described below. This implementation is proprietary
and available for a free trial and/or purchase from the vendor.
7.4. Apple Calendar
The widely used Apple Calendar [7] client is a standards-compliant
client implementing the CalDAV protocol. This production level
implementation supports all the requirements described in this
document and successfully interoperates with the
Calendar and Contacts Server, Cyrus Server, and
Oracle Communications Calendar Server implementations described
above. This client implementation is proprietary and is distributed
as part of Apple's desktop operating systems.
7.5. BusyCal
BusyCal [8] is a standards-compliant calendar client for MacOS
implementing the CalDAV protocol. This implementation supports all
of the requirements described in this document and successfully
interoperates with the Calendar and Contacts Server and Cyrus Server
implementations described above. This implementation is proprietary
and available for a free trial and/or purchase from the vendor.
7.6. CalDAVTester
CalDAVTester [9] is an open source test and performance application
designed to work with CalDAV servers and tests various aspects of
their protocol handling as well as performance. This widely used
implementation supports all of the requirements described in this
document and successfully interoperates with the server
implementations described above. This implementation is freely
distributable under the terms of the Apache License, Version 2.0
[10].
7.7. 2Do
2Do [11] is a standards-complient calendar client for iOS which uses
the CalDAV standard for communication. This implementation supports
all of the requirements described in this document and successfully
interoperates with the Calendar and Contacts Server implementation
described above. This implementation is proprietary and available
for purchase from the vendor.
8. Security Considerations
The security considerations in [RFC4791] and [RFC4918] apply to this The security considerations in [RFC4791] and [RFC4918] apply to this
extension. Additionally, servers need to be aware that a client extension. Additionally, servers need to be aware that a client
could attack underlying storage by POSTing extremely large could attack underlying storage by POSTing extremely large
attachments and could attack processing time by uploading a recurring attachments and could attack processing time by uploading a recurring
event with a large number of overrides and then repeatedly adding, event with a large number of overrides and then repeatedly adding,
updating, and deleting attachments. updating, and deleting attachments.
Malicious content could be introduced into the calendar server by way 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 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 8. IANA Considerations
9.1. Parameter Registrations 8.1. Parameter Registrations
This specification defines the following new iCalendar property This specification defines the following new iCalendar property
parameters to be added to the registry defined in Section 8.2.3 of parameters to be added to the "Parameters" registry defined in
[RFC5545]: Section 8.2.4 of [RFC5545]:
+--------------------+---------+----------------------+ +------------+---------+-----------------------+
| Property Parameter | Status | Reference | | Parameter | Status | Reference |
+--------------------+---------+----------------------+ +------------+---------+-----------------------+
| SIZE | Current | RFCXXXX, Section 4.1 | | SIZE | Current | RFC 8607, Section 4.1 |
| FILENAME | Current | RFCXXXX, Section 4.2 | | FILENAME | Current | RFC 8607, Section 4.2 |
| MANAGED-ID | Current | RFCXXXX, Section 4.3 | | MANAGED-ID | Current | RFC 8607, Section 4.3 |
+--------------------+---------+----------------------+ +------------+---------+-----------------------+
9.2. Message Header Field Registrations 8.2. Message Header Field Registrations
The message header fields below should be added to the Permanent The message header fields below should be added to the "Permanent
Message Header Field Registry (see [RFC3864]). Message Header Field Names" registry (see [RFC3864]).
9.2.1. Cal-Managed-ID 8.2.1. Cal-Managed-ID
Header field name: Cal-Managed-ID Header field name: Cal-Managed-ID
Applicable protocol: http Protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): this specification (Section 5.1) Reference: this specification (Section 5.1)
Related information: none Related information: none
10. Acknowledgments 9. References
This specification came about via discussions at the Calendaring and
Scheduling Consortium. Thanks in particular to Mike Douglass and
Eric York.
11. References
11.1. Normative References 9.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,
<https://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,
<https://www.rfc-editor.org/info/rfc2518>. <https://www.rfc-editor.org/info/rfc2518>.
skipping to change at page 28, line 41 skipping to change at page 27, line 5
<https://www.rfc-editor.org/info/rfc7240>. <https://www.rfc-editor.org/info/rfc7240>.
[RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538,
April 2015, <https://www.rfc-editor.org/info/rfc7538>. April 2015, <https://www.rfc-editor.org/info/rfc7538>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 9.2. Informative References
[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
October 2007, <https://www.rfc-editor.org/info/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,
<https://www.rfc-editor.org/info/rfc5546>. <https://www.rfc-editor.org/info/rfc5546>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014, RFC 7320, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>. <https://www.rfc-editor.org/info/rfc7320>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<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,
<https://www.rfc-editor.org/info/rfc8144>. <https://www.rfc-editor.org/info/rfc8144>.
11.3. URIs Appendix A. Example Involving Recurring Events
[1] https://tools.ietf.org/html/bcp14
[2] http://calendarserver.org/
[3] http://www.apache.org/licenses/LICENSE-2.0.html
[4] http://www.cyrusimap.org/
[5] http://www.cmu.edu/computing/
[6] http://www.cyrusimap.org/
[7] http://www.apple.com/macos/
[8] http://www.busymac.com/busycal/
[9] http://calendarserver.org/wiki/CalDAVTester
[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
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:
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:
1. Moved "Error Handling" into its own sub-section.
2. Split "Other Client Considerations" into "Processing Time" and
"Migrating Calendar Data".
Changes in calext-01:
1. Changed all instances of "header" to "header field".
2. Reworked wording of Prefer header field handling.
3. Switched to recommending 102 (Processing) interim response to
keep the client connection alive.
4. Fixed description of Cal-Managed-ID response header field to
state that it is also required in responses to successful
attachment-update.
5. Minor editorial changes.
Changes in calext-00:
1. Added Murchison as editor.
2. Updated HTTP references to RFC7230 and RFC7231.
3. Updated Prefer header field references to RFC7240.
4. Added Implementation Status section.
5. Minor editorial changes.
Changes in daboo-03:
1. Fixed some examples.
2. Fixed return-representation -> return=representation.
3. Added statement that servers must not allow clients to DELETE
attachments directly.
4. Added new preconditions for valid managed-id values.
5. Filled out Access Control section.
6. Allow servers to not support per-instance attachments and
advertise that fact to clients.
Changes in daboo-02:
1. MANAGED-ID changes on PUT.
2. MTAG has been removed.
3. Error pre-conditions added.
4. Interaction with WebDAV QUOTA discussed.
5. max-attachment-* limits added.
6. Updated references.
7. Removed MUST for specific 2xx codes in favor of generic success
code.
Changes in daboo-01:
1. Tweaked OPTIONS capability wording.
2. Added section on clients expecting 100-Continue for delayed
response.
3. Added text for clean-up and use of HTTP 410 on orphans.
4. Added text on removing "MANAGED-ID" when exporting/importing
calendar data.
5. Added protocol examples.
6. Added MTAG property parameter on ATTACH property
7. Added FILENAME property parameter on ATTACH property
8. "id" query parameter is now "managed-id".
9. Use of Cal-Managed-ID header instead of Location header in
responses.
10. rid query param MUST contain RECURRENCE-ID without any
conversion to UTC (case of floating events).
11. Introduced CALDAV:managed-attachments-server-URL property
12. Made support for Prefer header a MUST for servers.
Appendix B. Example Involving Recurring Events
In the following example, the organizer of a recurring meeting makes In the following example, the organizer of a recurring meeting makes
an unsuccessful attempt to add an agenda (HTML attachment) to the an unsuccessful attempt to add an agenda (HTML attachment) to the
corresponding calendar resource with a conditional request. Note corresponding calendar resource with a conditional request. Note
that the client includes both the Expect and Prefer header fields in that the client includes both the Expect and Prefer header fields in
the request, thereby preventing itself from needlessly sending the the request, thereby preventing itself from needlessly sending the
attachment data, and requesting that the current resource be returned attachment data and requesting that the current resource be returned
in the failure response (see Section 3.2 of [RFC8144]). in the failure response (see Section 3.2 of [RFC8144]).
>> 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: 80
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: 929
Content-Location: https://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
skipping to change at page 34, line 49 skipping to change at page 30, line 4
SUMMARY:Planning Meeting SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
e.com e.com
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
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
The organizer of a recurring meeting successfully adds an agenda The organizer of a recurring meeting successfully adds an agenda
(HTML attachment) to the corresponding calendar resource. Attendees (HTML attachment) to the corresponding calendar resource. Attendees
of the meeting are granted read access to the newly created 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
and they are notified of the change via their scheduling inbox. resource, 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: 80
If-Match: "123456789-000-000" If-Match: "123456789-000-000"
Expect: 100-continue Expect: 100-continue
Prefer: return=representation Prefer: return=representation
>> Interim Response << >> Interim Response <<
HTTP/1.1 100 Continue HTTP/1.1 100 Continue
>> Request Body << >> Request Body <<
<html> <html>
<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: 1043
Content-Location: https://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
skipping to change at page 36, line 48 skipping to change at page 31, line 48
DURATION:PT1H DURATION:PT1H
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
SUMMARY:Planning Meeting SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
e.com e.com
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=80;
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 an overridden instance is specifying the "rid" query parameter. Note that an overridden
created with the RECURRENCE-ID property value matching the value of instance is created with the "RECURRENCE-ID" property value matching
the "rid" query parameter in the request. Also note that the server the value of the "rid" query parameter in the request. Also, note
takes significant time to complete the request and notifies the that the server takes significant time to complete the request and
client accordingly. 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: 105
If-Match: "123456789-000-111" If-Match: "123456789-000-111"
Expect: 100-continue Expect: 100-continue
Prefer: return=representation Prefer: return=representation
>> Interim Response << >> Interim Response <<
HTTP/1.1 100 Continue HTTP/1.1 100 Continue
>> Request Body << >> Request Body <<
skipping to change at page 37, line 44 skipping to change at page 32, line 44
</html> </html>
>> 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: 1661
Content-Location: https://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
skipping to change at page 38, line 39 skipping to change at page 33, line 39
DURATION:PT1H DURATION:PT1H
RRULE:FREQ=WEEKLY RRULE:FREQ=WEEKLY
SUMMARY:Planning Meeting SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@exampl
e.com e.com
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=80;
FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R FILENAME=agenda.html:https://cal.example.com/attach/65/34X22R
END:VEVENT END:VEVENT
BEGIN:VEVENT BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com UID:20010712T182145Z-123401@example.com
RECURRENCE-ID;TZID=America/Montreal:20120220T100000 RECURRENCE-ID;TZID=America/Montreal:20120220T100000
DTSTAMP:20120201T203412Z DTSTAMP:20120201T203412Z
DTSTART;TZID=America/Montreal:20120220T100000 DTSTART;TZID=America/Montreal:20120220T100000
DURATION:PT1H DURATION:PT1H
SUMMARY:Planning Meeting SUMMARY:Planning Meeting
ORGANIZER:mailto:cyrus@example.com ORGANIZER:mailto:cyrus@example.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example. ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:cyrus@example.
com com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:arnaudq@exampl
e.com e.com
ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION:mailto:mike@examp
le.com le.com
ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=xxxx; ATTACH;MANAGED-ID=33225;FMTTYPE=text/html;SIZE=105;
FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225 FILENAME=agenda0220.html:https://cal.example.com/attach/65/FGZ225
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
Acknowledgments
This specification came about via discussions at the Calendaring and
Scheduling Consortium. Thanks in particular to Mike Douglass and
Eric York.
Authors' Addresses Authors' Addresses
Cyrus Daboo Cyrus Daboo
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
USA United States of America
Email: cyrus@daboo.name Email: cyrus@daboo.name
URI: http://www.apple.com/ URI: http://www.apple.com/
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 US LLC FastMail US LLC
1429 Walnut St, Suite 1201 1429 Walnut St, Suite 1201
Philadephia, PA 19102 Philadephia, PA 19102
USA United States of America
Email: murch@fastmailteam.com Email: murch@fastmailteam.com
URI: http://www.fastmail.com/ URI: http://www.fastmail.com/
 End of changes. 165 change blocks. 
632 lines changed or deleted 368 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/