draft-ietf-calext-caldav-attachments-01.txt   draft-ietf-calext-caldav-attachments-02.txt 
Calendering Extensions C. Daboo Calendering Extensions C. Daboo
Internet-Draft Apple Internet-Draft Apple
Intended status: Standards Track A. Quillaud Intended status: Standards Track A. Quillaud
Expires: September 11, 2017 Oracle Expires: September 14, 2017 Oracle
K. Murchison, Ed. K. Murchison, Ed.
CMU CMU
March 10, 2017 March 13, 2017
CalDAV Managed Attachments CalDAV Managed Attachments
draft-ietf-calext-caldav-attachments-01 draft-ietf-calext-caldav-attachments-02
Abstract Abstract
This specification defines an extension to the calendar access This specification defines an extension to the calendar access
protocol (CalDAV) to allow attachments associated with iCalendar protocol (CalDAV) to allow attachments associated with iCalendar data
data, to be stored and managed on the server. to be stored and managed on the server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Discovering Support for Managed Attachments . . . . . . . 4 3.2. Discovering Support for Managed Attachments . . . . . . . 4
3.3. POST Request for Managing Attachments . . . . . . . . . . 4 3.3. POST Request for Managing Attachments . . . . . . . . . . 4
3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6 3.4. Adding attachments . . . . . . . . . . . . . . . . . . . 6
3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9 3.5. Updating Attachments . . . . . . . . . . . . . . . . . . 9
3.6. Removing Attachments via POST . . . . . . . . . . . . . . 11 3.6. Removing Attachments via POST . . . . . . . . . . . . . . 11
3.7. Adding Existing Managed Attachments via PUT . . . . . . . 13 3.7. Adding Existing Managed Attachments via PUT . . . . . . . 13
3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 13 3.8. Updating Attachments via PUT . . . . . . . . . . . . . . 13
3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14 3.9. Removing Attachments via PUT . . . . . . . . . . . . . . 14
3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14 3.10. Retrieving Attachments . . . . . . . . . . . . . . . . . 14
3.11. Additional Considerations . . . . . . . . . . . . . . . . 14 3.11. Error Handling . . . . . . . . . . . . . . . . . . . . . 14
3.12. Additional Considerations . . . . . . . . . . . . . . . . 15
4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16 4. Modifications to iCalendar Syntax . . . . . . . . . . . . . . 16
4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16 4.1. SIZE Property Parameter . . . . . . . . . . . . . . . . . 16
4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 17 4.2. FILENAME Property Parameter . . . . . . . . . . . . . . . 17
4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17 4.3. MANAGED-ID Property Parameter . . . . . . . . . . . . . . 17
5. Additional Message Header Fields . . . . . . . . . . . . . . 18 5. Additional Message Header Fields . . . . . . . . . . . . . . 18
5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 18 5.1. Cal-Managed-ID Response Header Field . . . . . . . . . . 18
6. Additional WebDAV properties . . . . . . . . . . . . . . . . 18 6. Additional WebDAV properties . . . . . . . . . . . . . . . . 18
6.1. CALDAV:managed-attachments-server-URL property . . . . . 18 6.1. CALDAV:managed-attachments-server-URL property . . . . . 18
6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 19 6.2. CALDAV:max-attachment-size property . . . . . . . . . . . 19
6.3. CALDAV:max-attachments-per-resource property . . . . . . 20 6.3. CALDAV:max-attachments-per-resource property . . . . . . 20
skipping to change at page 2, line 46 skipping to change at page 2, line 47
9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 23 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 23
9.2. Message Header Field Registrations . . . . . . . . . . . 24 9.2. Message Header Field Registrations . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 26 publication) . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Example Involving Recurring Events . . . . . . . . . 28 Appendix B. Example Involving Recurring Events . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The iCalendar [RFC5545] data format is used to represent calendar The iCalendar [RFC5545] data format is used to represent calendar
data and is used with iTIP [RFC5546] to handle scheduling operations data and is used with iTIP [RFC5546] to handle scheduling operations
between calendar users. between calendar users.
[RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP
[RFC7230], for accessing calendar data stored on a server. [RFC7230], for accessing calendar data stored on a server.
skipping to change at page 13, line 35 skipping to change at page 13, line 35
>> 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.11.3). When this occurs, to the restrictions described in Section 3.12.2). When this occurs,
servers SHOULD NOT change either the "MANAGED-ID" parameter value or servers SHOULD NOT change either the "MANAGED-ID" parameter value or
the "ATTACH" property value for any managed attachments - this the "ATTACH" property value for any managed attachments - this
ensures that clients do not have to download the attachment data ensures that clients do not have to download the attachment data
again if they already have it cached, because it is used in another again if they already have it cached, because it is used in another
calendar resource. calendar resource.
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
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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. Additional Considerations 3.11. Error Handling
3.11.1. 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 the
calendar collection of the target calendar resource; calendar collection of the target calendar resource;
skipping to change at page 15, line 4 skipping to change at page 14, line 50
property parameter value in the iCalendar data targeted by the property parameter value in the iCalendar data targeted by the
request. request.
A POST request to add, modify, or delete a managed attachment results A POST request to add, modify, or delete a managed attachment results
in an implicit modification of the targeted calendar resource in an implicit modification of the targeted calendar resource
(equivalent of a PUT). As a consequence, clients should also be (equivalent of a PUT). As a consequence, clients should also be
prepared to handle preconditions associated with this implicit PUT. prepared to handle preconditions associated with this implicit PUT.
This includes (but is not limited to): This includes (but is not limited to):
(CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791]) (CALDAV:max-resource-size) (from Section 5.3.2.1 of [RFC4791])
(DAV:quota-not-exceeded) (from Section 6 of [RFC4331])
(DAV:quota-not-exceeded) (from Section 6 of [RFC4331])
(DAV:sufficient-disk-space) (from Section 6 of [RFC4331]) (DAV:sufficient-disk-space) (from Section 6 of [RFC4331])
A PUT request to add or modify and existing calendar object resource A PUT request to add or modify and existing calendar object resource
can make reference to an existing managed attachment. The following can make reference to an existing managed attachment. The following
new preconditions is defined: new preconditions is defined:
(CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property (CALDAV:valid-managed-id-parameter): a "MANAGED-ID" property
parameter value in the iCalendar data in the PUT request is not parameter value in the iCalendar data in the PUT request is not
valid (e.g., does not match any existing managed attachment). valid (e.g., does not match any existing managed attachment).
3.11.2. Quotas 3.12. Additional Considerations
3.12.1. Quotas
The WebDAV Quotas [RFC4331] specification defines two live WebDAV The WebDAV Quotas [RFC4331] specification defines two live WebDAV
properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to properties (DAV:quota-available-bytes and DAV:quota-used-bytes) to
communicate storage quota information to clients. Server communicate storage quota information to clients. Server
implementations MAY choose to include managed attachments sizes when implementations MAY choose to include managed attachments sizes when
calculating the amount of storage used by a particular resource. calculating the amount of storage used by a particular resource.
3.11.3. Access Control 3.12.2. Access Control
Access to the managed attachments store in a calendar object resource Access to the managed attachments store in a calendar object resource
SHOULD be restricted to only those calendar users who have access to SHOULD be restricted to only those calendar users who have access to
that calendar object either directly, or indirectly (via being an that calendar object either directly, or indirectly (via being an
attendee who would receive a scheduling message). 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 re-using a
managed attachment (based on its managed-id value), unless that user managed attachment (based on its managed-id value), unless that user
is the one who originally created the managed attachment. is the one who originally created the managed attachment.
3.11.4. Redirects 3.12.3. Redirects
For POST requests that add or update attachment data, the server MAY For POST requests that add or update attachment data, the server MAY
issue an HTTP redirect to require the client to re-issue the POST issue an HTTP redirect to require the client to re-issue the POST
request using a different request-URI. As a result, it is always request using a different request-URI. As a result, it is always
best for clients to use the "100-continue" expectation defined in best for clients to use the "100-continue" expectation defined in
Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a Section 5.1.1 of [RFC7231]. Using this mechanism ensures that, if a
redirect does occur, the client does not needlessly send the redirect does occur, the client does not needlessly send the
attachment data. attachment data.
3.11.5. Automatic Clean-up by servers 3.12.4. Processing Time
Clients can expect servers to take a while to respond to POST
requests that include large attachment bodies. Servers SHOULD use
the "102 (Processing)" interim response defined in Section 10.1 of
[RFC2518] to keep the client connection alive if the POST request
will take significant time to complete.
3.12.5. Automatic Clean-up by servers
Servers MAY automatically remove attachment data, for example to Servers MAY automatically remove attachment data, for example to
regain the storage taken by unused attachments, or as the result of a regain the storage taken by unused attachments, or as the result of a
virus scanning. When doing so they SHOULD NOT modify calendar data virus scanning. When doing so they SHOULD NOT modify calendar data
referencing those attachments. Instead they SHOULD respond with "410 referencing those attachments. Instead they SHOULD respond with "410
(Gone)" to any request on the removed attachment URI. (Gone)" to any request on the removed attachment URI.
3.11.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.11.7. Other Client Considerations 3.12.7. Migrating Calendar Data
Clients can expect servers to take a while to respond to POST
requests that include large attachment bodies. Servers SHOULD use
the "102 (Processing)" interim response defined in Section 10.1 of
[RFC2518] to keep the client connection alive if the final response
will take some time.
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
skipping to change at page 20, line 12 skipping to change at page 20, line 15
allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
request. 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.1) 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.
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:
skipping to change at page 21, line 6 skipping to change at page 21, line 9
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. Non-managed 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.1) 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:
skipping to change at page 23, line 31 skipping to change at page 23, line 33
described above. This implementation is proprietary and available described above. This implementation is proprietary and available
for purchase from the vendor. for purchase from the vendor.
8. Security Considerations 8. Security Considerations
Malicious content could be introduced into the Calendar Server by way Malicious content could be introduced into the Calendar Server by way
of a managed attachment, and propagated to many end users via of a managed attachment, and propagated to many end users via
scheduling. Servers SHOULD check managed attachments for malicious scheduling. Servers SHOULD check managed attachments for malicious
or inappropriate content. Upon detecting of such content, servers or inappropriate content. Upon detecting of such content, servers
SHOULD remove the attachment, following the rules described in SHOULD remove the attachment, following the rules described in
Section 3.11.5. Section 3.12.5.
9. IANA Considerations 9. IANA Considerations
9.1. Parameter Registrations 9.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 registry defined in Section 8.2.3 of
[RFC5545]: [RFC5545]:
+--------------------+---------+----------------------+ +--------------------+---------+----------------------+
skipping to change at page 26, line 35 skipping to change at page 26, line 35
[8] http://calendarserver.org/wiki/CalDAVTester [8] http://calendarserver.org/wiki/CalDAVTester
[9] http://www.apache.org/licenses/LICENSE-2.0.html [9] http://www.apache.org/licenses/LICENSE-2.0.html
[10] http://www.2doapp.com/ [10] http://www.2doapp.com/
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) publication)
Changes in calext-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: Changes in calext-01:
1. Changed all instances of "header" to "header field". 1. Changed all instances of "header" to "header field".
2. Reworked wording of Prefer header field handling. 2. Reworked wording of Prefer header field handling.
3. Switched to recommending 102 (Processing) interim response to 3. Switched to recommending 102 (Processing) interim response to
keep the client connection alive. keep the client connection alive.
4. Fixed description of Cal-Managed-ID response header field to 4. Fixed description of Cal-Managed-ID response header field to
 End of changes. 21 change blocks. 
28 lines changed or deleted 38 lines changed or added

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