Revision: 1510 http://trac.macosforge.org/projects/calendarserver/changeset/1510 Author: cdaboo@apple.com Date: 2007-05-03 08:55:48 -0700 (Thu, 03 May 2007) Log Message: ----------- Various specifications for extensions used or being proposed for use with the server. Added Paths: ----------- CalendarServer/trunk/doc/Extensions/ CalendarServer/trunk/doc/Extensions/caldav-ctag-02.txt CalendarServer/trunk/doc/Extensions/caldav-proxy-02.txt CalendarServer/trunk/doc/Extensions/caldav-resync-02.txt CalendarServer/trunk/doc/Extensions/icalendar-maskuids-02.txt Added: CalendarServer/trunk/doc/Extensions/caldav-ctag-02.txt =================================================================== --- CalendarServer/trunk/doc/Extensions/caldav-ctag-02.txt (rev 0) +++ CalendarServer/trunk/doc/Extensions/caldav-ctag-02.txt 2007-05-03 15:55:48 UTC (rev 1510) @@ -0,0 +1,336 @@ + + + +Calendar Server Extension C. Daboo + Apple + May 3, 2007 + + + Calendar Collection Entity Tag (CTag) in CalDAV + caldav-ctag-02 + +Abstract + + This specification defines an extension to CalDAV that provides a + fast way for a client to determine whether the contents of a calendar + collection may have changed. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 3 + 4.1. getctag WebDAV Property . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5 + Appendix B. Change History . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 1] + + CalDAV Proxy May 2007 + + +1. Introduction + + In CalDAV [RFC4791] calendar data is stored in calendar collection + resources. Clients need to "poll" calendar collections in order to + find out what has changed since the last time they examined it. + Currently that involves having to do a PROPFIND Depth:1 HTTP request, + or a CALDAV:calendar-query REPORT request. When a calendar + collection contains a large number of calendar resources those + operations become expensive on the server. + + Calendar users often configure their clients to poll at short time + intervals. So polling traffic to the server will be high, even + though the frequency at which changes actually occur to a calendar is + typically low. + + To improve on performance, this specification defines a new "calendar + collection entity tag" (CTag) WebDAV property that is defined on + calendar collections. When the calendar collection changes, the CTag + value changes. Thus a client can cache the CTag at some point in + time, then poll the collection only (i.e. PROPFIND Depth:0 HTTP + requests) and determine if a change has happened based on the + returned CTag value. If there is a change, it can then fall back to + doing the full (Depth:1) poll of the collection to actually determine + which resources in the collection changed. + + This extension also defines CTag's on CalDAV scheduling + [I-D.desruisseaux-caldav-sched] Inbox and Outbox collections. + + +2. Conventions Used in This 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 [RFC2119]. + + When XML element types in the namespaces "DAV:" and + "urn:ietf:params:xml:ns:caldav" are referenced in this document + outside of the context of an XML fragment, the string "DAV:" and + "CALDAV:" will be prefixed to the element type names respectively. + + The namespace "http://calendarserver.org/ns/" is used for XML + elements defined in this specification. When XML element types in + this namespace are referenced in this document outside of the context + of an XML fragment, the string "CS:" will be prefixed to the element + type names respectively. + + + + + + +Daboo [Page 2] + + CalDAV Proxy May 2007 + + +3. Overview + +3.1. Server + + For each calendar or scheduling Inbox or Outbox collection on the + server, a new CS:getctag WebDAV property is present. + + The property value is an "opaque" token whose value is guaranteed to + be unique over the lifetime of any calendar or scheduling Inbox or + Outbox collection at a specific URI. + + Whenever a calendar resource is added to, modified or deleted from + the calendar collection, the value of the CS:getctag property MUST + change. Typically this change will occur when the DAV:getetag + property on a child resource changes due to some protocol action. It + could be the result of a change to the body or properties of the + resource. + +3.2. Client + + The client starts off with an empty string as the initial value for + the cached CTag of a calendar or scheduling Inbox or Outbox + collection that it intends to synchronize with. + + When polling a calendar or scheduling Inbox or Outbox collection, the + client issues a PROPFIND Depth:0 HTTP request, asking for the CS: + getctag property to be returned. + + If the returned value of CS:getctag property matches the one + currently cached for the calendar or scheduling Inbox or Outbox + collection, then the collection contents have not changed and no + further action is required until the next poll. + + If the returned value of CS:getctag property does not match the one + found previously, then the contents of the calendar or scheduling + Inbox or Outbox collection have changed. At that point the client + should re-issue the PROPFIND Depth:1 request to get the collection + changes in detail and the CS:getctag property value corresponding to + the new state. The new CSgetctag property value should replace the + one currently cached for that calendar or scheduling Inbox or Outbox + collection. + + +4. New features in CalDAV + + + + + + + +Daboo [Page 3] + + CalDAV Proxy May 2007 + + +4.1. getctag WebDAV Property + + Name: getctag + + Namespace: http://calendarserver.org/ns/ + + Purpose: Specifies a "synchronization" token used to indicate when + the contents of a calendar or scheduling Inbox or Outbox + collection have changed. + + Conformance: This property MUST be defined on a calendar or + scheduling Inbox or Outbox collection resource. It MUST be + protected and SHOULD be returned by a PROPFIND DAV:allprop request + (as defined in Section 12.14.1 of [RFC2518]). + + Description: The CS:getctag property allows clients to quickly + determine if the contents of a calendar or scheduling Inbox or + Outbox collection have changed since the last time a + "synchronization" operation was done. The CS:getctag property + value MUST change each time the contents of the calendar or + scheduling Inbox or Outbox collection change, and each change MUST + result in a value that is different from any other used with that + collection URI. + + Definition: + + <!ELEMENT getctag #PCDATA> + + Example: + + <T:getctag xmlns:T="http://calendarserver.org/ns/" + >ABCD-GUID-IN-THIS-COLLECTION-20070228T122324010340</T:getctag> + + +5. Security Considerations + + The CS:getctag property value changes whenever any resource in the + collection or scheduling Inbox or Outbox changes. Thus a change to a + resource that a user does not have read access to will result in a + change in the CTag and the user will know that a change occurred. + However, that user will not able to get additional details about + exactly what changed as WebDAV ACLs [RFC3744] will prevent that. So + this does expose the fact that there are potentially "hidden" + resources in a calendar collection, but it does not expose any + details about them. + + + + + + +Daboo [Page 4] + + CalDAV Proxy May 2007 + + +6. IANA Considerations + + This document does not require any actions on the part of IANA. + + +7. Normative References + + [I-D.desruisseaux-caldav-sched] + Desruisseaux, B., "Scheduling Extensions to CalDAV", + draft-desruisseaux-caldav-sched-03 (work in progress), + January 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, February 1999. + + [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web + Distributed Authoring and Versioning (WebDAV) Access + Control Protocol", RFC 3744, May 2004. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + March 2007. + + +Appendix A. Acknowledgments + + This specification is the result of discussions between the Apple + calendar server and client teams. + + +Appendix B. Change History + + Changes from -01: + + 1. Updated to RFC4791 reference. + + 2. Added text indicating that ctag applies to schedule Inbox and + Outbox as well. + + Changes from -00: + + 1. Relaxed requirement so that any type of change to a child + resource can trigger a CTag change (similar behavior to ETag). + + + + +Daboo [Page 5] + + CalDAV Proxy May 2007 + + +Author's Address + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + Email: cyrus@daboo.name + URI: http://www.apple.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 6] + Added: CalendarServer/trunk/doc/Extensions/caldav-proxy-02.txt =================================================================== --- CalendarServer/trunk/doc/Extensions/caldav-proxy-02.txt (rev 0) +++ CalendarServer/trunk/doc/Extensions/caldav-proxy-02.txt 2007-05-03 15:55:48 UTC (rev 1510) @@ -0,0 +1,560 @@ + + + +Calendar Server Extension C. Daboo + Apple Computer + May 3, 2007 + + + Calendar User Proxy Functionality in CalDAV + caldav-cu-proxy-02 + +Abstract + + This specification defines an extension to CalDAV that makes it easy + for clients to setup and manage calendar user proxies, using the + WebDAV Access Control List extension as a basis. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 4 + 5.1. Proxy Principal Resource . . . . . . . . . . . . . . . . . 4 + 5.2. Privilege Provisioning . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9 + Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + +Daboo [Page 1] + + CalDAV Proxy May 2007 + + +1. Introduction + + CalDAV [RFC4791] provides a way for calendar users to store calendar + data and exchange this data via scheduling operations. Based on the + WebDAV protocol [RFC2518], it also includes the ability to manage + access to calendar data via the WebDAV ACL extension [RFC3744]. + + It is often common for a calendar user to delegate some form of + responsibility for their calendar and schedules to another calendar + user (e.g., a boss allows an assistant to check a calendar or to send + and accept scheduling invites on his behalf). The user handling the + calendar data on behalf of someone else is often referred to as a + "calendar user proxy". + + Whilst CalDAV does have fine-grained access control features that can + be used to setup complex sharing and management of calendars, often + the proxy behavior required is an "all-or-nothing" approach - i.e. + the proxy has access to all the calendars or to no calendars (in + which case they are of course not a proxy). So a simple way to + manage access to an entire set of calendars and scheduling ability + would be handy. + + In addition, calendar user agents will often want to display to a + user who has proxy access to their calendars, or to whom they are + acting as a proxy. Again, CalDAV's access control discovery and + report features can be used to do that, but with fine-grained control + that exists, it can be hard to tell who is a "real" proxy as opposed + to someone just granted rights to some subset of calendars. Again, a + simple way to discover proxy information would be handy. + + +2. Conventions Used in This 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 [RFC2119]. + + When XML element types in the namespace "DAV:" are referenced in this + document outside of the context of an XML fragment, the string "DAV:" + will be prefixed to the element type names. + + When XML element types in the namespaces "DAV:" and + "urn:ietf:params:xml:ns:caldav" are referenced in this document + outside of the context of an XML fragment, the string "DAV:" and + "CALDAV:" will be prefixed to the element type names respectively. + + The namespace "http://calendarserver.org/ns/" is used for XML + elements defined in this specification. When XML element types in + + + +Daboo [Page 2] + + CalDAV Proxy May 2007 + + + this namespace are referenced in this document outside of the context + of an XML fragment, the string "CS:" will be prefixed to the element + type names respectively. + + +3. Overview + +3.1. Server + + For each calendar user principal on the server, the server will + generate two group principals - "proxy groups". One is used to hold + the list of principals who have read-only proxy access to the main + principal's calendars, the other holds the list of principals who + have read-write and scheduling proxy access. NB these new group + principals would have no equivalent in Open Directory. + + Privileges on each "proxy group" principal will be set so that the + "owner" has the ability to change property values. + + The "proxy group" principals will be child resources of the user + principal resource with specific resource types and thus are easy to + discover. As a result the user principal resources will also be + collection resources. + + When provisioning the calendar user home collection, the server will: + + a. Add an ACE to the calendar home collection giving the read-only + "proxy group" inheritable read access. + + b. Add an ACE to the calendar home collection giving the read-write + "proxy group" inheritable read-write access. + + c. Add an ACE to each of the calendar Inbox and Outbox collections + giving the CALDAV:schedule privilege + [I-D.desruisseaux-caldav-sched] to the read-write "proxy group". + +3.2. Client + + A client can see who the proxies are for the current principal by + examining the principal resource for the two "proxy group" properties + and then looking at the DAV:group-member-set property of each. + + The client can edit the list of proxies for the current principal by + editing the DAV:group-member-set property on the relevant "proxy + group" principal resource. + + The client can find out who the current principal is a proxy for by + running a DAV:principal-match REPORT on the principal collection. + + + +Daboo [Page 3] + + CalDAV Proxy May 2007 + + + Alternatively, the client can find out who the current principal is a + proxy for by examining the DAV:group-membership property on the + current principal resource looking for membership in other users' + "proxy groups". + + +4. Open Issues + + 1. Do we want to separate read-write access to calendars vs the + ability to schedule as a proxy? + + 2. We may want to restrict changing properties on the proxy group + collections to just the DAV:group-member-set property? + + 3. There is no way for a proxy to be able to manage the list of + proxies. We could allow the main calendar user DAV:write-acl on + their "proxy group" principals, in which case they could grant + others the right to modify the group membership. + + 4. Should the "proxy group" principals also be collections given + that the regular principal resources will be? + + +5. New features in CalDAV + +5.1. Proxy Principal Resource + + Each "regular" principal resource that needs to allow calendar user + proxy support MUST be a collection resource. i.e. in addition to + including the DAV:principal XML element in the DAV:resourcetype + property on the resource, it MUST also include the DAV:collection XML + element. + + Each "regular" principal resource MUST contain two child resources + with names "calendar-proxy-read" and "calendar-proxy-write" (note + that these are only suggested names - the server could choose any + unique name for these). These resources are themselves principal + resources that are groups contain the list of principals for calendar + users who can act as a read-only or read-write proxy respectively. + + The server MUST include the CS:calendar-proxy-read or CS:calendar- + proxy-write XML elements in the DAV:resourcetype property of the + child resources, respectively. This allows clients to discover the + "proxy group" principals by using a PROPFIND, Depth:1 request on the + current user's principal resource and requesting the DAV:resourcetype + property be returned. The element type declarations are: + + + + + +Daboo [Page 4] + + CalDAV Proxy May 2007 + + + <!ELEMENT calendar-proxy-read EMPTY> + + <!ELEMENT calendar-proxy-write EMPTY> + + The server MUST allow the "parent" principal to change the DAV:group- + member-set property on each of the "child" "proxy group" principal + resources. When a principal is listed as a member of the "child" + resource, the server MUST include the "child" resource URI in the + DAV:group-membership property on the included principal resource. + Note that this is just "normal" behavior for a group principal. + + An example principal resource layout might be: + + + / + + principals/ + + users/ + + cyrus/ + calendar-proxy-read + calendar-proxy-write + + red/ + calendar-proxy-read + calendar-proxy-write + + wilfredo/ + calendar-proxy-read + calendar-proxy-write + + If the principal "cyrus" wishes to have the principal "red" act as a + calendar user proxy on his behalf and have the ability to change + items on his calendar or schedule meetings on his behalf, then he + would add the principal resource URI for "red" to the DAV:group- + member-set property of the principal resource /principals/users/ + cyrus/calendar-proxy-write, giving: + + <DAV:group-member-set> + <DAV:href>/principals/users/red/</DAV:href> + </DAV:group-member-set> + + The DAV:group-membership property on the resource /principals/users/ + red/ would be: + + <DAV:group-membership> + <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href> + </DAV:group-membership> + + If the principal "red" was also a read-only proxy for the principal + "wilfredo", then the DA:group-membership property on the resource + /principals/users/red/ would be: + + + + +Daboo [Page 5] + + CalDAV Proxy May 2007 + + + <DAV:group-membership> + <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href> + <DAV:href>/principals/users/wilfredo/calendar-proxy-read</DAV:href> + </DAV:group-membership> + + Thus a client can discover to which principals a particular principal + is acting as a calendar user proxy for by examining the DAV:group- + membership property. + + An alternative to discovering which principals a user can proxy as is + to use the WebDAV ACL principal-match report, targeted at the + principal collections available on the server. + + Example: + + >> Request << + + REPORT /principals/ HTTP/1.1 + Host: cal.example.com + Depth: 0 + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + Authorization: Digest username="red", + realm="cal.example.com", nonce="...", + uri="/principals/", response="...", opaque="..." + + <?xml version="1.0" encoding="utf-8" ?> + <D:principal-match xmlns:D="DAV:"> + <D:self/> + <D:prop> + <D:resourcetype/> + </D:prop> + </D:principal-match> + + + + + + + + + + + + + + + + + + +Daboo [Page 6] + + CalDAV Proxy May 2007 + + + >> Response << + + HTTP/1.1 207 Multi-Status + Date: Fri, 10 Nov 2006 09:32:12 GMT + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:multistatus xmlns:D="DAV:" + xmlns:A="http://calendarserver.org/ns/"> + <D:response> + <D:href>/principals/users/red/</D:href> + <D:propstat> + <D:prop> + <D:resourcetype> + <D:principal/> + <D:collection/> + </D:resourcetype> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>/principals/users/cyrus/calendar-proxy-write</D:href> + <D:propstat> + <D:prop> + <D:resourcetype> + <D:principal/> + <A:calendar-proxy-write/> + </D:resourcetype> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>/principals/users/wilfredo/calendar-proxy-read</D:href> + <D:propstat> + <D:prop> + <D:resourcetype> + <D:principal/> + <A:calendar-proxy-read/> + </D:resourcetype> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + + + + +Daboo [Page 7] + + CalDAV Proxy May 2007 + + +5.2. Privilege Provisioning + + In order for a calendar user proxy to be able to access the calendars + of the user they are proxying for the server MUST ensure that the + privileges on the relevant calendars are setup accordingly: + + The DAV:read privilege MUST be granted for read-only and read- + write calendar user proxy principals + + The DAV:write privilege MUST be granted for read-write calendar + user proxy principals. + + Additionally, the CalDAV scheduling Inbox and Outbox calendar + collections for the user allowing proxy access, MUST have the CALDAV: + schedule privilege [I-D.desruisseaux-caldav-sched] granted for read- + write calendar user proxy principals. + + Note that with a suitable repository layout, a server may be able to + grant the appropriate privileges on a parent collection and ensure + that all the contained collections and resources inherit that. For + example, given the following repository layout: + + + / + + calendars/ + + users/ + + cyrus/ + inbox + outbox + home + work + + red/ + inbox + outbox + work + soccer + + wilfredo/ + inbox + outbox + home + work + flying + + In order for the principal "red" to act as a read-write proxy for the + principal "cyrus", the following WebDAV ACE will need to be granted + on the resource /calendars/users/cyrus/ and all children of that + resource: + + + + + +Daboo [Page 8] + + CalDAV Proxy May 2007 + + + <DAV:ace> + <DAV:principal> + <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href> + </DAV:principal> + <DAV:privileges> + <DAV:grant><DAV:read/><DAV:write/></DAV:grant> + </DAV:privileges> + </DAV:ace> + + +6. Security Considerations + + TBD + + +7. IANA Considerations + + This document does not require any actions on the part of IANA. + + +8. Normative References + + [I-D.desruisseaux-caldav-sched] + Desruisseaux, B., "Scheduling Extensions to CalDAV", + draft-desruisseaux-caldav-sched-03 (work in progress), + January 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, February 1999. + + [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web + Distributed Authoring and Versioning (WebDAV) Access + Control Protocol", RFC 3744, May 2004. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + March 2007. + + +Appendix A. Acknowledgments + + This specification is the result of discussions between the Apple + calendar server and client teams. + + + + +Daboo [Page 9] + + CalDAV Proxy May 2007 + + +Appendix B. Change History + + Changes from -00: + + 1. Updated to RFC 4791 reference. + + Changes from -00: + + 1. Added more details on actual CalDAV protocol changes. + + 2. Changed namespace from http://apple.com/ns/calendarserver/ to + http://calendarserver.org/ns/. + + 3. Made "proxy group" principals child resources of their "owner" + principals. + + 4. The "proxy group" principals now have their own resourcetype. + + +Author's Address + + Cyrus Daboo + Apple Computer, Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + Email: cyrus@daboo.name + URI: http://www.apple.com/ + + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 10] + Added: CalendarServer/trunk/doc/Extensions/caldav-resync-02.txt =================================================================== --- CalendarServer/trunk/doc/Extensions/caldav-resync-02.txt (rev 0) +++ CalendarServer/trunk/doc/Extensions/caldav-resync-02.txt 2007-05-03 15:55:48 UTC (rev 1510) @@ -0,0 +1,616 @@ + + + +Calendar Server Extension C. Daboo + Apple + May 3, 2007 + + + CalDAV Fast Resynchronization + caldav-resync-02 + +Abstract + + This specification defines an extension to CalDAV that allows a + client to quickly determine differences between calendar data it has + cached and the current state of that data on the server. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 4 + 4.1. CS:calendar-resync REPORT . . . . . . . . . . . . . . . . 4 + 4.1.1. Example: Initial CALDAV:calendar-resync REPORT . . . . 6 + 4.1.2. Example: Successful CALDAV:calendar-resync REPORT . . 7 + 5. XML Element Definitions . . . . . . . . . . . . . . . . . . . 9 + 5.1. CS:calendar-resync XML Element . . . . . . . . . . . . . . 9 + 5.2. CS:resource XML Element . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 + Appendix B. Change History . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + + + + + + +Daboo [Page 1] + + CalDAV Resynchronization May 2007 + + +1. Introduction + + CalDAV [RFC4791] provides a way for calendar users to store calendar + data and exchange this data via scheduling operations. Due to the + stateless nature of the HTTP [RFC2616] and WebDAV [RFC2518] + protocols, on which CalDAV is built, there is no notification of + changes to server data that a client can utilize during a "session" + to keep its state synchronized with the server. In the absence of + this the client is forced to poll the server at regular intervals in + order to check for changes to calendar collections. + + Currently, re-synchronizing a calendar collection consists of three + steps. + + The first is to issue a PROPFIND request to retrieve the CS: + getctag [CTAG] property on a calendar collection. If the value of + that has changed since the last such poll, the client moves to the + second step. + + In the second step the client issues a PROPFIND (Depth:1) on a + calendar collection to fetch the DAV:href values and DAV:getetag + properties of all immediate child resources within that + collection. It then compares the results of that with the cached + DAV:href/DAV:getetag values it has to determine what has changed + on the server. For resources that are no longer on the server, it + will remove its local copy, for resources that are new or have + changed on the server, the client moves to the third step. + + In the third step the client fetches all the data for new and + changed resources. For this, it can use a single CALDAV:multiget + REPORT on a calendar collection to retrieve all the changed data + in one go. + + Thus a re-synchronizing, where at least one calendar object resource + has changed, involves three requests. The second PROPFIND (Depth:1) + can be expensive on large calendars in that a significant amount of + data is returned, when in fact the changes are small. + + To improve the performance of client synchronization, this + specification defines a new CalDAV CS:calendar-resync REPORT that + allows a client to request the server to return information about + changes to calendar object resources in a calendar collection only. + This can be accomplished in a single round trip. + + Note, that from a server load standpoint, it is still more efficient + if a client uses the CS:getctag property to first determine whether + any changes have taken place before using the CS:calendar-resync + REPORT to find any changes. This is particularly true for short + + + +Daboo [Page 2] + + CalDAV Resynchronization May 2007 + + + polling intervals. + + +2. Conventions Used in This 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 [RFC2119]. + + When XML element types in the namespaces "DAV:" and + "urn:ietf:params:xml:ns:caldav" are referenced in this document + outside of the context of an XML fragment, the string "DAV:" and + "CALDAV:" will be prefixed to the element type names respectively. + + The namespace "http://calendarserver.org/ns/" is used for XML + elements defined in this specification. When XML element types in + this namespace are referenced in this document outside of the context + of an XML fragment, the string "CS:" will be prefixed to the element + type names respectively. + + +3. Overview + + The first time a client "connects" to a server and examines a + calendar collection, it will download and cache the data for all + calendar object resources in that collection, if it wishes to + maintain a complete cache of all such resources. + + Subsequently, when the client wishes to check for changes it will + issue a CS:calendar-resync REPORT request to the server targeting the + calendar collection URI. In the report body it will include all DAV: + href/DAV:getetag value pairs it has stored for cached data. + + When the server receives the client report request, it will compare + the list of DAV:href/DAV:getetag pairs with the current list + accessible to the current user. + + The server will then return in a response information about only + those resources that are new, have changed, or have been deleted on + the server. Resources that are unchanged are not returned in the + response. + + The client can update its cache using the server results returned in + the response. + + + + + + + +Daboo [Page 3] + + CalDAV Resynchronization May 2007 + + +4. New features in CalDAV + + This section describes the changes to the base CalDAV access + [RFC4791] and scheduling [I-D.desruisseaux-caldav-sched] drafts. + +4.1. CS:calendar-resync REPORT + + The CALDAV:calendar-resync REPORT is used to retrieve calendar object + resources that are new, changed, deleted or had privileges changed. + This report is similar to the CALDAV:calendar-multiget REPORT (see + [RFC4791]), except that it takes a list of CS:resource elements, + instead of DAV:href elements, to determine which calendar object + resources to return. + + Marshalling: + + The request body MUST be a CALDAV:calendar-resync XML element (see + Section 5.1) + + The Request-URI MUST be a calendar collection resource (see + [RFC4791]), or a scheduling Inbox or Outbox collection (see + [I-D.desruisseaux-caldav-sched]). The DAV:href elements inside of + the CS:resource elements MUST all refer to calendar object + resources within the collection. As a result, the "Depth" header + MUST be ignored by the server and SHOULD NOT be sent by the + client. + + The response body for a successful request MUST be a DAV: + multistatus XML element. + + The response body for a successful CALDAV:calendar-resync REPORT + request MUST contain a DAV:response element for each calendar + object resource referenced by the provided set of DAV:href + elements inside of each CS:resource element. Calendar data is + being returned in the CALDAV:calendar-data element inside the DAV: + prop element. + + For each CS:resource element in the request, the server examines + the DAV:href and DAV:getetag element values, and uses the + following procedure to build the response: + + If the resource referenced by the DAV:href element is not an + immediate child of the collection targeted by the request-URI, + the server adds a DAV:response element with a DAV:status + element with the status set to "400 Bad Request". + + If the resource referenced by the DAV:href element does not + exist, the server adds a DAV:response element with a DAV:status + + + +Daboo [Page 4] + + CalDAV Resynchronization May 2007 + + + element with the status set to "404 Not Found". + + If the resource referenced by the DAV:href element is not + readable by the currently authenticated user, the server adds a + DAV:response element with a DAV:status element with the status + set to "403 Forbidden". + + If the resource referenced by the DAV:href element exists and + is readable, but the DAV:getetag value in the request does not + match the current DAV:getetag property value on the resource, + the server adds a DAV:response element with a DAV:status + element with the status set to "200 OK". The server also + includes in the DAV:response any properties requested by the + client in its request. + + If the resource referenced by the DAV:href element exists and + is readable, and the DAV:getetag value in the request matches + the current DAV:getetag property value on the resource, the + server does not add a DAV:response for that resource. + + For each resource in the calendar collection referenced by the + request-URI on the server that does not have a corresponding CS: + resource entry in the client's request, the server carries out the + following procedure to build the response: + + If the resource is not readable by the currently authenticated + user, the server ignores it. + + If the resource is readable, the server adds a DAV:response + element with a DAV:status element with the status set to "200 + OK". The server also includes in the DAV:response any + properties requested by the client in its request. + + Preconditions: + + (CALDAV:supported-calendar-data): The attributes "content-type" + and "version" of the CALDAV:calendar-data XML elements (see + [RFC4791]) specify a media type supported by the server for + calendar object resources. + + Postconditions: + + None. + + + + + + + + +Daboo [Page 5] + + CalDAV Resynchronization May 2007 + + +4.1.1. Example: Initial CALDAV:calendar-resync REPORT + + In this example, the client requests the server to synchronize a + calendar that it has not cached before. As a result the client + request does not include any CS:resource elements. The response from + the server indicates the presence of three resources in the calendar. + + >> Request << + + REPORT /cyrus/work/ HTTP/1.1 + Host: cal.example.com + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <C:calendar-resync xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav" + xmlns:CS="http://calendarserver.org/ns/"> + <D:prop> + <D:getetag/> + </D:prop> + </C:calendar-resync> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 6] + + CalDAV Resynchronization May 2007 + + + >> Response << + + HTTP/1.1 207 Multi-Status + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:multistatus xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg1.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"MTG1-0011"</D:getetag> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg2.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"MTG2-0021"</D:getetag> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg3.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"MTG3-0031"</D:getetag> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + +4.1.2. Example: Successful CALDAV:calendar-resync REPORT + + In this example, the client requests the server to synchronize the + calendar previously cached. The DAV:getetag property is requested + and returned as part of the response. Note that in this example, the + resource at http://cal.example.com/bernard/work/mtg1.ics no longer + exists, the resource at http://cal.example.com/cyrus/work/mtg2.ics + exists but has changed, the resource at + http://cal.example.com/cyrus/work/mtg3.ics exists and has not + + + +Daboo [Page 7] + + CalDAV Resynchronization May 2007 + + + changed, and a new resource at + http://cal.example.com/cyrus/work/mtg4.ics exists. + + >> Request << + + REPORT /cyrus/work/ HTTP/1.1 + Host: cal.example.com + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <C:calendar-resync xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav" + xmlns:CS="http://calendarserver.org/ns/"> + <D:prop> + <D:getetag/> + </D:prop> + <CS:resource> + <D:href>/cyrus/work/mtg1.ics</D:href> + <D:getetag>MTG1-0011</D:getetag> + </CS:resource> + <CS:resource> + <D:href>/cyrus/work/mtg2.ics</D:href> + <D:getetag>MTG2-0021</D:getetag> + </CS:resource> + <CS:resource> + <D:href>/cyrus/work/mtg3.ics</D:href> + <D:getetag>MTG3-0031</D:getetag> + </CS:resource> + </C:calendar-resync> + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 8] + + CalDAV Resynchronization May 2007 + + + >> Response << + + HTTP/1.1 207 Multi-Status + Date: Sat, 11 Nov 2006 09:32:12 GMT + Content-Type: application/xml; charset="utf-8" + Content-Length: xxxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:multistatus xmlns:D="DAV:" + xmlns:C="urn:ietf:params:xml:ns:caldav"> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg1.ics</D:href> + <D:status>HTTP/1.1 404 Not Found</D:status> + </D:response> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg2.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"MTG2-0022"</D:getetag> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>http://cal.example.com/cyrus/work/mtg4.ics</D:href> + <D:propstat> + <D:prop> + <D:getetag>"MTG4-0041"</D:getetag> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + + +5. XML Element Definitions + +5.1. CS:calendar-resync XML Element + + Name: calendar-resync + Namespace: http://calendarserver.org/ns/ + Purpose: Used as the root element in a REPORT request to find + changes to a calendar collection. + Description: See Section 4.1. + + + + + + + +Daboo [Page 9] + + CalDAV Resynchronization May 2007 + + + Definition: + + <!ELEMENT calendar-resync ((DAV:allprop | + DAV:propname | + DAV:prop)?, + resource*)> + +5.2. CS:resource XML Element + + Name: resource + Namespace: http://calendarserver.org/ns/ + Purpose: Used to hold DAV:href/DAV:getetag pairs to indicate to a + server what data a client has cached. + Description: See Section 4.1. + Definition: + + <!ELEMENT resource (href, getetag)> + + +6. Security Considerations + + When determining changes to the set of resources the client has + cached, the server MUST take into consideration WebDAV ACLs on the + resources it has stored for the user making the request. In + particular, the addition or removal of the DAV:read privilege MUST + result in appropriate change notification to a client. + + +7. IANA Considerations + + This document does not require any actions on the part of IANA. + + +8. Normative References + + [CTAG] Daboo, C., "Calendar Collection Entity Tag (CTag) in + CalDAV", March 2007, <file:caldav-ctag-01.txt>. + + [I-D.desruisseaux-caldav-sched] + Desruisseaux, B., "Scheduling Extensions to CalDAV", + draft-desruisseaux-caldav-sched-03 (work in progress), + January 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + + + +Daboo [Page 10] + + CalDAV Resynchronization May 2007 + + + WEBDAV", RFC 2518, February 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + March 2007. + + +Appendix A. Acknowledgments + + This specification is the result of discussions between the Apple + calendar server and client teams. + + +Appendix B. Change History + + Changes from -00: + 1. Fixed some typos. + + +Author's Address + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + Email: cdaboo@apple.com + URI: http://www.apple.com/ + + + + + + + + + + + + + + + + + + +Daboo [Page 11] + Added: CalendarServer/trunk/doc/Extensions/icalendar-maskuids-02.txt =================================================================== --- CalendarServer/trunk/doc/Extensions/icalendar-maskuids-02.txt (rev 0) +++ CalendarServer/trunk/doc/Extensions/icalendar-maskuids-02.txt 2007-05-03 15:55:48 UTC (rev 1510) @@ -0,0 +1,336 @@ + + + +Calendar Server Extension C. Daboo + Apple + May 3, 2007 + + + Masking existing meetings in iCalendar free busy requests + icalendar-maskuids-02 + +Abstract + + This document defines an extension to the iTIP calendar scheduling + protocol to allow an organizer to have a specific event that may + exist on an attendee's calendar ignored when the attendee calculates + and returns their free-busy information after a request from the + organizer. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 + 3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. New features in iCalendar . . . . . . . . . . . . . . . . . . . 3 + 4.1. Mask UID Property . . . . . . . . . . . . . . . . . . . . . 3 + 4.2. Free/Busy Component . . . . . . . . . . . . . . . . . . . . 3 + 4.3. iTIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Interaction with CalDAV Servers . . . . . . . . . . . . . . . . 4 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5 + Appendix B. Change History . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + + + + + + + +Daboo [Page 1] + + iCalendar Mask UIDs May 2007 + + +1. Introduction + + Internet calendaring and scheduling standards are defined by + iCalendar [RFC2445] and iTIP [RFC2446]. One of the scheduling + operations supported by iTIP is the ability of a meeting organizer to + request free-busy time information from attendees of a meeting. To + do that, the organizer creates an iCalendar VFREEBUSY component with + start and end times corresponding to the interval over which free- + busy time needs to be known, and then sends that component in an iTIP + REQUEST message to each attendee. Attendees determine their own + free-busy information over the specified interval and return that in + a VFREEBUSY component sent back to the organizer. + + It is often the case that an existing meeting that has previously + been "booked" with attendees, needs to be re-scheduled. To do that + the organizer may again check free-busy status for each attendee to + try and determine a suitable time for the re-scheduled meeting. One + problem with this is that with the current protocol, free-busy + information returned by attendees will include a block of busy time + corresponding to the meeting that has already been booked. Whilst + the organizer could choose to treat that time as free for each + attendee given that a known meeting exists, that would not take into + account the possibility that an attendee choose to be double-booked + for some reason. + + What would be useful is a way for an organizer to ask attendees to + ignore a certain meeting (specifically the one being re-scheduled) + when asking for free-busy time in order to determine when to re- + schedule a meeting. + + This specification defines a new iCalendar property that an organizer + can include in a VFREEBUSY request that instructs an attendee's + calendar user agent to ignore any matching events when calculating + free-busy information sent back in a response. + + +2. Conventions Used in This 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 [RFC2119]. + + +3. Open Issues + + 1. Do we want some kind of indicator in the iTIP reply so that the + organizer's CUA knows whether X-CALENDARSERVER-MASK-UID was used + (supported) or not? + + + +Daboo [Page 2] + + iCalendar Mask UIDs May 2007 + + +4. New features in iCalendar + +4.1. Mask UID Property + + Property Name: X-CALENDARSERVER-MASK-UID + + Purpose: This property indicates the unique identifier for a calendar + component that is to be ignored when calculating free-busy time. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property MAY be specified in a "VFREEBUSY" calendar + component, but MUST occur only once. It only has significance when + used in an iTIP VFREEBUSY request. + + The value of this property MUST be a unique identifier of another + iCalendar component that an organizer might believe exists on an + attendee's calendar. + + As per the iCalendar UID property, implementations MUST be able to + receive and persist values of at least 255 characters for this + property. + + Formal Definition: The property is defined by the following notation: + + maskuid = "X-CALENDARSERVER-MASK-UID" maskuidparam ":" text CRLF + + maskuidparam = *(";" xparam) + + Example: The following is an example of this property: + + X-CALENDARSERVER-MASK-UID:4000F192713-0052@example.com + +4.2. Free/Busy Component + + This specification extends the definition of the VFREEBUSY component + (see Section 4.6.4 of [RFC2445]) to allow zero or one + X-CALENDARSERVER-MASK-UID properties to be present. + + + + + + + + + + +Daboo [Page 3] + + iCalendar Mask UIDs May 2007 + + + Formal Definition: (extends [RFC2445]) + + fbprop /= *( + + ; the following are optional, + ; but MUST NOT occur more than once + + maskuid + + ) + +4.3. iTIP + + This specification extends the VFREEBUSY request requirements (see + Section 3.3.2 of [RFC2446]) to allow zero or one X-CALENDARSERVER- + MASK-UID properties to be present in a VFREEBUSY component sent in a + METHOD:REQUEST iTIP message. + + When a calendar user agent receives a VFREEBUSY request containing a + X-CALENDARSERVER-MASK-UID property, it processes the free-busy + request as usual with the exception that any components that would + contribute busy time to the free-busy response MUST have their UIDs + checked, and if they match the value of the X-CALENDARSERVER-MASK-UID + property, and they have an ORGANIZER property value that is the same + as the ORGANIZER property value on the VFREEBUSY request component, + then they should be ignored and not contribute busy time. + + +5. Interaction with CalDAV Servers + + The CalDAV access [RFC4791] and scheduling + [I-D.desruisseaux-caldav-sched] extensions to WebDAV define a server- + based calendar and scheduling protocol. The scheduling portion of + that uses iTIP messaging to send requests and get responses from + calendar users. + + CalDAV servers MAY support the X-CALENDARSERVER-MASK-UID property on + any iTIP VFREEBUSY requests sent to the server. To do that, a server + simply follows the procedure described above to remove the matching + UID from the free busy result, applying the appropriate restrictions + with respect to ORGANIZER property. + + +6. Security Considerations + + Calendar user agents processing a VFREEBUSY request with a + X-CALENDARSERVER-MASK-UID property present MUST ensure that only + components whose ORGANIZER property value matches that of the + + + +Daboo [Page 4] + + iCalendar Mask UIDs May 2007 + + + VFREEBUSY request component are ignored when calculating free-busy + time. This ensures that organizers can only mask out meetings that + they themselves have scheduled, rather than meetings proposed by + other people. This also ensures that only the original organizer of + a meeting can determine whether that meeting actually appears on + someone else's calendar by using the free-busy time requests with and + without a masked UID as a probe. + + +7. IANA Considerations + + This document does not require any actions on the part of IANA. + + +8. Normative References + + [I-D.desruisseaux-caldav-sched] + Desruisseaux, B., "Scheduling Extensions to CalDAV", + draft-desruisseaux-caldav-sched-03 (work in progress), + January 2007. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", + RFC 2445, November 1998. + + [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, + "iCalendar Transport-Independent Interoperability Protocol + (iTIP) Scheduling Events, BusyTime, To-dos and Journal + Entries", RFC 2446, November 1998. + + [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, + "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, + March 2007. + + +Appendix A. Acknowledgments + + This specification is the result of discussions between the Apple + calendar server and client teams. + + +Appendix B. Change History + + Changes since -01 + + + + +Daboo [Page 5] + + iCalendar Mask UIDs May 2007 + + + 1. Added section for support in CalDAV servers. + + Changes since -00 + + 1. Change to allow at most one X-CALENDARSERVER-MASK-UID property. + + 2. Change name to X-CALENDARSERVER-MASK-UID. + + +Author's Address + + Cyrus Daboo + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + Email: cyrus@daboo.name + URI: http://www.apple.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daboo [Page 6] +