Apple Inc.

1 Infinite Loop Cupertino CA 95014 USA cyrus@daboo.name http://www.apple.com/

Sun Microsystems

180, Avenue de l'Europe Saint Ismier cedex 38334 France arnaud.quillaud@sun.com http://www.sun.com/

Applications This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at .

WebDAV defines the concept of 'collections' which are hierarchical groupings of WebDAV resources on an HTTP server. Collections can be of arbitrary size and depth (i.e., collections within collections). WebDAV clients that cache resource content need a way to synchronize that data with the server (i.e., detect what has changed and update their cache). This can currently be done using a WebDAV PROPFIND request on a collection to list all members of a collection along with their DAV:getetag property values, which allows the client to determine which resources were changed, added or deleted. However, this does not scale well to large collections as the XML response to the PROPFIND request will grow with the collection size. This specification defines a new WebDAV report that results in the server returning to the client only information about those resources which have changed, are new or were deleted since a previous execution of the report on the collection. Additionally, a new property is added to collection resources that is used to convey a "synchronization token" that is guaranteed to change when resources within the collection have changed.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . This document uses XML DTD fragments (, Section 3.2) as a purely notational convention. WebDAV request and response bodies cannot be validated by a DTD due to the specific extensibility rules defined in Section 17 of [RFC4918] and due to the fact that all XML elements defined by this specification use the XML namespace name "DAV:". In particular: element names use the "DAV:" namespace, element ordering is irrelevant unless explicitly stated, extension elements (elements not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise, extension attributes (attributes not already defined as valid for this element) may be added anywhere, except when explicitly stated otherwise. When an XML element type in the "DAV:" namespace is referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type. This document inherits, and sometimes extends, DTD productions from Section 14 of .

We are extending the multistatus response element in a significant way. The DAV:sync-response differs from a regular DAV:response because, in the case of a created or modified resource, it contains both a DAV:status (201 for created, 200 for modified) and a DAV:propstat. The DAV:response on the other hand contains either a DAV:status or a DAV:propstat but not both. Shall we define a DAV:multisyncstatus response element instead of overloading DAV:multistatus ? Do clients really need to be notified that a resource was created versus modified ? They should be able to figure that out by looking at the state of their current cache. If this information is not necessary, the response would not need to contain a DAV:status along with the DAV:propstat. This would allow the use of a regular multistatus (simply extended with a sync-token element).

One way to synchronize data between two entities is to use some form of synchronization token. The token defines the state of the data being synchronized at a particular point in time. It can then be used to determine what has changed since one point in time and another. This specification defines a new WebDAV report that is used to enable client-server collection synchronization based on such a token. In order to synchronize the contents of a collection between a server and client, the server provides the client with a synchronization token each time the synchronization report is executed. That token represents the state of the data being synchronized at that point in time. The client can then present that same token back to the server at some later time and the server will return only those items that are new, have changed or were deleted since that token was generated. The server also returns a new token representing the new state at the time the report was run. Typically the first time a client connects to the server it will need to be informed of the entire state of the collection (i.e., a full list of all resources that are currently contained in the collection). That is done by the client sending an empty token value to the server. This indicates to the server that a full listing is required. As an alternative, the client may choose to do its first synchronization using some other mechanism on the collection (e.g. some other form of batch resource information retrieval such as PROPFIND, SEARCH , or specialized REPORTs such as those defined in CalDAV and CardDAV ) and ask for the DAV:sync-token property to be returned. This property (defined in ) contains the same token that can be used later on to issue a DAV:sync-collection report. In some cases a server may only wish to maintain a limited amount of history about changes to a collection. In that situation it will return an error to the client when the client presents a token that is "out of date". At that point the client has to fall back to synchronizing the entire collection by re-running the report request using an empty token value. ACL changes may also cause a token to become invalid.

This specification defines the DAV:sync-collection report. If this report is implemented by a WebDAV server, then the server MUST list the report in the "DAV:supported-report-set" property on any collection supporting synchronization. To implement the behavior for this report a server needs to keep track of changes to any resources in a collection. This includes noting the addition of new resources, changes to existing resources and removal of resources (where "removal" could be the result of a DELETE or MOVE WebDAV request). Only internal members of the collection (as defined in ) are to be considered. The server will track each change and provide a synchronization "token" to the client that describes the state of the server at a specific point in time. This "token" is returned as part of the response to the "sync-collection" report. Clients include the last token they got from the server in the next "sync-collection" report that they execute and the server provides the changes from the previous state, represented by the token, to the current state, represented by the new token returned. The synchronization token itself is an "opaque" string - i.e., the actual string data has no specific meaning or syntax. A simple implementation of such a token would be a numeric counter that counts each change as it occurs and relates that change to the specific object that changed. Marshalling: The request URI MUST be a collection. The request body MUST be a DAV:sync-collection XML element (see ), which MUST contain one DAV:sync-token XML element, and optionally a DAV:propstat XML element. The request MUST include a Depth header with a value of "1". The response body for a successful request MUST be a DAV:multistatus XML element, which MUST contain one DAV:sync-token element in addition to any DAV:sync-response elements. The response body for a successful DAV:sync-collection report request MUST contain a DAV:sync-response element for each resource that was created, has changed or been deleted since the last synchronization operation as specified by the DAV:sync-token provided in the request. A given resource MUST appear only once in the response. The DAV:status element in each DAV:sync-response element is used to indicate how the resource may have changed: A status code of '201 Created' is used to indicate resources that are new. A status code of '200 OK' is used to indicate resources that have changed. A status code of '404 Not Found' is used to indicate resources that have been removed. The conditions under which each type of change may occur is further described in . Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST map to a valid token previously returned by the server. A token may become invalid as the result of being "out of date" (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, ACL changes, etc...). Postconditions: None.

Three types of resource state changes can be returned by the DAV:sync-collection report (new, modified, removed). This section further defines under which condition each of them shall be used. It also clarifies the case where a resource may have undergone multiple changes in between two synchronizations.

A resource MUST be reported as new if it has been mapped directly under the target collection since the request sync token was generated. This includes resources that have been mapped as the result of a COPY, MOVE or BIND () operation. This also includes collection resources that have been created. In the case where a mapping between a resource and the target collection was removed, then a new mapping with the same URI created, the new resource MUST be reported as new, while the old resource MUST NOT be reported as removed. For example, if a resource was deleted, then recreated using the same URI, it should be reported as a new resource only. A resource MAY be reported as new if the user issuing the request was granted access to this resource, due to access control changes.

A resource MUST be reported as modified if it is not reported as new and if its entity tag value (defined in ) has changed since the request sync token was generated. In other words, the new resource change indicator takes precedence over the modified resource change indicator. Collection resources MUST NOT be returned as modified. Instead clients are expected to synchronize changes in child collection resources on an individual basis.

A resource MUST be reported as removed if its mapping under the target collection has been removed since the request sync token was generated, and it has not been re-mapped since it was removed. This includes resources that have been unmapped as the result of a MOVE or UNBIND () operation. This also includes collection resources that have been removed. If a resource was created (and possibly modified), then removed in between two synchronizations, it MUST NOT be reported as new, modified or removed. A resource MAY be reported as removed if the user issuing the request has no longer access to this resource, due to access control changes.

In this example, the client is making its first synchronization request to the server, so the DAV:sync-token element in the request is empty. It also asks for the DAV:getetag property. The server responds with the items currently in the targeted collection (indicating that they are 'new' via the '201 Created' status code). The current synchronization token is also returned.

>> Request << REPORT /home/cyrusdaboo/ HTTP/1.1 Host: webdav.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:sync-collection xmlns:D="DAV:"> <D:sync-token/> <D:prop> <D:getetag/> </D:prop> </D:sync-collection>

>> Response << HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href> <D:status>HTTP/1.1 201 Created</D:status> <D:propstat> <D:prop> <D:getetag>"00001-abcd1"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:sync-response> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href> <D:status>HTTP/1.1 201 Created</D:status> <D:propstat> <D:prop> <D:getetag>"00002-abcd1"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:sync-response> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/calendar.ics</D:href> <D:status>HTTP/1.1 201 Created</D:status> <D:propstat> <D:prop> <D:getetag>"00003-abcd1"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:sync-response> <D:sync-token>1234</D:sync-token> </D:multistatus>

In this example, the client is making a synchronization request to the server and is using the DAV:sync-token element returned from the last report it ran on this collection. The server responds listing the items that have been added, changed or removed. The (new) current synchronization token is also returned.

>> Request << REPORT /home/cyrusdaboo/ HTTP/1.1 Host: webdav.example.com Depth: 1 Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:sync-collection xmlns:D="DAV:"> <D:sync-token>1234</D:sync-token> <D:prop> <D:getetag/> </D:prop> </D:sync-collection>

>> Response << HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:"> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/file.xml</D:href> <D:status>HTTP/1.1 201 Created</D:status> <D:propstat> <D:prop> <D:getetag>"00004-abcd1"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:sync-response> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href> <D:status>HTTP/1.1 200 OK</D:status> <D:propstat> <D:prop> <D:getetag>"00002-abcd2"</D:getetag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:sync-response> <D:sync-response> <D:href >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href> <D:status>HTTP/1.1 404 Not Found</D:status> </D:sync-response> <D:sync-token>1238</D:sync-token> </D:multistatus>

sync-token DAV: Contains the value of the synchronization token as it would be returned by a DAV:sync-collection report. Any text. MUST be protected because this value is created and controlled by the server. This property value is dependent on the final state of the destination resource, not the value of the property on the source resource. The DAV:sync-token property MUST be defined on all resources that support the DAV:sync-collection report. It contains the value of the synchronization token as it would be returned by a DAV:sync-collection report on that resource at the same point in time. It SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in ).

<!ELEMENT sync-token #PCDATA>

sync-collection DAV: WebDAV report used to synchronize data between client and server. See .

<!ELEMENT sync-collection (sync-token, DAV:prop?)>

sync-token DAV: The synchronization token provided by the server and returned by the client. See .

<!ELEMENT sync-token CDATA>

multistatus DAV: Extends the DAV:multistatus element to include synchronization details. See .

<!ELEMENT multistatus ((DAV:response*, DAV:responsedescription?) | (DAV:sync-response*, DAV:sync-token, DAV:responsedescription?))>

sync-response DAV: Contains the synchronization results returned by the server. See .

<!ELEMENT sync-response (DAV:href, DAV:status, DAV:propstat?)>

This extension does not introduce any new security concerns than those already described in HTTP and WebDAV.

This document does not require any actions on the part of IANA.

The following individuals contributed their ideas and support for writing this specification: Bernard Desruisseaux, Mike Douglass, Ciny Joy and Julian Reschke.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 . Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).</t><t> RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS TRACK] Apple Inc.

1 Infinite Loop Cupertino CA 95014 USA cyrus@daboo.name http://www.apple.com/

Oracle Corporation

600 Blvd. de Maisonneuve West Suite 1900 Montreal QC H3A 3J2 CANADA bernard.desruisseaux@oracle.com http://www.oracle.com/

CommerceNet

169 University Ave. Palo Alto CA 94301 USA ldusseault@commerce.net http://commerce.net/

Applications calsched calsch caldav calendar calendaring scheduling webdav iCal iCalendar iTIP text/calendar HTTP This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS TRACK] This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format.

Changes in -02: Added definition of sync-token WebDAV property. Added references to SEARCH, CalDAV, CardDAV as alternative ways to first synchronize a collection. Added section defining under which condition each state change (new, modified, removed) should be reported. Added reference to BIND. Incorporated feedback from Julian Reschke and Ciny Joy. More details on the use of the DAV:valid-sync-token precondition. Changes in -01: Updated to 4918 reference. Fixed examples to properly include DAV:status in DAV:propstat Switch to using XML conventions text from RFC5323.