idnits 2.17.1 

draft-dusseault-caldav-10.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 18.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 4205.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4182.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4189.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4195.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (February 21, 2006) is 6632 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)

  ** Obsolete normative reference: RFC 2445 (Obsoleted by RFC 5545)

  ** Obsolete normative reference: RFC 2446 (Obsoleted by RFC 5546)

  ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)

  ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
     RFC 7232, RFC 7233, RFC 7234, RFC 7235)

  ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE4'

  -- Obsolete informational reference (is this intentional?): RFC 2251
     (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513)

  -- Obsolete informational reference (is this intentional?): RFC 2426
     (Obsoleted by RFC 6350)


     Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                           C. Daboo
3	Internet-Draft
4	Expires: August 25, 2006                                 B. Desruisseaux
5	                                                                  Oracle
6	                                                            L. Dusseault
7	                                                                    OSAF
8	                                                       February 21, 2006

10	               Calendaring Extensions to WebDAV (CalDAV)
11	                       draft-dusseault-caldav-10

13	Status of this Memo

15	   By submitting this Internet-Draft, each author represents that any
16	   applicable patent or other IPR claims of which he or she is aware
17	   have been or will be disclosed, and any of which he or she becomes
18	   aware will be disclosed, in accordance with Section 6 of BCP 79.

20	   Internet-Drafts are working documents of the Internet Engineering
21	   Task Force (IETF), its areas, and its working groups.  Note that
22	   other groups may also distribute working documents as Internet-
23	   Drafts.

25	   Internet-Drafts are draft documents valid for a maximum of six months
26	   and may be updated, replaced, or obsoleted by other documents at any
27	   time.  It is inappropriate to use Internet-Drafts as reference
28	   material or to cite them other than as "work in progress."

30	   The list of current Internet-Drafts can be accessed at
31	   http://www.ietf.org/ietf/1id-abstracts.txt.

33	   The list of Internet-Draft Shadow Directories can be accessed at
34	   http://www.ietf.org/shadow.html.

36	   This Internet-Draft will expire on August 25, 2006.

38	Copyright Notice

40	   Copyright (C) The Internet Society (2006).

42	Abstract

44	   This document specifies a set of methods, headers, message bodies,
45	   properties, and reports that define calendar access extensions to the
46	   WebDAV protocol.  The new protocol elements are intended to make
47	   WebDAV-based calendaring and scheduling an interoperable standard
48	   that supports calendar access, calendar management, calendar sharing,
49	   and calendar publishing.

51	Table of Contents

53	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
54	     1.1.  Notational Conventions . . . . . . . . . . . . . . . . . .  5
55	     1.2.  XML Namespaces . . . . . . . . . . . . . . . . . . . . . .  5
56	     1.3.  Method Preconditions and Postconditions  . . . . . . . . .  6
57	   2.  Requirements Overview  . . . . . . . . . . . . . . . . . . . .  6
58	   3.  Calendaring Data Model . . . . . . . . . . . . . . . . . . . .  7
59	     3.1.  Calendar Server  . . . . . . . . . . . . . . . . . . . . .  7
60	     3.2.  Recurrence and the Data Model  . . . . . . . . . . . . . .  8
61	   4.  Calendar Resources . . . . . . . . . . . . . . . . . . . . . .  9
62	     4.1.  Calendar Object Resources  . . . . . . . . . . . . . . . .  9
63	     4.2.  Calendar Collection  . . . . . . . . . . . . . . . . . . . 10
64	   5.  Calendar Access Feature  . . . . . . . . . . . . . . . . . . . 11
65	     5.1.  Calendar Access Support  . . . . . . . . . . . . . . . . . 11
66	       5.1.1.  Example: Using OPTIONS for the Discovery of
67	               Calendar Access Support  . . . . . . . . . . . . . . . 11
68	     5.2.  Calendar Collection Properties . . . . . . . . . . . . . . 12
69	       5.2.1.  CALDAV:calendar-description Property . . . . . . . . . 12
70	       5.2.2.  CALDAV:calendar-timezone Property  . . . . . . . . . . 12
71	       5.2.3.  CALDAV:supported-calendar-component-set Property . . . 14
72	       5.2.4.  CALDAV:supported-calendar-data Property  . . . . . . . 15
73	       5.2.5.  Additional Precondition for PROPPATCH  . . . . . . . . 15
74	     5.3.  Creating Resources . . . . . . . . . . . . . . . . . . . . 16
75	       5.3.1.  MKCALENDAR Method  . . . . . . . . . . . . . . . . . . 16
76	         5.3.1.1.  Status Codes . . . . . . . . . . . . . . . . . . . 17
77	         5.3.1.2.  Example: Successful MKCALENDAR request . . . . . . 18
78	       5.3.2.  Creating Calendar Object Resources . . . . . . . . . . 20
79	         5.3.2.1.  Additional Preconditions for PUT, COPY and MOVE  . 21
80	       5.3.3.  Non-standard components, properties and parameters . . 22
81	       5.3.4.  Calendar Object Resource Entity Tag  . . . . . . . . . 23
82	   6.  Calendaring Access Control . . . . . . . . . . . . . . . . . . 23
83	     6.1.  Calendaring Privilege  . . . . . . . . . . . . . . . . . . 23
84	       6.1.1.  CALDAV:read-free-busy Privilege  . . . . . . . . . . . 23
85	     6.2.  Additional Principal Property  . . . . . . . . . . . . . . 24
86	       6.2.1.  CALDAV:calendar-home-set Property  . . . . . . . . . . 24
87	   7.  Calendaring Reports  . . . . . . . . . . . . . . . . . . . . . 25
88	     7.1.  REPORT Method  . . . . . . . . . . . . . . . . . . . . . . 25
89	     7.2.  Ordinary collections . . . . . . . . . . . . . . . . . . . 25
90	     7.3.  Date and floating time . . . . . . . . . . . . . . . . . . 26
91	     7.4.  Time range filtering . . . . . . . . . . . . . . . . . . . 26
92	     7.5.  Returned calendar components . . . . . . . . . . . . . . . 27
93	     7.6.  Non-standard components, properties and parameters . . . . 27
94	     7.7.  CALDAV:calendar-query Report . . . . . . . . . . . . . . . 28
95	       7.7.1.  Example: Partial retrieval of events by time range . . 29
96	       7.7.2.  Example: Partial retrieval of recurring events . . . . 33
97	       7.7.3.  Example: Expanded retrieval of recurring events  . . . 36
98	       7.7.4.  Example: Partial retrieval of stored free busy
99	               components . . . . . . . . . . . . . . . . . . . . . . 38
100	       7.7.5.  Example: Retrieval of to-dos by alarm time range . . . 40
101	       7.7.6.  Example: Retrieval of event by UID . . . . . . . . . . 42
102	       7.7.7.  Example: Retrieval of events by PARTSTAT . . . . . . . 44
103	       7.7.8.  Example: Retrieval of events only  . . . . . . . . . . 46
104	       7.7.9.  Example: Attempt to query unsupported property . . . . 50
105	     7.8.  CALDAV:calendar-multiget Report  . . . . . . . . . . . . . 51
106	       7.8.1.  Example: Successful CALDAV:calendar-multiget Report  . 52
107	     7.9.  CALDAV:free-busy-query Report  . . . . . . . . . . . . . . 54
108	       7.9.1.  Example: Successful CALDAV:free-busy-query Report  . . 56
109	   8.  Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 57
110	     8.1.  Client-to-client Interoperability  . . . . . . . . . . . . 57
111	     8.2.  Synchronization Operations . . . . . . . . . . . . . . . . 57
112	       8.2.1.  Use of Reports . . . . . . . . . . . . . . . . . . . . 58
113	         8.2.1.1.  Restrict the Time Range  . . . . . . . . . . . . . 58
114	         8.2.1.2.  Synchronize by Time Range  . . . . . . . . . . . . 58
115	         8.2.1.3.  Synchronization Process  . . . . . . . . . . . . . 58
116	       8.2.2.  Restrict the Properties Returned . . . . . . . . . . . 60
117	     8.3.  Use of Locking . . . . . . . . . . . . . . . . . . . . . . 60
118	     8.4.  Finding calendars  . . . . . . . . . . . . . . . . . . . . 61
119	     8.5.  Storing and Using Attachments  . . . . . . . . . . . . . . 62
120	       8.5.1.  Inline attachments . . . . . . . . . . . . . . . . . . 62
121	       8.5.2.  External attachments . . . . . . . . . . . . . . . . . 63
122	     8.6.  Storing and Using Alarms . . . . . . . . . . . . . . . . . 64
123	   9.  XML Element Definitions  . . . . . . . . . . . . . . . . . . . 65
124	     9.1.  CALDAV:calendar XML Element  . . . . . . . . . . . . . . . 65
125	     9.2.  CALDAV:mkcalendar XML Element  . . . . . . . . . . . . . . 65
126	     9.3.  CALDAV:mkcalendar-response XML Element . . . . . . . . . . 66
127	     9.4.  CALDAV:calendar-query XML Element  . . . . . . . . . . . . 66
128	     9.5.  CALDAV:calendar-data XML Element . . . . . . . . . . . . . 66
129	       9.5.1.  CALDAV:comp XML Element  . . . . . . . . . . . . . . . 68
130	       9.5.2.  CALDAV:allcomp XML Element . . . . . . . . . . . . . . 68
131	       9.5.3.  CALDAV:allprop XML Element . . . . . . . . . . . . . . 68
132	       9.5.4.  CALDAV:prop XML Element  . . . . . . . . . . . . . . . 69
133	       9.5.5.  CALDAV:expand XML Element  . . . . . . . . . . . . . . 70
134	       9.5.6.  CALDAV:limit-recurrence-set XML Element  . . . . . . . 70
135	       9.5.7.  CALDAV:limit-freebusy-set XML Element  . . . . . . . . 71
136	     9.6.  CALDAV:filter XML Element  . . . . . . . . . . . . . . . . 72
137	       9.6.1.  CALDAV:comp-filter XML Element . . . . . . . . . . . . 72
138	       9.6.2.  CALDAV:prop-filter XML Element . . . . . . . . . . . . 73
139	       9.6.3.  CALDAV:param-filter XML Element  . . . . . . . . . . . 73
140	       9.6.4.  CALDAV:text-match XML Element  . . . . . . . . . . . . 74
141	     9.7.  CALDAV:timezone XML Element  . . . . . . . . . . . . . . . 74
142	     9.8.  CALDAV:time-range XML Element  . . . . . . . . . . . . . . 75
143	     9.9.  CALDAV:calendar-multiget XML Element . . . . . . . . . . . 77
144	     9.10. CALDAV:free-busy-query XML Element . . . . . . . . . . . . 77
145	   10. Internationalization Considerations  . . . . . . . . . . . . . 77
146	   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 77
147	   12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 78
148	     12.1. Namespace Registration . . . . . . . . . . . . . . . . . . 78
149	   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
150	   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
151	     14.1. Normative References . . . . . . . . . . . . . . . . . . . 79
152	     14.2. Informative References . . . . . . . . . . . . . . . . . . 80
153	   Appendix A.  CalDAV Method Privilege Table (Normative) . . . . . . 80
154	   Appendix B.  Calendar collections used in the examples . . . . . . 80
155	   Appendix C.  Changes . . . . . . . . . . . . . . . . . . . . . . . 86
156	     C.1.  Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 86
157	     C.2.  Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 87
158	     C.3.  Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 88
159	     C.4.  Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 89
160	     C.5.  Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 90
161	     C.6.  Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 90
162	     C.7.  Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 91
163	     C.8.  Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 91
164	     C.9.  Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 92
165	     C.10. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 92
166	   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
167	   Intellectual Property and Copyright Statements . . . . . . . . . . 94

169	1.  Introduction

171	   The concept of using HTTP [RFC2616] and WebDAV [RFC2518] as a basis
172	   for a calendar access protocol is by no means a new concept: it was
173	   discussed in the IETF CALSCH working group as early as 1997 or 1998.
174	   Several companies have implemented calendar access protocols using
175	   HTTP to upload and download iCalendar [RFC2445] objects, and using
176	   WebDAV to get listings of resources.  However, those implementations
177	   do not interoperate because there are many small and big decisions to
178	   be made in how to model calendaring data as WebDAV resources, as well
179	   as how to implement required features that aren't already part of
180	   WebDAV.  This document proposes a way to model calendar data in
181	   WebDAV, with additional features to make an interoperable calendar
182	   access protocol.

184	   Discussion of this Internet-Draft is taking place on the mailing list
185	   <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

187	1.1.  Notational Conventions

189	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
190	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
191	   document are to be interpreted as described in [RFC2119].

193	   The term "protected" is used in the Conformance field of property
194	   definitions as defined in Section 1.4.2 of [RFC3253].

196	   When XML element types in the namespaces "DAV:" and
197	   "urn:ietf:params:xml:ns:caldav" are referenced in this document
198	   outside of the context of an XML fragment, the string "DAV:" and
199	   "CALDAV:" will be prefixed to the element type names respectively.

201	1.2.  XML Namespaces

203	   Definitions of XML elements in this document use XML element type
204	   declarations (as found in XML Document Type Declarations), described
205	   in Section 3.2 of [W3C.REC-xml-20040204].

207	   The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
208	   elements defined in this specification, its revisions, and related
209	   CalDAV specifications.  XML elements defined by individual
210	   implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav"
211	   namespace, and instead should use a namespace that they control.

213	   The XML declarations used in this document do not include namespace
214	   information.  Thus, implementers MUST NOT use these declarations as
215	   the only way to create valid CalDAV properties or to validate CalDAV
216	   XML element type.  Some of the declarations refer to XML elements
217	   defined by WebDAV [RFC2518] which use the "DAV:" namespace.  Wherever
218	   such XML elements appear, they are explicitly prefixed with "DAV:" to
219	   avoid confusion.

221	   Also note that some CalDAV XML element names are identical to WebDAV
222	   XML element names, though their namespace differs.  Care must be
223	   taken not to confuse the two sets of names.

225	1.3.  Method Preconditions and Postconditions

227	   A "precondition" of a method describes the state of the server that
228	   must be true for that method to be performed.  A "postcondition" of a
229	   method describes the state of the server that must be true after that
230	   method has been completed.  If a method precondition or postcondition
231	   for a request is not satisfied, the response status of the request
232	   MUST be either 403 (Forbidden) if the request should not be repeated
233	   because it will always fail, or 409 (Conflict) if it is expected that
234	   the user might be able to resolve the conflict and resubmit the
235	   request.

237	   In order to allow better client handling of 403 and 409 responses, a
238	   distinct XML element type is associated with each method precondition
239	   and postcondition of a request.  When a particular precondition is
240	   not satisfied or a particular postcondition cannot be achieved, the
241	   appropriate XML element MUST be returned as the child of a top-level
242	   DAV:error element in the response body, unless otherwise negotiated
243	   by the request.

245	2.  Requirements Overview

247	   This section lists what functionality is required of a CalDAV server.
248	   To advertise support for CalDAV, a server:

250	   o  MUST support iCalendar [RFC2445] as a media type for calendar
251	      object resource format;

253	   o  MUST support WebDAV Class 1 [RFC2518];

255	   o  MUST support WebDAV ACL [RFC3744] with the additional privilege
256	      defined in Section 6.1 of this document;

258	   o  MUST support transport over TLS [RFC2246] as defined in [RFC2818];

260	   o  MUST support ETags [RFC2616] with additional requirements
261	      specified in Section 5.3.4 of this document;

263	   o  MUST support all calendaring REPORTs defined in Section 7 of this
264	      document; and

266	   o  MUST advertise support on all calendar collections and calendar
267	      object resources for the calendaring REPORTs in the DAV:supported-
268	      report-set property as defined in Versioning Extensions to WebDAV
269	      [RFC3253].

271	   In addition, a server:

273	   o  SHOULD support the MKCALENDAR method defined in Section 5.3.1 of
274	      this document.

276	3.  Calendaring Data Model

278	   One of the features which has made WebDAV a successful protocol is
279	   its firm data model.  This makes it a useful framework for other
280	   applications such as calendaring.  This specification follows the
281	   same pattern by developing all features based on a well-described
282	   data model.

284	   As a brief overview, a CalDAV calendar is modeled as a WebDAV
285	   collection with a defined structure; each calendar collection
286	   contains a number of resources representing calendar objects as its
287	   direct child resource.  Each resource representing a calendar object
288	   (event or to-do, or journal entry, or other calendar components) is
289	   called a "calendar object resource".  Each calendar object resource
290	   and each calendar collection can be individually locked and have
291	   individual WebDAV properties.  Requirements derived from this model
292	   are provided in Section 4.1 and Section 4.2.

294	3.1.  Calendar Server

296	   A CalDAV server is a calendaring-aware engine combined with a WebDAV
297	   repository.  A WebDAV repository is a set of WebDAV collections,
298	   containing other WebDAV resources, within a unified URL namespace.
299	   For example, the repository "http://www.example.com/webdav/" may
300	   contain WebDAV collections and resources, all of which have URLs
301	   beginning with "http://www.example.com/webdav/".  Note that the root
302	   URL "http://www.example.com/" may not itself be a WebDAV repository
303	   (for example, if the WebDAV support is implemented through a servlet
304	   or other Web server extension).

306	   A WebDAV repository MAY include calendar data in some parts of its
307	   URL namespace, and non-calendaring data in other parts.

309	   A WebDAV repository can advertise itself as a CalDAV server if it
310	   supports the functionality defined in this specification at any point
311	   within the root of the repository.  That might mean that calendaring
312	   data is spread throughout the repository and mixed with non-calendar
313	   data in nearby collections (e.g., calendar data may be found in
314	   /home/lisa/calendars/ as well as in /home/bernard/calendars/, and
315	   non-calendar data in /home/lisa/contacts/).  Or, it might mean that
316	   calendar data can be found only in certain sections of the repository
317	   (e.g., /calendar/).  Calendaring features are only required in the
318	   repository sections that are or contain calendar object resources.
319	   So a repository confining calendar data to the /calendar/ collection
320	   would only need to support the CalDAV required features within that
321	   collection.

323	   The CalDAV server or repository is the canonical location for
324	   calendar data and state information.  Both CalDAV servers and clients
325	   MUST ensure that the data is consistent and compliant.  Clients may
326	   submit requests to change data or download data.  Clients may store
327	   calendar objects offline and attempt to synchronize at a later time.
328	   However, clients MUST be prepared for calendar data on the server to
329	   change between the time of last synchronization and when attempting
330	   an update, as calendar collections may be shared and accessible via
331	   multiple clients.  Entity tags and other features make this possible.

333	3.2.  Recurrence and the Data Model

335	   Recurrence is an important part of the data model because it governs
336	   how many resources are expected to exist.  This specification models
337	   a recurring calendar component and its recurrence exceptions as a
338	   single resource.  In this model, recurrence rules, recurrence dates,
339	   exception rules, and exception dates are all part of the data in a
340	   single calendar object resource.  This model avoids problems of
341	   limiting how many recurrence instances to store in the repository,
342	   how to keep recurrence instances in sync with the recurring calendar
343	   component, and how to link recurrence exceptions with the recurring
344	   calendar component.  It also results in less data to synchronize
345	   between client and server, and makes it easier to make changes to all
346	   recurrence instances or to a recurrence rule.  It makes it easier to
347	   create a recurring calendar component, and easier to delete all
348	   recurrence instances.

350	   Clients are not forced to retrieve information about all recurrence
351	   instances of a recurring component.  The CALDAV:calendar-query and
352	   CALDAV:calendar-multiget REPORTs defined in this document allow
353	   clients to retrieve only recurrence instances that overlap a given
354	   time range.

356	4.  Calendar Resources

358	4.1.  Calendar Object Resources

360	   Calendar object resources contained in calendar collections MUST NOT
361	   contain more than one type of calendar component (e.g., VEVENT,
362	   VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
363	   components which MUST be specified for each unique TZID parameter
364	   value specified in the iCalendar object.  For instance, a calendar
365	   object resource can contain two VEVENT components and one VTIMEZONE
366	   component, but it cannot contain one VEVENT component and one VTODO
367	   component.

369	   Calendar object resources contained in calendar collections MUST NOT
370	   specify the iCalendar METHOD property.

372	   The UID property value of the calendar components contained in a
373	   calendar object resource MUST be unique in the scope of the calendar
374	   collection in which they are stored.

376	   Calendar components in a calendar collection that have different UID
377	   property values MUST be stored in separate calendar object resources.

379	   Calendar components with the same UID property value, in a given
380	   calendar collection, MUST be contained in the same calendar object
381	   resource.  This ensures that all components in a recurrence "set" are
382	   contained in the same calendar object resource.  It is possible for a
383	   calendar object resource to just contain components that represent
384	   "overridden" instances (ones which modify the behavior of a regular
385	   instance, and thus include a RECURRENCE-ID property), without also
386	   including the "master" recurring component (the one that defines the
387	   recurrence "set" and does not contain any "RECURRENCE-ID" property).

389	   For example, given the following iCalendar object:

391	    BEGIN:VCALENDAR
392	    PRODID:-//Example Corp.//CalDAV Client//EN
393	    VERSION:2.0
394	    BEGIN:VEVENT
395	    UID:1@example.com
396	    SUMMARY:One-off Meeting
397	    DTSTAMP:20041210T183904Z
398	    DTSTART:20041207T120000Z
399	    DTEND:20041207T130000Z
400	    END:VEVENT
401	    BEGIN:VEVENT
402	    UID:2@example.com
403	    SUMMARY:Weekly Meeting
404	    DTSTAMP:20041210T183838Z
405	    DTSTART:20041206T120000Z
406	    DTEND:20041206T130000Z
407	    RRULE:FREQ=WEEKLY
408	    END:VEVENT
409	    BEGIN:VEVENT
410	    UID:2@example.com
411	    SUMMARY:Weekly Meeting
412	    RECURRENCE-ID:20041213T120000Z
413	    DTSTAMP:20041210T183838Z
414	    DTSTART:20041213T130000Z
415	    DTEND:20041213T140000Z
416	    END:VEVENT
417	    END:VCALENDAR

419	   The VEVENT component with the UID value "1@example.com", would be
420	   stored in its own calendar object resource.  The two VEVENT
421	   components with the UID value "2@example.com", which represent a
422	   recurring event where one recurrence instance has been overridden,
423	   would be stored in the same calendar object resource.

425	4.2.  Calendar Collection

427	   A calendar collection contains calendar object resources that
428	   represent calendar components within a calendar.  A calendar
429	   collection is manifested to clients as a WebDAV resource collection
430	   identified by a URL.  A calendar collection MUST report the DAV:
431	   collection and CALDAV:calendar XML elements in the value of the DAV:
432	   resourcetype property.  The element type declaration for CALDAV:
433	   calendar is:

435	       <!ELEMENT calendar EMPTY>

437	   A calendar collection can be created through provisioning (e.g.,
438	   automatically created when a user's account is provisioned), or it
439	   can be created with the MKCALENDAR method (see Section 5.3.1).  This
440	   method can be useful for a user to create additional calendars (e.g.,
441	   soccer schedule) or for users to share a calendar (e.g., team events
442	   or conference room).  Note however that this document doesn't define
443	   what extra calendar collections are for.  Users must rely on non-
444	   standard cues to find out what a calendar collection is for, or use
445	   the CALDAV:calendar-description property defined in Section 5.2.1 to
446	   provide such a cue.

448	   Calendar collections MUST only contain calendar object resources and
449	   collections that are not calendar collections.  Furthermore,
450	   collections contained in calendar collections MUST NOT contain
451	   calendar collections.  This specification does not define how
452	   collections contained in calendar collections are used and may relate
453	   to the calendar object resources contained in the calendar
454	   collections.

456	   Multiple calendar collections MAY be children of the same collection.

458	5.  Calendar Access Feature

460	5.1.  Calendar Access Support

462	   A server supporting the features described in this document MUST
463	   include "calendar-access" as a field in the DAV response header from
464	   an OPTIONS request on any resource that supports any calendar
465	   properties, reports, method, or privilege.  A value of "calendar-
466	   access" in the DAV response header MUST indicate that the server
467	   supports all MUST level requirements specified in this document.

469	5.1.1.  Example: Using OPTIONS for the Discovery of Calendar Access
470	        Support

472	   >> Request <<

474	   OPTIONS /home/bernard/calendars/ HTTP/1.1
475	   Host: cal.example.com

477	   >> Response <<

479	   HTTP/1.1 200 OK
480	   Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
481	   Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
482	   DAV: 1, 2, access-control, calendar-access
483	   Date: Fri, 11 Nov 2005 09:32:12 GMT
484	   Content-Length: 0
485	   In this example, the OPTIONS method returns the value "calendar-
486	   access" in the DAV response header to indicate that the collection
487	   "/home/bernard/calendars/" may support properties, reports, methods,
488	   or privilege defined in this specification.

490	5.2.  Calendar Collection Properties

492	   This section defines properties that MAY be defined on calendar
493	   collections.

495	5.2.1.  CALDAV:calendar-description Property

497	   Name: calendar-description

499	   Namespace: urn:ietf:params:xml:ns:caldav

501	   Purpose: Provides a human-readable description of the calendar
502	      collection.

504	   Conformance: This property MAY be protected and SHOULD NOT be
505	      returned by a PROPFIND DAV:allprop request (as defined in Section
506	      12.14.1 of [RFC2518]).  An xml:lang attribute indicating the human
507	      language of the description SHOULD be set for this property by
508	      clients or through server provisioning.  Servers MUST return any
509	      xml:lang attribute if set for the property.

511	   Description: The CALDAV:calendar-description property MAY be defined
512	      on any calendar collection.  If present, the property contains a
513	      description of the calendar collection that is suitable for
514	      presentation to a user.

516	   Definition:

518	         <!ELEMENT calendar-description (#PCDATA)>
519	         PCDATA value: string

521	   Example:

523	         <C:calendar-description xml:lang="fr-CA"
524	            xmlns:C="urn:ietf:params:xml:ns:caldav"
525	         >Calendrier de Mathilde Desruisseaux</C:calendar-description>

527	5.2.2.  CALDAV:calendar-timezone Property
528	   Name: calendar-timezone

530	   Namespace: urn:ietf:params:xml:ns:caldav

532	   Purpose: Specifies a time zone on a calendar collection.

534	   Conformance: This property SHOULD NOT be returned by a PROPFIND DAV:
535	      allprop request (as defined in Section 12.14.1 of [RFC2518]).

537	   Description: The CALDAV:calendar-timezone property SHOULD be defined
538	      on all calendar collections to specify the time zone the server
539	      should rely on to resolve "date" values and "date with local time"
540	      values (i.e., floating time) to "date with UTC time" values.  The
541	      server will require this information to determine if a calendar
542	      component scheduled with "date" values or "date with local time"
543	      values overlaps a CALDAV:time-range specified in a CALDAV:
544	      calendar-query REPORT.  The server will also require this
545	      information to compute the proper FREEBUSY time period as "date
546	      with UTC time" in the VFREEBUSY component returned in a response
547	      to a CALDAV:free-busy-query REPORT request that takes into account
548	      calendar components scheduled with "date" values or "date with
549	      local time" values.

551	   Definition:

553	         <!ELEMENT calendar-timezone (#PCDATA)>
554	         PCDATA value: an iCalendar object with exactly one VTIMEZONE
555	               component.

557	   Example:

559	    <C:calendar-timezone
560	       xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR
561	   PRODID:-//Example Corp.//CalDAV Client//EN
562	   VERSION:2.0
563	   BEGIN:VTIMEZONE
564	   TZID:US-Eastern
565	   LAST-MODIFIED:19870101T000000Z
566	   BEGIN:STANDARD
567	   DTSTART:19671029T020000
568	   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
569	   TZOFFSETFROM:-0400
570	   TZOFFSETTO:-0500
571	   TZNAME:Eastern Standard Time (US &amp; Canada)
572	   END:STANDARD
573	   BEGIN:DAYLIGHT
574	   DTSTART:19870405T020000
575	   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
576	   TZOFFSETFROM:-0500
577	   TZOFFSETTO:-0400
578	   TZNAME:Eastern Daylight Time (US &amp; Canada)
579	   END:DAYLIGHT
580	   END:VTIMEZONE
581	   END:VCALENDAR
582	   </C:calendar-timezone>

584	5.2.3.  CALDAV:supported-calendar-component-set Property

586	   Name: supported-calendar-component-set

588	   Namespace: urn:ietf:params:xml:ns:caldav

590	   Purpose: Specifies the calendar component types (e.g., VEVENT, VTODO,
591	      etc.) that calendar object resources may contain in the calendar
592	      collection.

594	   Conformance: This property MUST be protected and SHOULD NOT be
595	      returned by a PROPFIND DAV:allprop request (as defined in Section
596	      12.14.1 of [RFC2518]).

598	   Description: The CALDAV:supported-calendar-component-set property MAY
599	      be defined on any calendar collection to specify restrictions on
600	      the calendar component types that calendar object resources may
601	      contain in a calendar collection.  Since this property is
602	      protected it cannot be changed by clients using a PROPPATCH
603	      request.  However, clients can initialize the value of this
604	      property when creating a new calendar collection with MKCALENDAR.
605	      The empty-element tag <C:comp name="VTIMEZONE"/> MUST only be
606	      specified if support for calendar object resources that only
607	      contain VTIMEZONE components is provided or desired.  Support for
608	      VTIMEZONE components in calendar object resources that contain
609	      VEVENT or VTODO components is always assumed.

611	   Definition:

613	         <!ELEMENT supported-calendar-component-set (comp*)>

615	   Example:

617	         <C:supported-calendar-component-set
618	             xmlns:C="urn:ietf:params:xml:ns:caldav">
619	           <C:comp name="VEVENT"/>
620	           <C:comp name="VTODO"/>
621	         </C:supported-calendar-component-set>

623	5.2.4.  CALDAV:supported-calendar-data Property

625	   Name: supported-calendar-data

627	   Namespace: urn:ietf:params:xml:ns:caldav

629	   Purpose: Specifies restrictions on a calendar collection.

631	   Conformance: This property MUST be protected and SHOULD NOT be
632	      returned by a PROPFIND DAV:allprop request (as defined in Section
633	      12.14.1 of [RFC2518]).

635	   Description: The CALDAV:supported-calendar-data property MAY be
636	      defined on any calendar collection to specify the media type
637	      supported for the calendar object resources contained in a given
638	      calendar collection (e.g., iCalendar version 2.0).

640	   Definition:

642	         <!ELEMENT supported-calendar-data (calendar-data*)>

644	   Example:

646	         <C:supported-calendar-data
647	            xmlns:C="urn:ietf:params:xml:ns:caldav">
648	           <C:calendar-data content-type="text/calendar" version="2.0"/>
649	         </C:supported-calendar-data>

651	5.2.5.  Additional Precondition for PROPPATCH

653	   This specification creates an additional Precondition for the
654	   PROPPATCH method.  The precondition is:

656	      (CALDAV:valid-calendar-data): The time zone specified in CALDAV:
657	      calendar-timezone property MUST be a valid iCalendar object
658	      containing a single valid VTIMEZONE component.

660	5.3.  Creating Resources

662	   The creation of calendar collections and calendar object resources
663	   may be initiated by either a CalDAV client or by the CalDAV server.
664	   For example, a server might come pre-configured with a user's
665	   calendar collection, or the CalDAV client might request the server to
666	   create a new calendar collection for a given user.  Servers might
667	   populate events as calendar objects inside a calendar collection, or
668	   clients might request the server to create events.  Either way, both
669	   client and server MUST comply with the requirements in this document,
670	   and MUST understand objects appearing in calendar collections or
671	   according to the data model defined here.

673	5.3.1.  MKCALENDAR Method

675	   An HTTP request using the MKCALENDAR method creates a new calendar
676	   collection resource.  A server MAY restrict calendar collection
677	   creation to particular collections.

679	   Support for MKCALENDAR on the server is only RECOMMENDED and not
680	   REQUIRED because some calendar stores only support one calendar per
681	   user (or principal) and those are typically pre-created for each
682	   account.  However, servers and clients are strongly encouraged to
683	   support MKCALENDAR whenever possible to allow users to create
684	   multiple calendar collections to better help organize their data.

686	   Clients SHOULD use the DAV:displayname property for a human-readable
687	   name of the calendar.  Clients can either specify the value of the
688	   DAV:displayname property in the request body of the MKCALENDAR
689	   request, or alternatively issue a PROPPATCH request to change the
690	   DAV:displayname property to the appropriate value immediately after
691	   issuing the MKCALENDAR request.  Clients SHOULD NOT set the DAV:
692	   displayname property to be the same as any other calendar collection
693	   at the same URI "level".  When displaying calendar collections to
694	   users, clients SHOULD check the DAV:displayname property and use that
695	   value as the name of the calendar.  In the event that the DAV:
696	   displayname property is empty, the client MAY use the last part of
697	   the calendar collection URI as the name, however that path segment
698	   may be "opaque" and not represent any meaningful human-readable text.

700	   If a MKCALENDAR request fails, the server state preceding the request
701	   MUST be restored.

703	   Marshalling:

705	      If a request body is included, it MUST be a CALDAV:mkcalendar XML
706	      element.  Instruction processing MUST occur in the order
707	      instructions are received (i.e., from top to bottom).
708	      Instructions MUST either all be executed or none executed.  Thus
709	      if any error occurs during processing, all executed instructions
710	      MUST be undone and a proper error result returned.  Instruction
711	      processing details can be found in the definition of the DAV:set
712	      instruction in Section 12.13 of [RFC2518].

714	         <!ELEMENT mkcalendar (DAV:set)>

716	      If a response body for a successful request is included, it MUST
717	      be a CALDAV:mkcalendar-response XML element.

719	         <!ELEMENT mkcalendar-response ANY>

721	      The response MUST include a Cache-Control:no-cache header.

723	   Preconditions:

725	      (DAV:resource-must-be-null): A resource MUST NOT exist at the
726	      Request-URI;

728	      (CALDAV:calendar-collection-location-ok): The Request-URI MUST
729	      identify a location where a calendar collection can be created;

731	      (CALDAV:valid-calendar-data): The time zone specified in the
732	      CALDAV:calendar-timezone property MUST be a valid iCalendar object
733	      containing a single valid VTIMEZONE component;

735	      (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
736	      the current user on the parent collection of the Request-URI.

738	   Postconditions:

740	      (CALDAV:initialize-calendar-collection): A new calendar collection
741	      exists at the Request-URI.  The DAV:resourcetype of the calendar
742	      collection MUST contain both DAV:collection and CALDAV:calendar
743	      XML elements.

745	5.3.1.1.  Status Codes

747	   The following are examples of response codes one would expect to get
748	   in a response to a MKCALENDAR request.  Note that this list is by no
749	   means exhaustive.

751	      201 (Created) - The calendar collection resource was created in
752	      its entirety;
753	      207 (Multi-Status) - The calendar collection resource was not
754	      created since one or more DAV:set instructions specified in the
755	      request body could not be processed successfully.  The following
756	      are examples of response codes one would expect to be used in a
757	      207 (Multi-Status) response in this situation:

759	         403 (Forbidden) - The client, for reasons the server chooses
760	         not to specify, cannot alter one of the properties;

762	         409 (Conflict) - The client has provided a value whose
763	         semantics are not appropriate for the property.  This includes
764	         trying to set read-only properties;

766	         424 (Failed Dependency) - The DAV:set instruction on the
767	         specified resource would have succeeded if it were not for the
768	         failure of another DAV:set instruction specified in the request
769	         body;

771	         423 (Locked) - The specified resource is locked and the client
772	         either is not a lock owner or the lock type requires a lock
773	         token to be submitted and the client did not submit it; and

775	         507 (Insufficient Storage) - The server did not have sufficient
776	         space to record the property;

778	      403 (Forbidden) - This indicates at least one of two conditions:
779	      1) the server does not allow the creation of calendar collections
780	      at the given location in its namespace, or 2) the parent
781	      collection of the Request-URI exists but cannot accept members;

783	      409 (Conflict) - A collection cannot be made at the Request-URI
784	      until one or more intermediate collections have been created;

786	      415 (Unsupported Media Type) - The server does not support the
787	      request type of the body; and

789	      507 (Insufficient Storage) - The resource does not have sufficient
790	      space to record the state of the resource after the execution of
791	      this method.

793	5.3.1.2.  Example: Successful MKCALENDAR request

795	   This example creates a calendar collection called /home/lisa/
796	   calendars/events/ on the server cal.example.com with specific values
797	   for the properties DAV:displayname, CALDAV:calendar-description,
798	   CALDAV:supported-calendar-component-set, and CALDAV:calendar-
799	   timezone.

801	   >> Request <<

803	   MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
804	   Host: cal.example.com
805	   Content-Type: application/xml; charset="utf-8"
806	   Content-Length: xxxx

808	   <?xml version="1.0" encoding="utf-8" ?>
809	   <C:mkcalendar xmlns:D="DAV:"
810	                 xmlns:C="urn:ietf:params:xml:ns:caldav">
811	     <D:set>
812	       <D:prop>
813	         <D:displayname>Lisa's Events</D:displayname>
814	         <C:calendar-description xml:lang="en"
815	   >Calendar restricted to events.</C:calendar-description>
816	         <C:supported-calendar-component-set>
817	           <C:comp name="VEVENT"/>
818	         </C:supported-calendar-component-set>
819	         <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR
820	   PRODID:-//Example Corp.//CalDAV Client//EN
821	   VERSION:2.0
822	   BEGIN:VTIMEZONE
823	   TZID:US-Eastern
824	   LAST-MODIFIED:19870101T000000Z
825	   BEGIN:STANDARD
826	   DTSTART:19671029T020000
827	   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
828	   TZOFFSETFROM:-0400
829	   TZOFFSETTO:-0500
830	   TZNAME:Eastern Standard Time (US & Canada)
831	   END:STANDARD
832	   BEGIN:DAYLIGHT
833	   DTSTART:19870405T020000
834	   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
835	   TZOFFSETFROM:-0500
836	   TZOFFSETTO:-0400
837	   TZNAME:Eastern Daylight Time (US & Canada)
838	   END:DAYLIGHT
839	   END:VTIMEZONE
840	   END:VCALENDAR
841	   ]]></C:calendar-timezone>
842	       </D:prop>
843	     </D:set>
844	   </C:mkcalendar>
845	   >> Response <<

847	   HTTP/1.1 201 Created
848	   Cache-Control: no-cache
849	   Date: Fri, 11 Nov 2005 09:32:12 GMT
850	   Content-Length: 0

852	5.3.2.  Creating Calendar Object Resources

854	   Clients populate calendar collections with calendar object resources.
855	   The URL for each calendar object resource is entirely arbitrary, and
856	   does not need to bear a specific relationship to the calendar object
857	   resource's iCalendar properties or other metadata.  New calendar
858	   object resources MUST be created with a PUT request targeted at an
859	   unmapped URI.  A PUT request targeted at a mapped URI updates an
860	   existing calendar object resource.

862	   When servers create new resources, it's not hard for the server to
863	   choose an unmapped URI.  It's slightly tougher for clients, because a
864	   client might not want to examine all resources in the collection, and
865	   might not want to lock the entire collection to ensure that a new
866	   resource isn't created with a name collision.  However, there is an
867	   HTTP feature to mitigate this.  If the client intends to create a new
868	   non-collection resource, such as a new VEVENT, the client SHOULD use
869	   the HTTP request header "If-None-Match: *" on the PUT request.  The
870	   Request-URI on the PUT request MUST include the target collection,
871	   where the resource is to be created, plus the name of the resource in
872	   the last path segment.  The "If-None-Match: *" request header ensures
873	   that the client will not inadvertently overwrite an existing
874	   resource, if the last path segment turned out to already be used.

876	   >> Request <<

878	   PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1
879	   If-None-Match: *
880	   Host: cal.example.com
881	   Content-Type: text/calendar
882	   Content-Length: xxxx

884	   BEGIN:VCALENDAR
885	   VERSION:2.0
886	   PRODID:-//Example Corp.//CalDAV Client//EN
887	   BEGIN:VEVENT
888	   UID:20010712T182145Z-123401@example.com
889	   DTSTAMP:20010712T182145Z
890	   DTSTART:20010714T170000Z
891	   DTEND:20010715T040000Z
892	   SUMMARY:Bastille Day Party
893	   END:VEVENT
894	   END:VCALENDAR

896	   >> Response <<

898	   HTTP/1.1 201 Created
899	   Content-Length: 0
900	   Date: Fri, 11 Nov 2005 09:32:12 GMT
901	   ETag: "123456789-000-111"

903	   The request to change an existing event is the same, but with a
904	   specific ETag in the "If-Match" header, rather than the "If-None-
905	   Match" header.

907	   As indicated in Section 3.10 of [RFC2445], the URL of calendar object
908	   resources containing (an arbitrary set of) calendaring and scheduling
909	   information may be suffixed by ".ics", and the URL of calendar object
910	   resources containing free or busy time information may be suffixed by
911	   ".ifb".

913	5.3.2.1.  Additional Preconditions for PUT, COPY and MOVE

915	   This specification creates additional Preconditions for PUT, COPY and
916	   MOVE methods.  These preconditions apply:

918	      When a PUT operation of a calendar object resource into a calendar
919	      collection occurs.

921	      When a COPY or MOVE operation of a calendar object resource into a
922	      calendar collection occurs.

924	   The new preconditions are:

926	      (CALDAV:supported-calendar-data): The resource submitted in the
927	      PUT request, or targeted by a COPY or MOVE request MUST be a
928	      supported media type (i.e., iCalendar) for calendar object
929	      resources;

931	      (CALDAV:valid-calendar-data): The resource submitted in the PUT
932	      request, or targeted by a COPY or MOVE request MUST be valid data
933	      for the media type being specified (i.e., MUST contain valid
934	      iCalendar data);

936	      (CALDAV:valid-calendar-object-resource): The resource submitted in
937	      the PUT request, or targeted by a COPY or MOVE request MUST obey
938	      all restrictions specified in Section 4.1 (e.g., calendar object
939	      resources MUST NOT contain more than one type of calendar
940	      component, calendar object resources MUST NOT specify the
941	      iCalendar METHOD property, etc.);

943	      (CALDAV:supported-calendar-component): The resource submitted in
944	      the PUT request, or targeted by a COPY or MOVE request MUST
945	      contain a type of calendar component that is supported in the
946	      targeted calendar collection;

948	      (CALDAV:no-uid-conflict): The resource submitted in the PUT
949	      request, or targeted by a COPY or MOVE request MUST NOT specify an
950	      iCalendar UID property value already in use in the targeted
951	      calendar collection or overwrite an existing calendar object
952	      resource with one that has a different UID property value.
953	      Servers SHOULD report the URL of the resource that is already
954	      making use of the same UID property value in the DAV:resource
955	      element;

957	                <!ELEMENT no-uid-conflict (DAV:resource)>

959	5.3.3.  Non-standard components, properties and parameters

961	   iCalendar provides a "standard mechanism for doing non-standard
962	   things".  This extension support allows implementers to make use of
963	   non-standard components, properties and parameters whose names are
964	   prefixed with the text "X-".

966	   Servers MUST support the use of non-standard components, properties
967	   and parameters in calendar object resources stored via the PUT
968	   method.

970	   Servers MAY reject any non-standard components, properties and
971	   parameters that have specific values in calendar object resources
972	   stored via the PUT method.  This allows the server to enforce rules
973	   for its own "private" values that it may use.

975	5.3.4.  Calendar Object Resource Entity Tag

977	   The DAV:getetag property MUST be defined and set to a strong entity
978	   tag on all calendar object resources.

980	   A response to a GET request targeted at a calendar object resource
981	   MUST contain an ETag response header field indicating the current
982	   value of the strong entity tag of the calendar object resource.

984	   A response to a PUT request MAY contain an ETag response header field
985	   indicating the current value of the entity tag for the calendar
986	   object resource just created or modified.

988	   As required by [RFC2616], a response to a PUT request with a strong
989	   entity tag MUST mean that the server will return on a subsequent GET
990	   request a calendar object resource that is equivalent by octet
991	   equality.

993	   A response to a PUT request MUST NOT contain an ETag response header
994	   field if the server will return on a subsequent GET request a
995	   calendar object resource that is not equivalent by octet equality to
996	   the submitted calendar object resource.  In this case, the client
997	   SHOULD retrieve the new entity (and ETag) as a basis for further
998	   changes, rather than use the entity it had sent with the PUT request.

1000	6.  Calendaring Access Control

1002	6.1.  Calendaring Privilege

1004	   CalDAV servers MUST support and adhere to the requirements of WebDAV
1005	   ACL [RFC3744].  WebDAV ACL provides a framework for an extensible set
1006	   of privileges that can be applied to WebDAV collections and ordinary
1007	   resources.  CalDAV servers MUST also support the calendaring
1008	   privilege defined in this section.

1010	6.1.1.  CALDAV:read-free-busy Privilege

1012	   Calendar users often wish to allow other users to see their busy time
1013	   information, without viewing the other details of the calendar
1014	   components (location, summary, attendees).  This allows a significant
1015	   amount of privacy while still allowing other users to schedule
1016	   meetings at times when the user is likely to be free.

1018	   The CALDAV:read-free-busy privilege controls which calendar
1019	   collections and calendar object resources are examined when a CALDAV:
1020	   free-busy-query REPORT request is processed (see Section 7.9).  This
1021	   privilege can be granted on calendar collections or calendar object
1022	   resources.  Servers MUST support this privilege on all calendar
1023	   collections and calendar object resources.

1025	           <!ELEMENT read-free-busy EMPTY>

1027	   The CALDAV:read-free-busy privilege MUST be aggregated in the DAV:
1028	   read privilege.  Servers MUST allow the CALDAV:read-free-busy to be
1029	   granted without the DAV:read privilege being granted.

1031	   Clients should note that when only the CALDAV:read-free-busy
1032	   privilege has been granted on a resource, this does not imply access
1033	   to GET, HEAD, OPTIONS and PROPFIND on the resource -- those
1034	   operations are governed by the DAV:read privilege.

1036	6.2.  Additional Principal Property

1038	   This section defines an additional property for WebDAV principal
1039	   resources as defined in [RFC3744].

1041	6.2.1.  CALDAV:calendar-home-set Property

1043	   Name: calendar-home-set

1045	   Namespace: urn:ietf:params:xml:ns:caldav

1047	   Purpose: Identifies the URL of any WebDAV collections that contain
1048	      calendar collections owned by the associated principal resource.

1050	   Conformance: This property MAY be protected and SHOULD NOT be
1051	      returned by a PROPFIND DAV:allprop request (as defined in Section
1052	      12.14.1 of [RFC2518]).  Support for this property is RECOMMENDED.

1054	   Description: The CALDAV:calendar-home-set property is meant to allow
1055	      users to easily find the calendar collections owned by the
1056	      principal.  Typically, users will group all the calendar
1057	      collections that they own under a common collection.  This
1058	      property specify the URL of collections that either are calendar
1059	      collections or ordinary collections that have child or descendant
1060	      calendar collections owned by the principal.

1062	   Definition:

1064	         <!ELEMENT calendar-home-set (DAV:href*)>

1066	   Example:

1068	       <C:calendar-home-set xmlns:D="DAV:"
1069	                            xmlns:C="urn:ietf:params:xml:ns:caldav">
1070	         <D:href>http://cal.example.com/home/bernard/calendars/</D:href>
1071	       </C:calendar-home-set>

1073	7.  Calendaring Reports

1075	   This section defines the REPORTs that CalDAV servers MUST support on
1076	   calendar collections and calendar object resources.

1078	   CalDAV servers MUST advertise support for these REPORTs on all
1079	   calendar collections and calendar object resources with the DAV:
1080	   supported-report-set property defined in Section 3.1.5 of [RFC3253].
1081	   CalDAV servers MAY also advertise support for these REPORTs on
1082	   ordinary collections.

1084	   Some of these REPORTs allow calendar data (from possibly multiple
1085	   resources) to be returned.

1087	7.1.  REPORT Method

1089	   The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
1090	   extensible mechanism for obtaining information about one or more
1091	   resources.  Unlike the PROPFIND method, which returns the value of
1092	   one or more named properties, the REPORT method can involve more
1093	   complex processing.  REPORT is valuable in cases where the server has
1094	   access to all of the information needed to perform the complex
1095	   request (such as a query), and where it would require multiple
1096	   requests for the client to retrieve the information needed to perform
1097	   the same request.

1099	   CalDAV servers MUST support the DAV:expand-property REPORT defined in
1100	   Section 3.8 of [RFC3253].

1102	7.2.  Ordinary collections

1104	   Servers MAY support the REPORTs defined in this document on ordinary
1105	   collections, that is, collections that are not calendar collections.
1106	   In computing responses to the REPORTs defined in this document,
1107	   servers MUST only consider calendar object resources contained in
1108	   calendar collections, subject also to the value of the Depth request
1109	   header.

1111	7.3.  Date and floating time

1113	   iCalendar provides a way to specify DATE and DATE-TIME values that
1114	   are not bound to any time zone in particular, hereafter called
1115	   "floating date" and "floating time" respectively.  These values are
1116	   used to represent the same day, hour, minute and second value
1117	   regardless of which time zone is being observed.  For instance, the
1118	   DATE value "20051111", represents November 11th, 2005 in no specific
1119	   time zone, while the DATE-TIME value "20051111T111100" represents
1120	   November 11th, 2005 at 11:11 AM in no specific time zone.

1122	   CalDAV servers may need to convert "floating date" and "floating
1123	   time" values in date with UTC time values in the processing of
1124	   calendaring REPORT requests.

1126	   For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the
1127	   value of the CALDAV:timezone XML element, if specified as part of the
1128	   request body, to perform the proper conversion of "floating date" and
1129	   "floating time" values to date with UTC time values.  If the CALDAV:
1130	   timezone XML element is not specified in the request body, CalDAV
1131	   servers MUST rely on the value of the CALDAV:calendar-timezone
1132	   property, if defined, else the CalDAV servers MAY rely on the time
1133	   zone of their choice.

1135	   For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on
1136	   the value of the CALDAV:calendar-timezone property, if defined, to
1137	   compute the proper FREEBUSY time period value as date with UTC time,
1138	   for calendar components scheduled with "floating date" or "floating
1139	   time".  If the CALDAV:calendar-timezone property is not defined,
1140	   CalDAV servers MAY rely on the time zone of their choice.

1142	7.4.  Time range filtering

1144	   Some of the reports defined in this section can be targeted at
1145	   calendar object resources within a specific time range.  To determine
1146	   whether a calendar object resource matches the time range filter
1147	   element, the start and end times for the particular type of object
1148	   are determined and then compared to the requested time range.  If the
1149	   start and end overlap the requested time range, then the calendar
1150	   object resource matches the filter element.  The rules defined in
1151	   [RFC2445] for determining the actual start and end times of calendar
1152	   components MUST be used, along with the rules for determining overlap
1153	   specified in Section 9.8 of this document.

1155	   When such time range filtering is used, special consideration must be
1156	   given to recurring calendar components such as VEVENT and VTODO
1157	   components.  The server MUST expand recurring components to determine
1158	   whether any recurrence instances overlap the specified time range.

1160	   If one or more recurrence instances overlap the time range, then the
1161	   calendar object resource matches the filter element.

1163	7.5.  Returned calendar components

1165	   In addition, CalDAV provides three ways to determine which components
1166	   of a calendar object resource are returned from the recurrence set.
1167	   The three options are:

1169	   1.  Return all the calendar components contained in the calendar
1170	       object resources.  This includes the component that defines the
1171	       recurrence set, referred to as the "master component", as well as
1172	       the components that define exceptions to the recurrence set,
1173	       referred to as the "overridden components".  According to the
1174	       rules defined in Section 3.2 all recurrence instances of a
1175	       recurring component will always be contained in the same calendar
1176	       object resource.

1178	   2.  Return the "master component" and only the "overridden
1179	       components" that currently or originally overlap the specified
1180	       time range.  This avoids the need for clients to process
1181	       "overridden components" outside of the time range they are
1182	       interested in.  See Section 9.5.6.

1184	   3.  Return "expanded" calendar components that represent only those
1185	       recurrence instances in the recurrence set that overlap the
1186	       specified time range.  This avoids the need for clients to do any
1187	       recurrence processing themselves as the server does the expansion
1188	       for them and provides the list of instances.  See Section 9.5.5.

1190	7.6.  Non-standard components, properties and parameters

1192	   Servers MUST support the use of non-standard component, property or
1193	   parameter names in the CALDAV:calendar-data XML element in
1194	   calendaring REPORT requests to allow clients to request that non-
1195	   standard components, properties and parameters be returned in the
1196	   calendar data provided in the response.

1198	   Servers MAY support the use of non-standard component, property or
1199	   parameter names in the CALDAV:comp-filter, CALDAV:prop-filter and
1200	   CALDAV:param-filter XML elements specified in the CALDAV:filter XML
1201	   element of calendaring REPORT requests.

1203	   Servers MUST fail with the CALDAV:supported-filter precondition if a
1204	   calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop-
1205	   filter or CALDAV:param-filter XML element that makes reference to a
1206	   non-standard component, property or parameter name which the server
1207	   does not support queries on.

1209	7.7.  CALDAV:calendar-query Report

1211	   The CALDAV:calendar-query REPORT performs a search for all calendar
1212	   object resources that match a specified filter.  The response of this
1213	   REPORT will contain all the WebDAV properties and calendar object
1214	   resource data specified in the request.  In the case of the CALDAV:
1215	   calendar-data XML element, one can explicitly specify the calendar
1216	   components and properties that should be returned in the calendar
1217	   object resource data that matches the filter.

1219	   The format of this REPORT is modeled on the PROPFIND method.  The
1220	   request and response bodies of the CALDAV:calendar-query REPORT use
1221	   XML elements that are also used by PROPFIND.  In particular the
1222	   request can include XML elements to request WebDAV properties to be
1223	   returned.  When that occurs the response should follow the same
1224	   behavior as PROPFIND with respect to the DAV:multistatus response
1225	   elements used to return specific property results.  For instance, a
1226	   request to retrieve the value of a property which does not exist is
1227	   an error and MUST be noted with a response XML element which contains
1228	   a 404 (Not Found) status value.

1230	   Support for the CALDAV:calendar-query REPORT is REQUIRED.

1232	   Marshalling:

1234	      The request body MUST be a CALDAV:calendar-query XML element as
1235	      defined in Section 9.4.

1237	      The response body for a successful request MUST be a DAV:
1238	      multistatus XML element (i.e., the response uses the same format
1239	      as the response for PROPFIND).  In the case where there are no
1240	      response elements, the returned DAV:multistatus XML element is
1241	      empty.

1243	      The response body for a successful CALDAV:calendar-query REPORT
1244	      request MUST contain a DAV:response element for each iCalendar
1245	      object that matched the search filter.  Calendar data is being
1246	      returned in the CALDAV:calendar-data XML element inside the DAV:
1247	      propstat XML element.

1249	   Preconditions:

1251	      (CALDAV:supported-calendar-data): The attributes "content-type"
1252	      and "version" of the CALDAV:calendar-data XML elements specify a
1253	      media type supported by the server for calendar object resources.

1255	      (CALDAV:valid-filter): The CALDAV:filter XML element specified in
1256	      the REPORT request MUST be valid.  For instance, a CALDAV:filter
1257	      cannot nest a <C:comp name="VEVENT"> element in a <C:comp
1258	      name="VTODO"> element, or a CALDAV:filter cannot nest a <C:time-
1259	      range start="..." end="..."> element in a <C:prop name="SUMMARY">
1260	      element.

1262	      (CALDAV:supported-filter): The CALDAV:comp-filter, CALDAV:prop-
1263	      filter and CALDAV:param-filter XML elements used in the CALDAV:
1264	      filter XML element in the REPORT request only makes reference to
1265	      components, properties and parameters on which queries are
1266	      supported by the server.  Servers SHOULD report the CALDAV:comp-
1267	      filter, CALDAV:prop-filter or CALDAV:param-filter for which it
1268	      does not provide support.

1270	            <!ELEMENT supported-filter (comp-filter*,
1271	                                        prop-filter*,
1272	                                        param-filter*)>

1274	      (CALDAV:valid-calendar-data): The time zone specified in the
1275	      REPORT request MUST be a valid iCalendar object containing a
1276	      single valid VTIMEZONE component.

1278	   Postconditions:

1280	      (DAV:number-of-matches-within-limits): The number of matching
1281	      calendar object resources must fall within server-specific,
1282	      predefined limits.  For example, this condition might be triggered
1283	      if a search specification would cause the return of an extremely
1284	      large number of responses.

1286	7.7.1.  Example: Partial retrieval of events by time range

1288	   In this example, the client requests the server to return specific
1289	   components and properties of the VEVENT components that overlap the
1290	   time range from January 4th, 2006 at 00:00:00 AM UTC to January 5th,
1291	   2006 at 00:00:00 AM UTC.  In addition the DAV:getetag property is
1292	   also requested and returned as part of the response.  Note that the
1293	   first calendar object returned is a recurring event whose first
1294	   instance lies outside of the requested time range, but whose third
1295	   instance does overlap the time range.  Note that due to the CALDAV:
1296	   calendar-data element restrictions, the DTSTAMP property in VEVENT
1297	   components has not been returned, and only the only property returned
1298	   in the VCALENDAR object is VERSION.

1300	   >> Request <<

1302	   REPORT /bernard/work/ HTTP/1.1
1303	   Host: cal.example.com
1304	   Depth: 1
1305	   Content-Type: application/xml; charset="utf-8"
1306	   Content-Length: xxxx

1308	   <?xml version="1.0" encoding="utf-8" ?>
1309	   <C:calendar-query xmlns:D="DAV:"
1310	                 xmlns:C="urn:ietf:params:xml:ns:caldav">
1311	     <D:prop>
1312	       <D:getetag/>
1313	       <C:calendar-data>
1314	         <C:comp name="VCALENDAR">
1315	           <C:prop name="VERSION"/>
1316	           <C:comp name="VEVENT">
1317	             <C:prop name="SUMMARY"/>
1318	             <C:prop name="UID"/>
1319	             <C:prop name="DTSTART"/>
1320	             <C:prop name="DTEND"/>
1321	             <C:prop name="DURATION"/>
1322	             <C:prop name="RRULE"/>
1323	             <C:prop name="RDATE"/>
1324	             <C:prop name="EXRULE"/>
1325	             <C:prop name="EXDATE"/>
1326	             <C:prop name="RECURRENCE-ID"/>
1327	           </C:comp>
1328	           <C:comp name="VTIMEZONE"/>
1329	         </C:comp>
1330	       </C:calendar-data/>
1331	     </D:prop>
1332	     <C:filter>
1333	       <C:comp-filter name="VCALENDAR">
1334	         <C:comp-filter name="VEVENT">
1335	           <C:time-range start="20060104T000000Z"
1336	                         end="20060105T000000Z"/>
1337	         </C:comp-filter>
1338	       </C:comp-filter>
1339	     </C:filter>
1340	   </C:calendar-query>

1342	   >> Response <<

1344	   HTTP/1.1 207 Multi-Status
1345	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1346	   Content-Type: application/xml; charset="utf-8"
1347	   Content-Length: xxxx
1348	   <?xml version="1.0" encoding="utf-8" ?>
1349	   <D:multistatus xmlns:D="DAV:"
1350	              xmlns:C="urn:ietf:params:xml:ns:caldav">
1351	     <D:response>
1352	       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
1353	       <D:propstat>
1354	         <D:prop>
1355	           <D:getetag>"fffff-abcd2"</D:getetag>
1356	           <C:calendar-data>BEGIN:VCALENDAR
1357	      VERSION:2.0
1358	      BEGIN:VTIMEZONE
1359	      LAST-MODIFIED:20040110T032845Z
1360	      TZID:US/Eastern
1361	      BEGIN:DAYLIGHT
1362	      DTSTART:20000404T020000
1363	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1364	      TZNAME:EDT
1365	      TZOFFSETFROM:-0500
1366	      TZOFFSETTO:-0400
1367	      END:DAYLIGHT
1368	      BEGIN:STANDARD
1369	      DTSTART:20001026T020000
1370	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1371	      TZNAME:EST
1372	      TZOFFSETFROM:-0400
1373	      TZOFFSETTO:-0500
1374	      END:STANDARD
1375	      END:VTIMEZONE
1376	      BEGIN:VEVENT
1377	      DTSTART;TZID=US/Eastern:20060102T120000
1378	      DURATION:PT1H
1379	      RRULE:FREQ=DAILY;COUNT=5
1380	      SUMMARY:Event #2
1381	      UID:00959BC664CA650E933C892C@example.com
1382	      END:VEVENT
1383	      BEGIN:VEVENT
1384	      DTSTART;TZID=US/Eastern:20060104T140000
1385	      DURATION:PT1H
1386	      RECURRENCE-ID;TZID=US/Eastern:20060104T120000
1387	      SUMMARY:Event #2 bis
1388	      UID:00959BC664CA650E933C892C@example.com
1389	      END:VEVENT
1390	      BEGIN:VEVENT
1391	      DTSTART;TZID=US/Eastern:20060106T140000
1392	      DURATION:PT1H
1393	      RECURRENCE-ID;TZID=US/Eastern:20060106T120000
1394	      SUMMARY:Event #2 bis bis
1395	      UID:00959BC664CA650E933C892C@example.com
1396	      END:VEVENT
1397	      END:VCALENDAR
1398	           </C:calendar-data>
1399	         </D:prop>
1400	         <D:status>HTTP/1.1 200 OK</D:status>
1401	       </D:propstat>
1402	     </D:response>
1403	     <D:response>
1404	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
1405	       <D:propstat>
1406	         <D:prop>
1407	           <D:getetag>"fffff-abcd3"</D:getetag>
1408	           <C:calendar-data>BEGIN:VCALENDAR
1409	      VERSION:2.0
1410	      PRODID:-//Example Corp.//CalDAV Client//EN
1411	      BEGIN:VTIMEZONE
1412	      LAST-MODIFIED:20040110T032845Z
1413	      TZID:US/Eastern
1414	      BEGIN:DAYLIGHT
1415	      DTSTART:20000404T020000
1416	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1417	      TZNAME:EDT
1418	      TZOFFSETFROM:-0500
1419	      TZOFFSETTO:-0400
1420	      END:DAYLIGHT
1421	      BEGIN:STANDARD
1422	      DTSTART:20001026T020000
1423	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1424	      TZNAME:EST
1425	      TZOFFSETFROM:-0400
1426	      TZOFFSETTO:-0500
1427	      END:STANDARD
1428	      END:VTIMEZONE
1429	      BEGIN:VEVENT
1430	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
1431	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
1432	      DTSTAMP:20060206T001220Z
1433	      DTSTART;TZID=US/Eastern:20060104T100000
1434	      DURATION:PT1H
1435	      LAST-MODIFIED:20060206T001330Z
1436	      ORGANIZER:mailto:cyrus@example.com
1437	      SEQUENCE:1
1438	      STATUS:TENTATIVE
1439	      SUMMARY:Event #3
1440	      UID:DC6C50A017428C5216A2F1CD@example.com
1441	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
1442	      END:VEVENT
1443	      END:VCALENDAR
1444	           </C:calendar-data>
1445	         </D:prop>
1446	         <D:status>HTTP/1.1 200 OK</D:status>
1447	       </D:propstat>
1448	     </D:response>
1449	   </D:multistatus>

1451	7.7.2.  Example: Partial retrieval of recurring events

1453	   In this example, the client requests the server to return VEVENT
1454	   components that overlap the time range from January 3rd, 2006 at 00:
1455	   00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC.  Use of the
1456	   CALDAV:limit-recurrence-set element causes the server to only return
1457	   overridden recurrence components that overlap the time range
1458	   specified in that element, or that affect other instances that
1459	   overlap the time range (e.g., in the case of a "THISANDFUTURE"
1460	   behavior).  In this example the first overridden component in the
1461	   matching resource is returned but the second one is not.

1463	   >> Request <<

1465	   REPORT /bernard/work/ HTTP/1.1
1466	   Host: cal.example.com
1467	   Depth: 1
1468	   Content-Type: application/xml; charset="utf-8"
1469	   Content-Length: xxxx

1471	   <?xml version="1.0" encoding="utf-8" ?>
1472	   <C:calendar-query xmlns:D="DAV:"
1473	                     xmlns:C="urn:ietf:params:xml:ns:caldav">
1474	     <D:prop>
1475	       <C:calendar-data>
1476	         <C:limit-recurrence-set start="20060103T000000Z"
1477	                                 end="20060105T000000Z"/>
1478	       </C:calendar-data>
1479	     </D:prop>
1480	     <C:filter>
1481	       <C:comp-filter name="VCALENDAR">
1482	         <C:comp-filter name="VEVENT">
1483	           <C:time-range start="20060103T000000Z"
1484	                         end="20060105T000000Z"/>
1485	         </C:comp-filter>
1486	       </C:comp-filter>
1487	     </C:filter>
1488	   </C:calendar-query>

1490	   >> Response <<
1491	   HTTP/1.1 207 Multi-Status
1492	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1493	   Content-Type: application/xml; charset="utf-8"
1494	   Content-Length: xxxx

1496	   <?xml version="1.0" encoding="utf-8" ?>
1497	   <D:multistatus xmlns:D="DAV:"
1498	              xmlns:C="urn:ietf:params:xml:ns:caldav">
1499	     <D:response>
1500	       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
1501	       <D:propstat>
1502	         <D:prop>
1503	           <D:getetag>"fffff-abcd2"</D:getetag>
1504	           <C:calendar-data>BEGIN:VCALENDAR
1505	      VERSION:2.0
1506	      PRODID:-//Example Corp.//CalDAV Client//EN
1507	      BEGIN:VTIMEZONE
1508	      LAST-MODIFIED:20040110T032845Z
1509	      TZID:US/Eastern
1510	      BEGIN:DAYLIGHT
1511	      DTSTART:20000404T020000
1512	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1513	      TZNAME:EDT
1514	      TZOFFSETFROM:-0500
1515	      TZOFFSETTO:-0400
1516	      END:DAYLIGHT
1517	      BEGIN:STANDARD
1518	      DTSTART:20001026T020000
1519	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1520	      TZNAME:EST
1521	      TZOFFSETFROM:-0400
1522	      TZOFFSETTO:-0500
1523	      END:STANDARD
1524	      END:VTIMEZONE
1525	      BEGIN:VEVENT
1526	      DTSTAMP:20060206T001121Z
1527	      DTSTART;TZID=US/Eastern:20060102T120000
1528	      DURATION:PT1H
1529	      RRULE:FREQ=DAILY;COUNT=5
1530	      SUMMARY:Event #2
1531	      UID:00959BC664CA650E933C892C@example.com
1532	      END:VEVENT
1533	      BEGIN:VEVENT
1534	      DTSTAMP:20060206T001121Z
1535	      DTSTART;TZID=US/Eastern:20060104T140000
1536	      DURATION:PT1H
1537	      RECURRENCE-ID;TZID=US/Eastern:20060104T120000
1538	      SUMMARY:Event #2 bis
1539	      UID:00959BC664CA650E933C892C@example.com
1540	      END:VEVENT
1541	      END:VCALENDAR
1542	           </C:calendar-data>
1543	         </D:prop>
1544	         <D:status>HTTP/1.1 200 OK</D:status>
1545	       </D:propstat>
1546	     </D:response>
1547	     <D:response>
1548	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
1549	       <D:propstat>
1550	         <D:prop>
1551	           <D:getetag>"fffff-abcd3"</D:getetag>
1552	           <C:calendar-data>BEGIN:VCALENDAR
1553	      VERSION:2.0
1554	      PRODID:-//Example Corp.//CalDAV Client//EN
1555	      BEGIN:VTIMEZONE
1556	      LAST-MODIFIED:20040110T032845Z
1557	      TZID:US/Eastern
1558	      BEGIN:DAYLIGHT
1559	      DTSTART:20000404T020000
1560	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1561	      TZNAME:EDT
1562	      TZOFFSETFROM:-0500
1563	      TZOFFSETTO:-0400
1564	      END:DAYLIGHT
1565	      BEGIN:STANDARD
1566	      DTSTART:20001026T020000
1567	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1568	      TZNAME:EST
1569	      TZOFFSETFROM:-0400
1570	      TZOFFSETTO:-0500
1571	      END:STANDARD
1572	      END:VTIMEZONE
1573	      BEGIN:VEVENT
1574	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
1575	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
1576	      DTSTAMP:20060206T001220Z
1577	      DTSTART;TZID=US/Eastern:20060104T100000
1578	      DURATION:PT1H
1579	      LAST-MODIFIED:20060206T001330Z
1580	      ORGANIZER:mailto:cyrus@example.com
1581	      SEQUENCE:1
1582	      STATUS:TENTATIVE
1583	      SUMMARY:Event #3
1584	      UID:DC6C50A017428C5216A2F1CD@example.com
1585	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
1586	      END:VEVENT
1587	      END:VCALENDAR
1588	           </C:calendar-data>
1589	         </D:prop>
1590	         <D:status>HTTP/1.1 200 OK</D:status>
1591	       </D:propstat>
1592	     </D:response>
1593	   </D:multistatus>

1595	7.7.3.  Example: Expanded retrieval of recurring events

1597	   In this example, the client requests the server to return VEVENT
1598	   components that overlap the time range from January 2nd, 2006 at 00:
1599	   00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC and to return
1600	   recurring calendar components expanded into individual recurrence
1601	   instance calendar components.  Use of the CALDAV:expand element
1602	   causes the server to only return overridden recurrence instances that
1603	   overlap the time range specified in that element.

1605	   >> Request <<

1607	   REPORT /bernard/work/ HTTP/1.1
1608	   Host: cal.example.com
1609	   Depth: 1
1610	   Content-Type: application/xml; charset="utf-8"
1611	   Content-Length: xxxx

1613	   <?xml version="1.0" encoding="utf-8" ?>
1614	   <C:calendar-query xmlns:D="DAV:"
1615	                     xmlns:C="urn:ietf:params:xml:ns:caldav">
1616	     <D:prop>
1617	       <C:calendar-data>
1618	         <C:expand start="20060103T000000Z"
1619	                                  end="20060105T000000Z"/>
1620	       </C:calendar-data>
1621	     </D:prop>
1622	     <C:filter>
1623	       <C:comp-filter name="VCALENDAR">
1624	         <C:comp-filter name="VEVENT">
1625	           <C:time-range start="20060103T000000Z"
1626	                         end="20060105T000000Z"/>
1627	         </C:comp-filter>
1628	       </C:comp-filter>
1629	     </C:filter>
1630	   </C:calendar-query>

1632	   >> Response <<

1634	   HTTP/1.1 207 Multi-Status
1635	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1636	   Content-Type: application/xml; charset="utf-8"
1637	   Content-Length: xxxx

1639	   <?xml version="1.0" encoding="utf-8" ?>
1640	   <D:multistatus xmlns:D="DAV:"
1641	              xmlns:C="urn:ietf:params:xml:ns:caldav">
1642	     <D:response>
1643	       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
1644	       <D:propstat>
1645	         <D:prop>
1646	           <D:getetag>"fffff-abcd2"</D:getetag>
1647	           <C:calendar-data>BEGIN:VCALENDAR
1648	      VERSION:2.0
1649	      PRODID:-//Example Corp.//CalDAV Client//EN
1650	      BEGIN:VEVENT
1651	      DTSTAMP:20060206T001121Z
1652	      DTSTART:20060103T170000
1653	      DURATION:PT1H
1654	      RECURRENCE-ID:20060103T170000
1655	      SUMMARY:Event #2
1656	      UID:00959BC664CA650E933C892C@example.com
1657	      END:VEVENT
1658	      BEGIN:VEVENT
1659	      DTSTAMP:20060206T001121Z
1660	      DTSTART:20060104T190000
1661	      DURATION:PT1H
1662	      RECURRENCE-ID:20060104T170000
1663	      SUMMARY:Event #2 bis
1664	      UID:00959BC664CA650E933C892C@example.com
1665	      END:VEVENT
1666	      END:VCALENDAR
1667	           </C:calendar-data>
1668	         </D:prop>
1669	         <D:status>HTTP/1.1 200 OK</D:status>
1670	       </D:propstat>
1671	     </D:response>
1672	     <D:response>
1673	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
1674	       <D:propstat>
1675	         <D:prop>
1676	           <D:getetag>"fffff-abcd3"</D:getetag>
1677	           <C:calendar-data>BEGIN:VCALENDAR
1678	      VERSION:2.0
1679	      PRODID:-//Example Corp.//CalDAV Client//EN
1680	      BEGIN:VEVENT
1681	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
1682	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
1683	      DTSTAMP:20060206T001220Z
1684	      DTSTART:20060104T150000
1685	      DURATION:PT1H
1686	      LAST-MODIFIED:20060206T001330Z
1687	      ORGANIZER:mailto:cyrus@example.com
1688	      SEQUENCE:1
1689	      STATUS:TENTATIVE
1690	      SUMMARY:Event #3
1691	      UID:DC6C50A017428C5216A2F1CD@example.com
1692	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
1693	      END:VEVENT
1694	      END:VCALENDAR
1695	           </C:calendar-data>
1696	         </D:prop>
1697	         <D:status>HTTP/1.1 200 OK</D:status>
1698	       </D:propstat>
1699	     </D:response>
1700	   </D:multistatus>

1702	7.7.4.  Example: Partial retrieval of stored free busy components

1704	   In this example, the client requests the server to return the
1705	   VFREEBUSY components that have free busy information that overlap the
1706	   time range from January 2nd, 2006 at 00:00:00 AM UTC (inclusively) to
1707	   January 3rd, 2006 at 00:00:00 AM UTC (exclusively).  Use of the
1708	   CALDAV:limit-freebusy-set element causes the server to only return
1709	   the FREEBUSY property values that overlap the time range specified in
1710	   that element.  Note that this is not an example of discovering when
1711	   the calendar owner is busy.

1713	   >> Request <<

1715	   REPORT /bernard/work/ HTTP/1.1
1716	   Host: cal.example.com
1717	   Depth: 1
1718	   Content-Type: application/xml; charset="utf-8"
1719	   Content-Length: xxxx

1721	   <?xml version="1.0" encoding="utf-8" ?>
1722	   <C:calendar-query xmlns:D="DAV:"
1723	                 xmlns:C="urn:ietf:params:xml:ns:caldav">
1724	     <D:prop>
1725	       <C:calendar-data>
1726	         <C:limit-freebusy-set start="20060102T000000Z"
1727	                                 end="20060103T000000Z"/>
1728	       </C:calendar-data>
1729	     </D:prop>
1730	     <C:filter>
1731	       <C:comp-filter name="VCALENDAR">
1732	         <C:comp-filter name="VFREEBUSY">
1733	           <C:time-range start="20060102T000000Z"
1734	                           end="20060103T000000Z"/>
1735	         </C:comp-filter>
1736	       </C:comp-filter>
1737	     </C:filter>
1738	   </C:calendar-query>
1739	   >> Response <<

1741	   HTTP/1.1 207 Multi-Status
1742	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1743	   Content-Type: application/xml; charset="utf-8"
1744	   Content-Length: xxxx

1746	   <?xml version="1.0" encoding="utf-8" ?>
1747	   <D:multistatus xmlns:D="DAV:"
1748	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
1749	     <D:response>
1750	       <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
1751	       <D:propstat>
1752	         <D:prop>
1753	           <D:getetag>"fffff-abcd6"</D:getetag>
1754	           <C:calendar-data>BEGIN:VCALENDAR
1755	      VERSION:2.0
1756	      PRODID:-//Example Corp.//CalDAV Client//EN
1757	      BEGIN:VFREEBUSY
1758	      ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
1759	      UID:76ef34-54a3d2@example.com
1760	      DTSTAMP:20050530T123421Z
1761	      DTSTART:20060101T100000Z
1762	      DTEND:20060108T100000Z
1763	      FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
1764	      END:VFREEBUSY
1765	      END:VCALENDAR
1766	           </C:calendar-data>
1767	         </D:prop>
1768	         <D:status>HTTP/1.1 200 OK</D:status>
1769	       </D:propstat>
1770	     </D:response>
1771	   </D:multistatus>

1773	7.7.5.  Example: Retrieval of to-dos by alarm time range

1775	   In this example, the client requests the server to return the VTODO
1776	   components that have an alarm trigger scheduled in the specified time
1777	   range.

1779	   >> Request <<

1781	   REPORT /bernard/work/ HTTP/1.1
1782	   Host: cal.example.com
1783	   Depth: 1
1784	   Content-Type: application/xml; charset="utf-8"
1785	   Content-Length: xxxx

1787	   <?xml version="1.0" encoding="utf-8" ?>
1788	   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
1789	     <D:prop xmlns:D="DAV:">
1790	       <D:getetag/>
1791	       <C:calendar-data/>
1792	     </D:prop>
1793	     <C:filter>
1794	       <C:comp-filter name="VCALENDAR">
1795	         <C:comp-filter name="VTODO">
1796	           <C:comp-filter name="VALARM">
1797	             <C:time-range start="20060106T100000Z"
1798	                             end="20060107T100000Z"/>
1799	           </C:comp-filter>
1800	         </C:comp-filter>
1801	       </C:comp-filter>
1802	     </C:filter>
1803	   </C:calendar-query>
1804	   >> Response <<

1806	   HTTP/1.1 207 Multi-Status
1807	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1808	   Content-Type: application/xml; charset="utf-8"
1809	   Content-Length: xxxx

1811	   <?xml version="1.0" encoding="utf-8" ?>
1812	   <D:multistatus xmlns:D="DAV:"
1813	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
1814	     <D:response>
1815	       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
1816	       <D:propstat>
1817	         <D:prop>
1818	           <D:getetag>"fffff-abcd4"</D:getetag>
1819	           <C:calendar-data>BEGIN:VCALENDAR
1820	      VERSION:2.0
1821	      PRODID:-//Example Corp.//CalDAV Client//EN
1822	      BEGIN:VTODO
1823	      DTSTAMP:20060205T235300Z
1824	      DUE;TZID=US/Eastern:20060106T120000
1825	      LAST-MODIFIED:20060205T235308Z
1826	      SEQUENCE:1
1827	      STATUS:NEEDS-ACTION
1828	      SUMMARY:Task #2
1829	      UID:E10BA47467C5C69BB74E8720@example.com
1830	      BEGIN:VALARM
1831	      ACTION:AUDIO
1832	      TRIGGER;RELATED=START:-PT10M
1833	      END:VALARM
1834	      END:VTODO
1835	      END:VCALENDAR
1836	           </C:calendar-data>
1837	         </D:prop>
1838	         <D:status>HTTP/1.1 200 OK</D:status>
1839	       </D:propstat>
1840	     </D:response>
1841	   </D:multistatus>

1843	7.7.6.  Example: Retrieval of event by UID

1845	   In this example, the client requests the server to return the VEVENT
1846	   component that has the UID property set to
1847	   "DC6C50A017428C5216A2F1CD@example.com".

1849	   >> Request <<

1851	   REPORT /bernard/work/ HTTP/1.1
1852	   Host: cal.example.com
1853	   Depth: 1
1854	   Content-Type: application/xml; charset="utf-8"
1855	   Content-Length: xxxx

1857	   <?xml version="1.0" encoding="utf-8" ?>
1858	   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
1859	     <D:prop xmlns:D="DAV:">
1860	       <D:getetag/>
1861	       <C:calendar-data/>
1862	     </D:prop>
1863	     <C:filter>
1864	       <C:comp-filter name="VCALENDAR">
1865	         <C:comp-filter name="VEVENT">
1866	           <C:prop-filter name="UID">
1867	             <C:text-match caseless="no">
1868	              DC6C50A017428C5216A2F1CD@example.com</C:text-match>
1869	           </C:prop-filter>
1870	         </C:comp-filter>
1871	       </C:comp-filter>
1872	     </C:filter>
1873	   </C:calendar-query>

1875	   >> Response <<

1877	   HTTP/1.1 207 Multi-Status
1878	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1879	   Content-Type: application/xml; charset="utf-8"
1880	   Content-Length: xxxx

1882	   <?xml version="1.0" encoding="utf-8" ?>
1883	   <D:multistatus xmlns:D="DAV:"
1884	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
1885	     <D:response>
1886	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
1887	       <D:propstat>
1888	         <D:prop>
1889	           <D:getetag>"fffff-abcd3"</D:getetag>
1890	           <C:calendar-data>BEGIN:VCALENDAR
1891	      VERSION:2.0
1892	      PRODID:-//Example Corp.//CalDAV Client//EN
1893	      BEGIN:VTIMEZONE
1894	      LAST-MODIFIED:20040110T032845Z
1895	      TZID:US/Eastern
1896	      BEGIN:DAYLIGHT
1897	      DTSTART:20000404T020000
1898	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1899	      TZNAME:EDT
1900	      TZOFFSETFROM:-0500
1901	      TZOFFSETTO:-0400
1902	      END:DAYLIGHT
1903	      BEGIN:STANDARD
1904	      DTSTART:20001026T020000
1905	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1906	      TZNAME:EST
1907	      TZOFFSETFROM:-0400
1908	      TZOFFSETTO:-0500
1909	      END:STANDARD
1910	      END:VTIMEZONE
1911	      BEGIN:VEVENT
1912	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
1913	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
1914	      DTSTAMP:20060206T001220Z
1915	      DTSTART;TZID=US/Eastern:20060104T100000
1916	      DURATION:PT1H
1917	      LAST-MODIFIED:20060206T001330Z
1918	      ORGANIZER:mailto:cyrus@example.com
1919	      SEQUENCE:1
1920	      STATUS:TENTATIVE
1921	      SUMMARY:Event #3
1922	      UID:DC6C50A017428C5216A2F1CD@example.com
1923	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
1924	      END:VEVENT
1925	      END:VCALENDAR
1926	           </C:calendar-data>
1927	         </D:prop>
1928	         <D:status>HTTP/1.1 200 OK</D:status>
1929	       </D:propstat>
1930	     </D:response>
1931	   </D:multistatus>

1933	7.7.7.  Example: Retrieval of events by PARTSTAT

1935	   In this example, the client requests the server to return the VEVENT
1936	   components that have the ATTENDEE property with the value
1937	   "mailto:lisa@example.com" and for which the PARTSTAT parameter is set
1938	   to "NEEDS-ACTION".

1940	   >> Request <<

1942	   REPORT /bernard/work/ HTTP/1.1
1943	   Host: cal.example.com
1944	   Depth: 1
1945	   Content-Type: application/xml; charset="utf-8"
1946	   Content-Length: xxxx

1948	   <?xml version="1.0" encoding="utf-8" ?>
1949	   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
1950	     <D:prop xmlns:D="DAV:">
1951	       <D:getetag/>
1952	       <C:calendar-data/>
1953	     </D:prop>
1954	     <C:filter>
1955	       <C:comp-filter name="VCALENDAR">
1956	         <C:comp-filter name="VEVENT">
1957	           <C:prop-filter name="ATTENDEE">
1958	             <C:text-match
1959	               caseless="yes">mailto:lisa@example.com</C:text-match>
1960	             <C:param-filter name="PARTSTAT">
1961	               <C:text-match caseless="yes">NEEDS-ACTION</C:text-match>
1962	             </C:param-filter>
1963	           </C:prop-filter>
1964	         </C:comp-filter>
1965	       </C:comp-filter>
1966	     </C:filter>
1967	   </C:calendar-query>

1969	   >> Response <<

1971	   HTTP/1.1 207 Multi-Status
1972	   Date: Fri, 11 Nov 2005 09:32:12 GMT
1973	   Content-Type: application/xml; charset="utf-8"
1974	   Content-Length: xxxx

1976	   <?xml version="1.0" encoding="utf-8" ?>
1977	   <D:multistatus xmlns:D="DAV:"
1978	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
1979	     <D:response>
1980	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
1981	       <D:propstat>
1982	         <D:prop>
1983	           <D:getetag>"fffff-abcd3"</D:getetag>
1984	           <C:calendar-data>BEGIN:VCALENDAR
1985	      VERSION:2.0
1986	      PRODID:-//Example Corp.//CalDAV Client//EN
1987	      BEGIN:VTIMEZONE
1988	      LAST-MODIFIED:20040110T032845Z
1989	      TZID:US/Eastern
1990	      BEGIN:DAYLIGHT
1991	      DTSTART:20000404T020000
1992	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1993	      TZNAME:EDT
1994	      TZOFFSETFROM:-0500
1995	      TZOFFSETTO:-0400
1996	      END:DAYLIGHT
1997	      BEGIN:STANDARD
1998	      DTSTART:20001026T020000
1999	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2000	      TZNAME:EST
2001	      TZOFFSETFROM:-0400
2002	      TZOFFSETTO:-0500
2003	      END:STANDARD
2004	      END:VTIMEZONE
2005	      BEGIN:VEVENT
2006	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
2007	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
2008	      DTSTAMP:20060206T001220Z
2009	      DTSTART;TZID=US/Eastern:20060104T100000
2010	      DURATION:PT1H
2011	      LAST-MODIFIED:20060206T001330Z
2012	      ORGANIZER:mailto:cyrus@example.com
2013	      SEQUENCE:1
2014	      STATUS:TENTATIVE
2015	      SUMMARY:Event #3
2016	      UID:DC6C50A017428C5216A2F1CD@example.com
2017	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
2018	      END:VEVENT
2019	      END:VCALENDAR
2020	           </C:calendar-data>
2021	         </D:prop>
2022	         <D:status>HTTP/1.1 200 OK</D:status>
2023	       </D:propstat>
2024	     </D:response>
2025	   </D:multistatus>

2027	7.7.8.  Example: Retrieval of events only

2029	   In this example, the client requests the server to return all VEVENT
2030	   components.

2032	   >> Request <<

2034	   REPORT /bernard/work/ HTTP/1.1
2035	   Host: cal.example.com
2036	   Depth: 1
2037	   Content-Type: application/xml; charset="utf-8"
2038	   Content-Length: xxxx

2040	   <?xml version="1.0" encoding="utf-8" ?>
2041	   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2042	     <D:prop xmlns:D="DAV:">
2043	       <D:getetag/>
2044	       <C:calendar-data/>
2045	     </D:prop>
2046	     <C:filter>
2047	       <C:comp-filter name="VCALENDAR">
2048	         <C:comp-filter name="VEVENT"/>
2049	       </C:comp-filter>
2050	     </C:filter>
2051	   </C:calendar-query>

2053	   >> Response <<

2055	   HTTP/1.1 207 Multi-Status
2056	   Date: Fri, 11 Nov 2005 09:32:12 GMT
2057	   Content-Type: application/xml; charset="utf-8"
2058	   Content-Length: xxxx

2060	   <?xml version="1.0" encoding="utf-8" ?>
2061	   <D:multistatus xmlns:D="DAV:"
2062	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
2063	     <D:response>
2064	       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
2065	       <D:propstat>
2066	         <D:prop>
2067	           <D:getetag>"fffff-abcd1"</D:getetag>
2068	           <C:calendar-data>BEGIN:VCALENDAR
2069	      VERSION:2.0
2070	      PRODID:-//Example Corp.//CalDAV Client//EN
2071	      BEGIN:VTIMEZONE
2072	      LAST-MODIFIED:20040110T032845Z
2073	      TZID:US/Eastern
2074	      BEGIN:DAYLIGHT
2075	      DTSTART:20000404T020000
2076	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2077	      TZNAME:EDT
2078	      TZOFFSETFROM:-0500
2079	      TZOFFSETTO:-0400
2080	      END:DAYLIGHT
2081	      BEGIN:STANDARD
2082	      DTSTART:20001026T020000
2083	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2084	      TZNAME:EST
2085	      TZOFFSETFROM:-0400
2086	      TZOFFSETTO:-0500
2087	      END:STANDARD
2088	      END:VTIMEZONE
2089	      BEGIN:VEVENT
2090	      DTSTAMP:20060206T001102Z
2091	      DTSTART;TZID=US/Eastern:20060102T100000
2092	      DURATION:PT1H
2093	      SUMMARY:Event #1
2094	      Description:Go Steelers!
2095	      UID:74855313FA803DA593CD579A@example.com
2096	      END:VEVENT
2097	      END:VCALENDAR
2098	           </C:calendar-data>
2099	         </D:prop>
2100	         <D:status>HTTP/1.1 200 OK</D:status>
2101	       </D:propstat>
2102	     </D:response>
2103	     <D:response>
2104	       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
2105	       <D:propstat>
2106	         <D:prop>
2107	           <D:getetag>"fffff-abcd2"</D:getetag>
2108	           <C:calendar-data>BEGIN:VCALENDAR
2109	      VERSION:2.0
2110	      PRODID:-//Example Corp.//CalDAV Client//EN
2111	      BEGIN:VTIMEZONE
2112	      LAST-MODIFIED:20040110T032845Z
2113	      TZID:US/Eastern
2114	      BEGIN:DAYLIGHT
2115	      DTSTART:20000404T020000
2116	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2117	      TZNAME:EDT
2118	      TZOFFSETFROM:-0500
2119	      TZOFFSETTO:-0400
2120	      END:DAYLIGHT
2121	      BEGIN:STANDARD
2122	      DTSTART:20001026T020000
2123	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2124	      TZNAME:EST
2125	      TZOFFSETFROM:-0400
2126	      TZOFFSETTO:-0500
2127	      END:STANDARD
2128	      END:VTIMEZONE
2129	      BEGIN:VEVENT
2130	      DTSTAMP:20060206T001121Z
2131	      DTSTART;TZID=US/Eastern:20060102T120000
2132	      DURATION:PT1H
2133	      RRULE:FREQ=DAILY;COUNT=5
2134	      SUMMARY:Event #2
2135	      UID:00959BC664CA650E933C892C@example.com
2136	      END:VEVENT
2137	      BEGIN:VEVENT
2138	      DTSTAMP:20060206T001121Z
2139	      DTSTART;TZID=US/Eastern:20060104T140000
2140	      DURATION:PT1H
2141	      RECURRENCE-ID;TZID=US/Eastern:20060104T120000
2142	      SUMMARY:Event #2 bis
2143	      UID:00959BC664CA650E933C892C@example.com
2144	      END:VEVENT
2145	      BEGIN:VEVENT
2146	      DTSTAMP:20060206T001121Z
2147	      DTSTART;TZID=US/Eastern:20060106T140000
2148	      DURATION:PT1H
2149	      RECURRENCE-ID;TZID=US/Eastern:20060106T120000
2150	      SUMMARY:Event #2 bis bis
2151	      UID:00959BC664CA650E933C892C@example.com
2152	      END:VEVENT
2153	      END:VCALENDAR
2154	           </C:calendar-data>
2155	         </D:prop>
2156	         <D:status>HTTP/1.1 200 OK</D:status>
2157	       </D:propstat>
2158	     </D:response>
2159	     <D:response>
2160	       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
2161	       <D:propstat>
2162	         <D:prop>
2163	           <D:getetag>"fffff-abcd3"</D:getetag>
2164	           <C:calendar-data>BEGIN:VCALENDAR
2165	      VERSION:2.0
2166	      PRODID:-//Example Corp.//CalDAV Client//EN
2167	      BEGIN:VTIMEZONE
2168	      LAST-MODIFIED:20040110T032845Z
2169	      TZID:US/Eastern
2170	      BEGIN:DAYLIGHT
2171	      DTSTART:20000404T020000
2172	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2173	      TZNAME:EDT
2174	      TZOFFSETFROM:-0500
2175	      TZOFFSETTO:-0400
2176	      END:DAYLIGHT
2177	      BEGIN:STANDARD
2178	      DTSTART:20001026T020000
2179	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2180	      TZNAME:EST
2181	      TZOFFSETFROM:-0400
2182	      TZOFFSETTO:-0500
2183	      END:STANDARD
2184	      END:VTIMEZONE
2185	      BEGIN:VEVENT
2186	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
2187	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
2188	      DTSTAMP:20060206T001220Z
2189	      DTSTART;TZID=US/Eastern:20060104T100000
2190	      DURATION:PT1H
2191	      LAST-MODIFIED:20060206T001330Z
2192	      ORGANIZER:mailto:cyrus@example.com
2193	      SEQUENCE:1
2194	      STATUS:TENTATIVE
2195	      SUMMARY:Event #3
2196	      UID:DC6C50A017428C5216A2F1CD@example.com
2197	      X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
2198	      END:VEVENT
2199	      END:VCALENDAR
2200	           </C:calendar-data>
2201	         </D:prop>
2202	         <D:status>HTTP/1.1 200 OK</D:status>
2203	       </D:propstat>
2204	     </D:response>
2205	   </D:multistatus>

2207	7.7.9.  Example: Attempt to query unsupported property

2209	   In this example, the client requests the server to return all VEVENT
2210	   components that include an "X-ABC-GUID" property with a value
2211	   matching "ABC".  However, the server does not support querying that
2212	   non-standard property and instead returns and error response.

2214	   >> Request <<

2216	   REPORT /bernard/work/ HTTP/1.1
2217	   Host: cal.example.com
2218	   Depth: 1
2219	   Content-Type: application/xml; charset="utf-8"
2220	   Content-Length: xxxx

2222	   <?xml version="1.0" encoding="utf-8" ?>
2223	   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2224	     <D:prop xmlns:D="DAV:">
2225	       <D:getetag/>
2226	       <C:calendar-data/>
2227	     </D:prop>
2228	     <C:filter>
2229	       <C:comp-filter name="VCALENDAR">
2230	         <C:comp-filter name="VEVENT">
2231	           <C:prop-filter name="X-ABC-GUID">
2232	             <C:text-match>ABC</C:text-match>
2233	           </C:prop-filter>
2234	         </C:comp-filter>
2235	       </C:comp-filter>
2236	     </C:filter>
2237	   </C:calendar-query>

2239	   >> Response <<

2241	   HTTP/1.1 400 Bad Request
2242	   Date: Fri, 11 Nov 2005 09:32:12 GMT
2243	   Content-Type: application/xml; charset="utf-8"
2244	   Content-Length: xxxx

2246	   <?xml version="1.0" encoding="utf-8" ?>
2247	   <D:error>
2248	     <C:supported-filter>
2249	       <C:prop-filter name="X-ABC-GUID"/>
2250	     </C:supported-filter>
2251	   </D:error>

2253	7.8.  CALDAV:calendar-multiget Report

2255	   The CALDAV:calendar-multiget REPORT is used to retrieve specific
2256	   calendar object resources from within a collection, if the Request-
2257	   URI is a collection, or to retrieve a specific calendar object
2258	   resource, if the Request-URI is a calendar object resource.  This
2259	   REPORT is similar to the CALDAV:calendar-query REPORT (see
2260	   Section 7.7), except that it takes a list of DAV:href elements
2261	   instead of a CALDAV:filter element to determine which calendar object
2262	   resources to return.

2264	   Support for the calendar-multiget REPORT is REQUIRED.

2266	   Marshalling:

2268	      The request body MUST be a CALDAV:calendar-multiget XML element
2269	      (see Section 9.9).  If the Request-URI is a collection resource,
2270	      then the DAV:href elements MUST refer to resources within that
2271	      collection, and they MAY refer to resources at any depth within
2272	      the collection.  As a result the "Depth" header MUST be ignored by
2273	      the server and SHOULD NOT be sent by the client.  If the Request-
2274	      URI refers to a non-collection resource, then there MUST be a
2275	      single DAV:href element that is equivalent to the Request-URI.

2277	      The response body for a successful request MUST be a DAV:
2278	      multistatus XML element.

2280	      The response body for a successful CALDAV:calendar-multiget REPORT
2281	      request MUST contain a DAV:response element for each calendar
2282	      object resource referenced by the provided set of DAV:href
2283	      elements.  Calendar data is being returned in the CALDAV:calendar-
2284	      data element inside the DAV:prop element.

2286	      In the case of an error accessing any of the provided DAV:href
2287	      resources, the server MUST return the appropriate error status
2288	      code in the DAV:status element of the corresponding DAV:response
2289	      element.

2291	   Preconditions:

2293	      (CALDAV:supported-calendar-data): The attributes "content-type"
2294	      and "version" of the CALDAV:calendar-data XML elements specify a
2295	      media type supported by the server for calendar object resources.

2297	   Postconditions:

2299	      None.

2301	7.8.1.  Example: Successful CALDAV:calendar-multiget Report

2303	   In this example, the client requests the server to return specific
2304	   properties of the VEVENT components referenced by specific URIs.  In
2305	   addition the DAV:getetag property is also requested and returned as
2306	   part of the response.  Note that in this example, the resource at
2307	   http://cal.example.com/bernard/work/mtg1.ics does not exist,
2308	   resulting in an error status response.

2310	   >> Request <<

2312	   REPORT /bernard/work/ HTTP/1.1
2313	   Host: cal.example.com
2314	   Content-Type: application/xml; charset="utf-8"
2315	   Content-Length: xxxx

2317	   <?xml version="1.0" encoding="utf-8" ?>
2318	   <C:calendar-multiget xmlns:D="DAV:"
2319	                    xmlns:C="urn:ietf:params:xml:ns:caldav">
2320	     <D:prop>
2321	       <D:getetag/>
2322	       <C:calendar-data/>
2323	     </D:prop>
2324	     <D:href>/bernard/work/abcd1.ics</D:href>
2325	     <D:href>/bernard/work/mtg1.ics</D:href>
2326	   </C:calendar-multiget>

2328	   >> Response <<

2330	   HTTP/1.1 207 Multi-Status
2331	   Date: Fri, 11 Nov 2005 09:32:12 GMT
2332	   Content-Type: application/xml; charset="utf-8"
2333	   Content-Length: xxxx

2335	   <?xml version="1.0" encoding="utf-8" ?>
2336	   <D:multistatus xmlns:D="DAV:"
2337	                  xmlns:C="urn:ietf:params:xml:ns:caldav">
2338	     <D:response>
2339	       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
2340	       <D:propstat>
2341	         <D:prop>
2342	           <D:getetag>"fffff-abcd1"</D:getetag>
2343	           <C:calendar-data>BEGIN:VCALENDAR
2344	      VERSION:2.0
2345	      PRODID:-//Example Corp.//CalDAV Client//EN
2346	      BEGIN:VTIMEZONE
2347	      LAST-MODIFIED:20040110T032845Z
2348	      TZID:US/Eastern
2349	      BEGIN:DAYLIGHT
2350	      DTSTART:20000404T020000
2351	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2352	      TZNAME:EDT
2353	      TZOFFSETFROM:-0500
2354	      TZOFFSETTO:-0400
2355	      END:DAYLIGHT
2356	      BEGIN:STANDARD
2357	      DTSTART:20001026T020000
2358	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2359	      TZNAME:EST
2360	      TZOFFSETFROM:-0400
2361	      TZOFFSETTO:-0500
2362	      END:STANDARD
2363	      END:VTIMEZONE
2364	      BEGIN:VEVENT
2365	      DTSTAMP:20060206T001102Z
2366	      DTSTART;TZID=US/Eastern:20060102T100000
2367	      DURATION:PT1H
2368	      SUMMARY:Event #1
2369	      Description:Go Steelers!
2370	      UID:74855313FA803DA593CD579A@example.com
2371	      END:VEVENT
2372	      END:VCALENDAR
2373	           </C:calendar-data>
2374	         </D:prop>
2375	         <D:status>HTTP/1.1 200 OK</D:status>
2376	       </D:propstat>
2377	     </D:response>
2378	     <D:response>
2379	       <D:href>http://cal.example.com/bernard/work/mtg1.ics</D:href>
2380	       <D:status>HTTP/1.1 404 Not Found</D:status>
2381	     </D:response>
2382	   </D:multistatus>

2384	7.9.  CALDAV:free-busy-query Report

2386	   The CALDAV:free-busy-query REPORT generates a VFREEBUSY component
2387	   containing free busy information for all the calendar object
2388	   resources targeted by the request and which have the CALDAV:read-
2389	   free-busy or DAV:read privilege granted to the current user.

2391	   Only VEVENT components without a TRANSP property or with the TRANSP
2392	   property set to "OPAQUE", and VFREEBUSY components SHOULD be
2393	   considered to generate the free busy time information.

2395	   In the case of VEVENT components, the free or busy time type (FBTYPE)
2396	   of the FREEBUSY properties in the returned VFREEBUSY component SHOULD
2397	   be derived from the value of the TRANSP and STATUS properties as
2398	   outlined in the table below:

2400	         +---------------------------++------------------+
2401	         |          VEVENT           ||    VFREEBUSY     |
2402	         +-------------+-------------++------------------+
2403	         | TRANSP      | STATUS      || FBTYPE           |
2404	         +=============+=============++==================+
2405	         |             | CONFIRMED   || BUSY             |
2406	         |             | (default)   ||                  |
2407	         | OPAQUE      +-------------++------------------+
2408	         | (default)   | CANCELLED   || FREE             |
2409	         |             +-------------++------------------+
2410	         |             | TENTATIVE   || BUSY-TENTATIVE   |
2411	         |             +-------------++------------------+
2412	         |             | x-name      || BUSY or          |
2413	         |             |             || x-name           |
2414	         +-------------+-------------++------------------+
2415	         |             | CONFIRMED   ||                  |
2416	         | TRANSPARENT | CANCELLED   || FREE             |
2417	         |             | TENTATIVE   ||                  |
2418	         |             | x-name      ||                  |
2419	         +-------------+-------------++------------------+

2421	   Duplicate busy time periods with the same FBTYPE parameter value
2422	   SHOULD NOT be specified in the returned VFREEBUSY component.  Servers
2423	   SHOULD coalesce consecutive or overlapping busy time period of the
2424	   same type.  Busy time periods with different FBTYPE parameter values
2425	   MAY overlap.

2427	   Support for the CALDAV:free-busy-query REPORT is REQUIRED.

2429	   Marshalling:

2431	      The request body MUST be a CALDAV:free-busy-query XML element (see
2432	      Section 9.10, which MUST contain exactly one CALDAV:time-range XML
2433	      element, as defined in Section 9.8.

2435	      The request MAY include a Depth header.  If no Depth header is
2436	      included, Depth:0 is assumed.

2438	      The response body for a successful request MUST be an iCalendar
2439	      object that contains exactly one VFREEBUSY component that
2440	      describes the busy time intervals for the calendar object
2441	      resources containing VEVENT or VFREEBUSY components that satisfy
2442	      the Depth value and for which the current user is at least granted
2443	      the CALDAV:read-free-busy privilege.  If no calendar object
2444	      resources are found to satisfy these conditions a VFREEBUSY
2445	      component with no FREEBUSY property MUST be returned.  This REPORT
2446	      only returns busy time information.  Free time information can be
2447	      inferred from the returned busy time information.

2449	      If the current user is not granted the CALDAV:read-free-busy or
2450	      DAV:read privileges on the Request-URI, the CALDAV:free-busy-query
2451	      REPORT request MUST fail and return a 404 (Not Found) status
2452	      value.  This restriction will prevent users from discovering URLs
2453	      of resources for which they are only granted the CALDAV:read-free-
2454	      busy privilege.

2456	      The CALDAV:free-busy-query REPORT request can only be run against
2457	      a collection (either a regular collection or a calendar
2458	      collection).  An attempt to run the report on a calendar object
2459	      resource MUST fail and return a 403 (Forbidden) status value.

2461	   Preconditions:

2463	      None.

2465	   Postconditions:

2467	      (DAV:number-of-matches-within-limits): The number of matching
2468	      calendar object resources must fall within server-specific,
2469	      predefined limits.  For example, this postcondition might fail if
2470	      the specified CALDAV:time-range would cause an extremely large
2471	      number calendar object resources to be considered to compute the
2472	      response.

2474	7.9.1.  Example: Successful CALDAV:free-busy-query Report

2476	   In this example, the client requests the server to return free busy
2477	   information on the calendar collection /bernard/work/, between 9:00
2478	   AM and 5:00 PM EST (2:00 PM and 10:00 PM UTC) on the 4th January
2479	   2006.  The server responds indicating two busy time intervals of one
2480	   hour, one of which is tentative.

2482	   >> Request <<

2484	   REPORT /bernard/work/ HTTP/1.1
2485	   Host: cal.example.com
2486	   Depth: 1
2487	   Content-Type: application/xml; charset="utf-8"
2488	   Content-Length: xxxx

2490	   <?xml version="1.0" encoding="utf-8" ?>
2491	   <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2492	     <C:time-range start="20060104T140000Z"
2493	                     end="20060105T220000Z"/>
2494	   </C:free-busy-query>
2495	   >> Response <<

2497	   HTTP/1.1 200 OK
2498	   Date: Fri, 11 Nov 2005 09:32:12 GMT
2499	   Content-Type: text/calendar
2500	   Content-Length: xxxx

2502	   BEGIN:VCALENDAR
2503	   VERSION:2.0
2504	   PRODID:-//Example Corp.//CalDAV Server//EN
2505	   BEGIN:VFREEBUSY
2506	   DTSTAMP:20050125T090000Z
2507	   DTSTART:20060104T140000Z
2508	   DTEND:20060105T220000Z
2509	   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
2510	   FREEBUSY:20060104T190000Z/PT1H
2511	   END:VFREEBUSY
2512	   END:VCALENDAR

2514	8.  Guidelines

2516	8.1.  Client-to-client Interoperability

2518	   There are a number of actions clients can take which will be legal
2519	   (the server will not return errors) but which can degrade
2520	   interoperability with other client implementations accessing the same
2521	   data.  For example, a recurrence rule could be replaced with a set of
2522	   recurrence dates, a single recurring event could be replaced with a
2523	   set of independent resources to represent each recurrence, or the
2524	   start/end time values can be translated from the original time zone
2525	   to another time zone.  Although this advice amounts to iCalendar
2526	   interoperability best practices and is not limited only to CalDAV
2527	   usage, interoperability problems are likely to be more evident in
2528	   CalDAV use cases.

2530	8.2.  Synchronization Operations

2532	   WebDAV already provides functionality required to synchronize a
2533	   collection or set of collections, make changes offline, and a simple
2534	   way to resolve conflicts when reconnected.  ETags are the key to
2535	   making this work, but these are not required of all WebDAV servers.
2536	   Since offline functionality is more important to calendar
2537	   applications than to some other WebDAV applications, CalDAV servers
2538	   MUST support ETags as specified in Section 5.3.4.

2540	8.2.1.  Use of Reports

2542	8.2.1.1.  Restrict the Time Range

2544	   The REPORTs provided in CalDAV can be used by clients to optimize
2545	   their performance in terms of network bandwidth usage, and resource
2546	   consumption on the local client machine.  Both are certainly major
2547	   considerations for mobile or handheld devices with limited capacity,
2548	   but they are also relevant to desktop client applications in cases
2549	   where the calendar collections contain large amounts of data.

2551	   Typically clients present calendar data to users in views that span a
2552	   finite time interval, so whenever possible clients should only
2553	   retrieve calendar components from the server using CALDAV:calendar-
2554	   query REPORT combined with a CALDAV:time-range element to limit the
2555	   set of returned components to just those needed to populate the
2556	   current view.

2558	8.2.1.2.  Synchronize by Time Range

2560	   Typically in a calendar, historical data (events, to-dos etc. that
2561	   have completed prior to the current date) do not change, though they
2562	   may be deleted.  As a result, a client can speed up the
2563	   synchronization process by only considering data for the present time
2564	   and the future up to a reasonable limit (e.g., one week, one month).
2565	   If the user then tries to examine a portion of the calendar outside
2566	   of the range that has been synchronized, the client can perform
2567	   another synchronization operation on the new time interval being
2568	   examined.  This "just-in-time" synchronization can minimize bandwidth
2569	   for common user interaction behaviors.

2571	8.2.1.3.  Synchronization Process

2573	   If a client wants to support calendar data synchronization, as
2574	   opposed to downloading calendar data each time it is needed, it needs
2575	   to cache the calendar object resource's URI and ETag along with the
2576	   actual calendar data.  While the URI remains static for the lifetime
2577	   of the calendar object resource, the ETag will change with each
2578	   successive change to the calendar object resource.  Thus to
2579	   synchronize a local data cache with the server, the client can first
2580	   fetch the URI/ETag pairs for the time interval being considered, and
2581	   compare those results with the cached data.  Any cached component
2582	   whose ETag differs from that on the server needs to be refreshed.

2584	   In order to properly detect the changes between the server and client
2585	   data, the client will need to keep a record of which calendar object
2586	   resources have been created, changed or deleted since the last
2587	   synchronization operation so that it can reconcile those changes with
2588	   the data on the server.

2590	   Here's an example of how to do that:

2592	   The client issues a CALDAV:calendar-query REPORT request for a
2593	   specific time range, and asks for only the DAV:getetag property to be
2594	   returned:

2596	   REPORT /bernard/work/ HTTP/1.1
2597	   Host: cal.example.com
2598	   Depth: 1
2599	   Content-Type: application/xml; charset="utf-8"
2600	   Content-Length: xxxx

2602	   <?xml version="1.0" encoding="utf-8" ?>
2603	   <C:calendar-query xmlns:D="DAV:"
2604	                     xmlns:C="urn:ietf:params:xml:ns:caldav">
2605	     <D:prop>
2606	       <D:getetag/>
2607	     </D:prop>
2608	     <C:filter>
2609	       <C:comp-filter name="VCALENDAR">
2610	         <C:comp-filter name="VEVENT">
2611	           <C:time-range start="20040902T000000Z"
2612	                           end="20040903T000000Z"/>
2613	         </C:comp-filter>
2614	       </C:comp-filter>
2615	     </C:filter>
2616	   </C:calendar-query>

2618	   The client then uses the results to determine which calendar object
2619	   resources have changed, been created or deleted on the server and how
2620	   those relate to locally cached calendar object resources that may
2621	   have changed, been created or deleted.  If the client determines that
2622	   there are calendar object resources on the server that need to be
2623	   fetched, the client issues a CALDAV:calendar-multiget REPORT request
2624	   to fetch their calendar data:

2626	   REPORT /bernard/work/ HTTP/1.1
2627	   Host: cal.example.com
2628	   Depth: 1
2629	   Content-Type: application/xml; charset="utf-8"
2630	   Content-Length: xxxx

2632	   <?xml version="1.0" encoding="utf-8" ?>
2633	   <C:calendar-multiget xmlns:D="DAV:"
2634	                        xmlns:C="urn:ietf:params:xml:ns:caldav">
2635	     <D:prop>
2636	       <D:getetag/>
2637	       <C:calendar-data/>
2638	     </D:prop>
2639	     <D:href>/bernard/work/abcd1.ics</D:href>
2640	     <D:href>/bernard/work/mtg1.ics</D:href>
2641	   </C:calendar-multiget>

2643	8.2.2.  Restrict the Properties Returned

2645	   Clients may not need all the calendar properties of a calendar object
2646	   resource when presenting information to the user.  Since some
2647	   calendar property values can be large (e.g., ATTACH or ATTENDEE)
2648	   clients can choose to restrict the calendar properties to be returned
2649	   in a calendaring REPORT request to those it knows it will use.

2651	   However, if a client needs to make a change to a calendar object
2652	   resource, it can only change the entire calendar object resource via
2653	   a PUT request.  There is currently no way to incrementally make a
2654	   change to a set of calendar properties of a calendar object resource.
2655	   As a result the client will have to get the entire calendar object
2656	   resource that is being changed.

2658	8.3.  Use of Locking

2660	   WebDAV locks can be used to prevent two clients modifying the same
2661	   resource from either overwriting each others' changes (though that
2662	   problem can also be solved by using ETags) or wasting time making
2663	   changes that will conflict with another set of changes.  In a multi-
2664	   user calendar system, an interactive calendar client could lock an
2665	   event while the user is editing the event, and unlock the event when
2666	   the user finishes or cancels.  Locks can also be used to prevent
2667	   changes while data is being reorganized.  For example, a calendar
2668	   client might lock two calendar collections prior to moving a bunch of
2669	   calendar resources from one to another.

2671	   Clients are responsible for requesting a lock timeout period that is
2672	   appropriate to the use case.  When the user explicitly decides to
2673	   reserve a resource and prevent other changes, a long timeout might be
2674	   appropriate, but in cases when the client automatically decides to
2675	   lock the resource the timeout should be short (and the client can
2676	   always refresh the lock should it need to).  A short lock timeout
2677	   means that if the client is unable to remove the lock, the other
2678	   calendar users aren't prevented from making changes.

2680	8.4.  Finding calendars

2682	   Much of the time a calendar client (or agent) will discover a new
2683	   calendar's location by being provided directly with the URL.  E.g., a
2684	   user will type his or her own calendar location into client
2685	   configuration information, or copy and paste a URL from email into
2686	   the calendar application.  The client need only confirm that the URL
2687	   points to a resource which is a calendar collection.  The client may
2688	   also be able to browse WebDAV collections to find calendar
2689	   collections.

2691	   The choice of HTTP URLs means that calendar object resources are
2692	   backward compatible with existing software, but does have the
2693	   disadvantage that existing software does not usually know to look at
2694	   the OPTIONS response to that URL to determine what can be done with
2695	   it.  This is somewhat of a barrier for WebDAV usage as well as with
2696	   CalDAV usage.  This specification does not offer a way through this
2697	   other than making the information available in the OPTIONS response
2698	   should this be requested.

2700	   For calendar sharing and scheduling use cases, one might wish to find
2701	   the calendar belonging to another user.  If the other user has a
2702	   calendar in the same repository, that calendar can be found by using
2703	   the principal namespace required by WebDAV ACL support.  For other
2704	   cases, the authors have no universal solution but implementors can
2705	   consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards
2706	   together with calendar attributes [RFC2739].

2708	   Because CalDAV requires servers to support WebDAV ACL [RFC3744]
2709	   including principal namespaces, and with the addition of the CALDAV:
2710	   calendar-home-set property, there are a couple options for CalDAV
2711	   clients to find one's own calendar or another user's calendar.

2713	   In this case, a DAV:principal-match REPORT is used to find a named
2714	   property (the CALDAV:calendar-home-set) on the Principal-URL of the
2715	   current user.  Using this, a WebDAV client can learn "who am I" and
2716	   "where are my calendars".  The REPORT request body looks like this:

2718	   <?xml version="1.0" encoding="utf-8" ?>
2719	   <D:principal-match xmlns:D="DAV:">
2720	     <D:self/>
2721	     <D:prop>
2722	       <C:calendar-home-set
2723	          xmlns:C="urn:ietf:params:xml:ns:caldav"/>
2724	     </D:prop>
2725	   </D:principal-match>

2727	   To find other users calendars, the DAV:principal-property-search
2728	   REPORT can be used to filter on some properties and return others.
2729	   To search for a calendar owned by a user named "Laurie", the REPORT
2730	   request body would look like this:

2732	   <?xml version="1.0" encoding="utf-8" ?>
2733	   <D:principal-property-search xmlns:D="DAV:">
2734	     <D:property-search>
2735	       <D:prop>
2736	         <D:displayname/>
2737	       </D:prop>
2738	       <D:match>Laurie</D:match>
2739	     </D:property-search>
2740	     <D:prop>
2741	       <C:calendar-home-set
2742	          xmlns:C="urn:ietf:params:xml:ns:caldav"/>
2743	       <D:displayname/>
2744	     </D:prop>
2745	   </D:principal-property-search>

2747	   The server performs a case-sensitive or caseless search for a
2748	   matching string subset of "Laurie" within the DAV:displayname
2749	   property.  Thus, the server might return "Laurie Dusseault", "Laurier
2750	   Desruisseaux" or "Wilfrid Laurier" all as matching DAV:displayname
2751	   values, and the calendars for each of these.

2753	8.5.  Storing and Using Attachments

2755	   CalDAV clients MAY create attachments in calendar components either
2756	   as inline or external.  This section contains some guidelines on
2757	   creating and managing attachments.

2759	8.5.1.  Inline attachments

2761	   CalDAV clients MUST support inline attachments as specified in
2762	   iCalendar [RFC2445].  CalDAV servers MUST support inline attachments,
2763	   so clients can rely on being able to create attachments this way.  On
2764	   the other hand, inline attachments have some drawbacks:

2766	   o  Servers MAY impose limitations on the size of calendar object
2767	      resources (i.e., refusing PUT requests of very large iCalendar
2768	      objects).

2770	   o  Servers MAY impose storage quota limitations on calendar
2771	      collections (See [I-D.ietf-webdav-quota]).

2773	   o  Any change to a calendar object resource containing an attachment
2774	      requires the entire attachment to be re-uploaded.

2776	   o  Clients synchronizing a changed calendar object resource have to
2777	      download the entire calendar object resource even if the
2778	      attachment is unchanged.

2780	8.5.2.  External attachments

2782	   CalDAV clients MUST support external attachments: if the client
2783	   accesses any calendar object resource it MUST be capable of also
2784	   accessing the external attachment if one exists.  An external
2785	   attachment could be:

2787	   o  In a collection in the calendar collection containing the calendar
2788	      object resource;

2790	   o  Somewhere else in the same repository that hosts the calendar
2791	      collection; or

2793	   o  On an HTTP or FTP server elsewhere.

2795	   CalDAV servers MAY provide support for child collections in calendar
2796	   collections.  CalDAV servers MAY allow the MKCOL method to create
2797	   child collections in calendar collections.  Child collections of
2798	   calendar collections MAY contain any type of resource except calendar
2799	   collections which they MUST NOT contain.  Some CalDAV servers won't
2800	   allow child collections in calendar collections, and it may be
2801	   possible on such a server to discover other locations where
2802	   attachments can be stored.

2804	   Clients are entirely responsible for maintaining reference
2805	   consistency with calendar components that link to external
2806	   attachments.  A client deleting a calendar component with an external
2807	   attachment might therefore also delete the attachment if that's
2808	   appropriate, however appropriateness can be very hard to determine.
2809	   A new component might easily reference some pre-existing Web resource
2810	   which is intended to have independent existence from the calendar
2811	   component (the "attachment" could be a major proposal to be discussed
2812	   in a meeting, for instance).  Best practices will probably emerge and
2813	   should probably be documented but for now clients should be wary of
2814	   engaging in aggressive "cleanup" of external attachments.  A client
2815	   could involve the user in making decisions about removing
2816	   unreferenced documents, or a client could be conservative in only
2817	   deleting attachments it had created.

2819	   Also, clients are responsible for consistency of permissions when
2820	   using external attachments.  One reason for servers to support the
2821	   storage of attachments within child collections of calendar
2822	   collections is that ACL inheritance might make it easier to grant the
2823	   same permissions to attachments that are granted on the calendar
2824	   collection.  Otherwise, it can be very difficult to keep permissions
2825	   synchronized.  With attachments stored on separate repositories, it
2826	   can be impossible to keep permissions consistent -- the two
2827	   repositories may not support the same permissions or have the same
2828	   set of principals.  Some systems have used tickets or other anonymous
2829	   access control mechanisms to provide partially satisfactory solutions
2830	   to these kinds of problems.

2832	8.6.  Storing and Using Alarms

2834	   Note that all CalDAV calendar collections (including those which the
2835	   user might treat as public or group calendars) can contain alarm
2836	   information on events and to-dos.  Users can synchronize a calendar
2837	   between multiple devices and decide to have alarms execute on a
2838	   different device than the device that created the alarm.  Not all
2839	   alarm action types are completely interoperable (e.g., those which
2840	   name a sound file to play).

2842	      When the action is "AUDIO", and the client is configured to
2843	      execute the alarm, the client SHOULD play the suggested sound if
2844	      it's available or play another sound, but SHOULD NOT rewrite the
2845	      alarm just to replace the suggested sound with a sound that's
2846	      locally available.

2848	      When the action is "DISPLAY", and the client is configured to
2849	      execute the alarm, the client SHOULD execute a display alarm by
2850	      displaying either according to the suggested description or some
2851	      reasonable replacement, but SHOULD NOT rewrite the alarm for its
2852	      own convenience.

2854	      When the action is "EMAIL", and the client is incapable of sending
2855	      email, it SHOULD ignore the alarm but MUST continue to synchronize
2856	      the alarm itself.

2858	      This specification makes no recommendations about executing alarm
2859	      of type PROCEDURE except to note that clients are advised to take
2860	      care to avoid creating security holes by executing these.

2862	   Non-interoperable alarm information (e.g., should somebody define a
2863	   color to be used in a display alarm) should be put in non-standard
2864	   properties inside the VALARM component in order to keep the basic
2865	   alarm usable on all devices.

2867	   Clients that allow changes to calendar object resources MUST
2868	   synchronize the alarm data that already exists in the resources.
2869	   Clients MAY execute alarms that are downloaded in this fashion,
2870	   possibly based on user preference.  If a client is only doing read
2871	   operations on a calendar and there is no risk of losing alarm
2872	   information, then the client MAY discard alarm information.

2874	   This specification makes no attempt to provide multi-user alarms on
2875	   group calendars or to find out who an alarm is intended for.
2876	   Addressing those issues might require extensions to iCalendar, for
2877	   example to store alarms per-user or indicate which user a VALARM was
2878	   intended for.  In the meantime, clients might maximize
2879	   interoperability by generally not uploading alarm information to
2880	   public, group or resource calendars.

2882	9.  XML Element Definitions

2884	9.1.  CALDAV:calendar XML Element

2886	   Name: calendar

2888	   Namespace: urn:ietf:params:xml:ns:caldav

2890	   Purpose: Specifies the resource type of a calendar collection.

2892	   Description: See Section 4.2.

2894	   Definition:

2896	         <!ELEMENT calendar EMPTY>

2898	9.2.  CALDAV:mkcalendar XML Element

2900	   Name: mkcalendar

2902	   Namespace: urn:ietf:params:xml:ns:caldav

2904	   Purpose: Specifies a request that lists the WebDAV property values to
2905	      be set for a calendar collection resource.

2907	   Description: See Section 5.3.1.

2909	   Definition:

2911	         <!ELEMENT mkcalendar (DAV:set)>

2913	9.3.  CALDAV:mkcalendar-response XML Element

2915	   Name: mkcalendar-response

2917	   Namespace: urn:ietf:params:xml:ns:caldav

2919	   Purpose: Specifies a response body for a successful MKCALENDAR
2920	      request.

2922	   Description: See Section 5.3.1.

2924	   Definition:

2926	         <!ELEMENT mkcalendar-response ANY>

2928	9.4.  CALDAV:calendar-query XML Element

2930	   Name: calendar-query

2932	   Namespace: urn:ietf:params:xml:ns:caldav

2934	   Purpose: Defines a REPORT for querying calendar object resources.

2936	   Description: See Section 7.7.

2938	   Definition:

2940	         <!ELEMENT calendar-query ((DAV:allprop |
2941	                                    DAV:propname |
2942	                                    DAV:prop)?, filter, timezone?)>

2944	9.5.  CALDAV:calendar-data XML Element

2946	   Name: calendar-data

2948	   Namespace: urn:ietf:params:xml:ns:caldav

2950	   Purpose: Used to (1) specify a supported media type for calendar
2951	      object resources when nested in the CALDAV:supported-calendar-data
2952	      property; (2) specify which parts of a calendar object resource
2953	      should be returned by a given calendaring REPORT; and (3) specify
2954	      the content of a calendar object resource in a response to a
2955	      calendaring REPORT.

2957	   Description: When nested in the CALDAV:supported-calendar-data
2958	      property, the CALDAV:calendar-data XML element specifies a media
2959	      type supported by the CalDAV server for calendar object resources.

2961	      When used in a calendaring REPORT request, the CALDAV:calendar-
2962	      data XML element specifies which parts of calendar object
2963	      resources need to be returned in the response.  If the CALDAV:
2964	      calendar-data XML element doesn't contain any CALDAV:comp element,
2965	      calendar object resources will be returned in their entirety.

2967	      Finally, when used in a calendaring REPORT response, the CALDAV:
2968	      calendar-data XML element specifies the content of a calendar
2969	      object resource.  Given that XML parsers normalizes the two-
2970	      character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal
2971	      10) to a single LF character (US-ASCII decimal 10), the CR
2972	      character (US-ASCII decimal 13) MAY be omitted in calendar object
2973	      resources specified in the CALDAV:calendar-data XML element.
2974	      Furthermore, calendar object resources specified in the CALDAV:
2975	      calendar-data XML element MAY be invalid per their media type
2976	      specification if the CALDAV:calendar-data XML element part of the
2977	      calendaring REPORT request did not specify required properties
2978	      (e.g., UID, DTSTAMP, etc.) or specified a CALDAV:prop XML element
2979	      with the "novalue" attribute set to "yes".

2981	   Note: The CALDAV:calendar-data XML element is specified in requests
2982	      and responses inside the DAV:prop XML element as if it were a
2983	      WebDAV property.  However, the CALDAV:calendar-data XML element is
2984	      not a WebDAV property and as such it is not returned in PROPFIND
2985	      responses nor used in PROPPATCH requests.

2987	   Definition:

2989	         <!ELEMENT calendar-data ((comp?, (expand |
2990	                                           limit-recurrence-set)?,
2991	                                           limit-freebusy-set?) |
2992	                                  #PCDATA)?>
2993	         PCDATA value: iCalendar object

2995	         <!ATTLIST calendar-data content-type CDATA "text/calendar">
2996	                                 version CDATA "2.0">
2997	         content-type value: a MIME media type
2998	         version value: a version string

3000	9.5.1.  CALDAV:comp XML Element

3002	   Name: comp

3004	   Namespace: urn:ietf:params:xml:ns:caldav

3006	   Purpose: Defines which component types to return.

3008	   Description: The name value is a calendar component name (e.g.,
3009	      "VEVENT").

3011	   Definition:

3013	         <!ELEMENT comp (((allprop | prop*), allcomp) |
3014	                         ((allprop | prop*), comp*))>

3016	         <!ATTLIST comp name CDATA #REQUIRED>
3017	         name value: a calendar component name

3019	   Note: The CALDAV:prop and CALDAV:allprop elements have the same name
3020	      as the DAV:prop and DAV:allprop elements defined in [RFC2518].
3021	      However, the CALDAV:prop and CALDAV:allprop element are defined in
3022	      the "urn:ietf:params:xml:ns:caldav" namespace instead of the
3023	      "DAV:" namespace.

3025	9.5.2.  CALDAV:allcomp XML Element

3027	   Name: allcomp

3029	   Namespace: urn:ietf:params:xml:ns:caldav

3031	   Purpose: Specifies that all components shall be returned.

3033	   Description: The CALDAV:allcomp XML element can be used when the
3034	      client wants all types of components returned by a calendaring
3035	      REPORT request.

3037	   Definition:

3039	         <!ELEMENT allcomp EMPTY>

3041	9.5.3.  CALDAV:allprop XML Element

3043	   Name: allprop
3044	   Namespace: urn:ietf:params:xml:ns:caldav

3046	   Purpose: Specifies that all properties shall be returned.

3048	   Description: The CALDAV:allprop XML element can be used when the
3049	      client wants all properties of components returned by a
3050	      calendaring REPORT request.

3052	   Definition:

3054	         <!ELEMENT allprop EMPTY>

3056	   Note: The CALDAV:allprop element has the same name as the DAV:allprop
3057	      element defined in [RFC2518].  However, the CALDAV:allprop element
3058	      is defined in the "urn:ietf:params:xml:ns:caldav" namespace
3059	      instead of the "DAV:" namespace.

3061	9.5.4.  CALDAV:prop XML Element

3063	   Name: prop

3065	   Namespace: urn:ietf:params:xml:ns:caldav

3067	   Purpose: Defines which properties to return in the response.

3069	   Description: The "name" attribute specifies the name of the calendar
3070	      property to return (e.g., "ATTENDEE").  The "novalue" attribute
3071	      can be used by clients to request that the actual value of the
3072	      property not be returned (if the "novalue" attribute is set to
3073	      "yes").  In that case the server will return just the iCalendar
3074	      property name and any iCalendar parameters and a trailing ":"
3075	      without the subsequent value data.

3077	   Definition:

3079	         <!ELEMENT prop EMPTY>

3081	         <!ATTLIST prop name CDATA #REQUIRED
3082	                     novalue (yes | no) "no">
3083	         name value: a calendar property name
3084	         novalue value: "yes" or "no"

3086	   Note: The CALDAV:prop element has the same name as the DAV:prop
3087	      element defined in [RFC2518].  However, the CALDAV:prop element is
3088	      defined in the "urn:ietf:params:xml:ns:caldav" namespace instead
3089	      of the "DAV:" namespace.

3091	9.5.5.  CALDAV:expand XML Element

3093	   Name: expand

3095	   Namespace: urn:ietf:params:xml:ns:caldav

3097	   Purpose: Forces the server to expand recurring components into
3098	      individual recurrence instances.

3100	   Description: The CALDAV:expand XML element specifies that for a given
3101	      calendaring REPORT request the server MUST expand the recurrence
3102	      set into calendar components that define exactly one recurrence
3103	      instance and MUST return only those whose scheduled time intersect
3104	      a specified time range.  The "start" attribute specifies the
3105	      inclusive start of the time range, and the "end" attribute
3106	      specifies the non-inclusive end of the time range.  Both
3107	      attributes are specified as date with UTC time value.  The server
3108	      MUST use the same logic as defined for CALDAV:time-range to
3109	      determine if a recurrence instance intersects the specified time
3110	      range.  Recurring components, other than the initial instance,
3111	      MUST include a RECURRENCE-ID property indicating which instance
3112	      they refer to.  The returned calendar components MUST NOT use
3113	      recurrence properties (i.e., EXDATE, EXRULE, RDATE and RRULE) and
3114	      MUST NOT have reference to or include VTIMEZONE components.  Date
3115	      and local time with reference to time zone information MUST be
3116	      converted into date with UTC time.

3118	   Definition:

3120	         <!ELEMENT expand EMPTY>

3122	         <!ATTLIST expand start CDATA #REQUIRED
3123	                         end   CDATA #REQUIRED>
3124	         start value: an iCalendar "date with UTC time"
3125	         end value: an iCalendar "date with UTC time"

3127	9.5.6.  CALDAV:limit-recurrence-set XML Element

3129	   Name: limit-recurrence-set

3131	   Namespace: urn:ietf:params:xml:ns:caldav

3133	   Purpose: Specifies a time range to limit the set of "overridden
3134	      components" returned by the server.

3136	   Description: The CALDAV:limit-recurrence-set XML element specifies
3137	      that for a given calendaring REPORT request the server MUST only
3138	      return the "master component" as well as the "overridden
3139	      components" that specify one or more recurrence instances whose
3140	      current scheduled time or original scheduled time intersect a
3141	      specified time range.  The "start" attribute specifies the
3142	      inclusive start of the time range, and the "end" attribute
3143	      specifies the non-inclusive end of the time range.  Both
3144	      attributes are specified as date with UTC time value.  The server
3145	      MUST use the same logic as defined for CALDAV:time-range to
3146	      determine if the current or original scheduled time of an
3147	      "overridden" recurrence instance intersect the specified time
3148	      range.  Overridden components that have a RANGE parameter on their
3149	      RECURRENCE-ID property may specify one or more instances in the
3150	      recurrence set, and some of those instances may fall within the
3151	      specified time range, or may have originally fallen within the
3152	      specified time range prior to being overridden.  If that is the
3153	      case, the overridden component MUST be included in the results as
3154	      it has a direct impact on the interpretation of instances within
3155	      the specified time range.

3157	   Definition:

3159	         <!ELEMENT limit-recurrence-set EMPTY>

3161	         <!ATTLIST limit-recurrence-set start CDATA #REQUIRED
3162	                                       end   CDATA #REQUIRED>
3163	         start value: an iCalendar "date with UTC time"
3164	         end value: an iCalendar "date with UTC time"

3166	9.5.7.  CALDAV:limit-freebusy-set XML Element

3168	   Name: limit-freebusy-set

3170	   Namespace: urn:ietf:params:xml:ns:caldav

3172	   Purpose: Specifies a time range to limit the set of FREEBUSY values
3173	      returned by the server.

3175	   Description: The CALDAV:limit-freebusy-set XML element specifies that
3176	      for a given calendaring REPORT request the server MUST only return
3177	      the FREEBUSY property values of a VFREEBUSY component that
3178	      intersect a specified time range.  The "start" attribute specifies
3179	      the inclusive start of the time range, and the "end" attribute
3180	      specifies the non-inclusive end of the time range.  Both
3181	      attributes are specified as "date with UTC time" value.  The
3182	      server MUST use the same logic as defined for CALDAV:time-range to
3183	      determine if a FREEBUSY property value intersect the specified
3184	      time range.

3186	   Definition:

3188	         <!ELEMENT limit-freebusy-set EMPTY>

3190	         <!ATTLIST limit-freebusy-set start CDATA #REQUIRED
3191	                                     end   CDATA #REQUIRED>
3192	         start value: an iCalendar "date with UTC time"
3193	         end value: an iCalendar "date with UTC time"

3195	9.6.  CALDAV:filter XML Element

3197	   Name: filter

3199	   Namespace: urn:ietf:params:xml:ns:caldav

3201	   Purpose: Specifies a filter to limit the set of calendar components
3202	      returned by the server.

3204	   Description: The CALDAV:filter XML element specifies the search
3205	      filter used to limit the calendar components returned by a
3206	      calendaring REPORT request.

3208	   Definition:

3210	         <!ELEMENT filter (comp-filter)>

3212	9.6.1.  CALDAV:comp-filter XML Element

3214	   Name: comp-filter

3216	   Namespace: urn:ietf:params:xml:ns:caldav

3218	   Purpose: Specifies search criteria on calendar components.

3220	   Description: The CALDAV:comp-filter XML element specifies the queried
3221	      calendar component type (e.g., "VEVENT").  A calendar object
3222	      resource is said to match a CALDAV:comp-filter if it contains
3223	      calendar components of the type specified by the "name" attribute,
3224	      and that it contains at least one recurrence instance scheduled to
3225	      overlap a given time range if a CALDAV:time-range XML element is
3226	      specified, and that any CALDAV:prop-filter and CALDAV:comp-filter
3227	      child elements also matches.

3229	   Definition:

3231	         <!ELEMENT comp-filter (time-range?, prop-filter*,
3232	                                comp-filter*)>

3234	         <!ATTLIST comp-filter name CDATA #REQUIRED>
3235	         name value: a calendar component name (e.g., "VEVENT")

3237	9.6.2.  CALDAV:prop-filter XML Element

3239	   Name: prop-filter

3241	   Namespace: urn:ietf:params:xml:ns:caldav

3243	   Purpose: Specifies search criteria on calendar properties.

3245	   Description: The CALDAV:prop-filter XML element specifies a search
3246	      criteria on a specific calendar property (e.g., CATEGORIES) in the
3247	      scope of a given CALDAV:comp-filter.  A calendar component is said
3248	      to match a CALDAV:prop-filter if it defines the property specified
3249	      by the "name" attribute, and that it matches the CALDAV:time-range
3250	      or CALDAV:text-match conditions if specified, and that any CALDAV:
3251	      param-filter child elements also matches.

3253	   Definition:

3255	         <!ELEMENT prop-filter ((time-range | text-match)?,
3256	                               param-filter*)>

3258	         <!ATTLIST prop-filter name CDATA #REQUIRED>
3259	         name value: a calendar property name (e.g., "ATTENDEE")

3261	9.6.3.  CALDAV:param-filter XML Element

3263	   Name: param-filter

3265	   Namespace: urn:ietf:params:xml:ns:caldav

3267	   Purpose: Limits the search to specific parameter values.

3269	   Description: The CALDAV:param-filter XML element specifies a search
3270	      criteria on a specific calendar property parameter (e.g.,
3271	      PARTSTAT) in the scope of a given CALDAV:prop-filter.  A calendar
3272	      property is said to match a CALDAV:param-filter if it defines the
3273	      parameter specified by the "name" attribute, and that it matches
3274	      the CALDAV:text-match condition if specified.

3276	   Definition:

3278	         <!ELEMENT param-filter (text-match?)>

3280	         <!ATTLIST param-filter name CDATA #REQUIRED>
3281	         name value: a property parameter name (e.g., "PARTSTAT")

3283	9.6.4.  CALDAV:text-match XML Element

3285	   Name: text-match

3287	   Namespace: urn:ietf:params:xml:ns:caldav

3289	   Purpose: Specifies a substring match on a property or parameter
3290	      value.

3292	   Description: The CALDAV:text-match XML element specifies text used
3293	      for a substring match against the property or parameter value
3294	      specified in a calendaring REPORT request.  The "caseless"
3295	      attribute indicates whether the match is case-sensitive (value set
3296	      to "no") or case-insensitive (value set to "yes").  The default
3297	      value is server-specified.  Caseless matching SHOULD be
3298	      implemented as defined in section 5.18 of the Unicode Standard
3299	      ([UNICODE4]).  Support for the "caseless" attribute is REQUIRED.
3300	      A server MAY ignore the caseless attribute when applied to
3301	      enumerated iCalendar property or parameter values, and default to
3302	      caseless matching for those values, since they are defined as
3303	      being case-insensitive in iCalendar.

3305	   Definition:

3307	         <!ELEMENT text-match (#PCDATA)>
3308	         PCDATA value: string

3310	         <!ATTLIST text-match caseless (yes | no) #IMPLIED>

3312	9.7.  CALDAV:timezone XML Element

3314	   Name: timezone

3316	   Namespace: urn:ietf:params:xml:ns:caldav

3318	   Purpose: Specifies the time zone component to use when determining
3319	      the results of a report.

3321	   Description: The CALDAV:timezone XML element specifies that for a
3322	      given calendaring REPORT request the server MUST rely on the
3323	      specified VTIMEZONE component instead of the CALDAV:calendar-
3324	      timezone property of the calendar collection in which the calendar
3325	      object resource is contained to resolve "date" values and "date
3326	      with local time" values (i.e., floating time) to "date with UTC
3327	      time" values.  The server will require this information to
3328	      determine if a calendar component scheduled with "date" values or
3329	      "date with local time" values intersect a CALDAV:time-range
3330	      specified in a CALDAV:calendar-query REPORT.

3332	   Definition:

3334	         <!ELEMENT timezone (#PCDATA)>
3335	         PCDATA value: an iCalendar object with exactly one VTIMEZONE

3337	9.8.  CALDAV:time-range XML Element

3339	   Name: time-range

3341	   Namespace: urn:ietf:params:xml:ns:caldav

3343	   Purpose: Specifies a time range to limit the set of calendar
3344	      components returned by the server.

3346	   Description: The CALDAV:time-range XML element specifies that for a
3347	      given calendaring REPORT request the server MUST only return the
3348	      calendar object resources that, depending on the context, have a
3349	      component or property or parameter whose value intersect a
3350	      specified time range.  The "start" attribute specifies the
3351	      inclusive start of the time range, and the "end" attribute
3352	      specifies the non-inclusive end of the time range.  Both
3353	      attributes are specified as "date with UTC time" value.  While the
3354	      "start" and "end" attributes are not required to allow time ranges
3355	      opened at one end, at least one of them MUST be specified in the
3356	      CALDAV:time-range element.

3358	      A VEVENT component overlaps a given time range if:

3360	         (DTSTART <= start AND DTEND > start) OR
3361	         (DTSTART <= start AND DTSTART+DURATION > start) OR
3362	         (DTSTART >= start AND DTSTART < end) OR
3363	         (DTEND   > start AND DTEND <= end)

3365	      A VEVENT component with no DTSTART and DTEND properties does not
3366	      overlap any time range.

3368	      A VTODO component overlaps a given time range if:

3370	         (DTSTART <= start AND DUE >= start) OR
3371	         (DTSTART <= start AND DTSTART+DURATION > start) OR
3372	         (DTSTART >= start AND DTSTART < end) OR
3373	         (DUE     >= start AND DUE < end)

3375	      A VTODO component with no DTSTART and DUE properties does not
3376	      overlap any time range.

3378	      A VJOURNAL component overlaps a given time range if:

3380	         DTSTART >= start AND DTSTART < end

3382	      A VJOURNAL component with no DTSTART property does not overlap any
3383	      time range.

3385	      A VFREEBUSY component overlaps a given time range if for any of
3386	      its FREEBUSY property value the following condition holds:

3388	         freebusy-period-start >= start AND freebusy-period-end < end

3390	      A VFREEBUSY component with no FREEBUSY property does not overlap
3391	      any time range.

3393	      A VALARM component overlaps a given time range if:

3395	         trigger-time >= start AND trigger-time < end

3397	      A VALARM component can be defined such that it triggers
3398	      repeatedly.  Such a VALARM component is said to overlap a given
3399	      time range if at least one of its trigger overlap the time range.

3401	      The calendar properties COMPLETED, CREATED, DTSTAMP and LAST-
3402	      MODIFIED overlaps a given time range

3404	         date-time >= start AND date-time < end

3406	      The semantic of CALDAV:time-range is not defined for any other
3407	      calendar properties.

3409	   Definition:

3411	         <!ELEMENT time-range EMPTY>

3413	         <!ATTLIST time-range start CDATA #IMPLIED
3414	                             end   CDATA #IMPLIED>
3415	         start value: an iCalendar "date with UTC time"
3416	         end value: an iCalendar "date with UTC time"

3418	9.9.  CALDAV:calendar-multiget XML Element

3420	   Name: calendar-multiget

3422	   Namespace: urn:ietf:params:xml:ns:caldav

3424	   Purpose: CalDAV REPORT used to retrieve specific calendar object
3425	      resources.

3427	   Description: See Section 7.8.

3429	   Definition:

3431	         <!ELEMENT calendar-multiget ((DAV:allprop |
3432	                                      DAV:propname |
3433	                                      DAV:prop)?, DAV:href+)>

3435	9.10.  CALDAV:free-busy-query XML Element

3437	   Name: free-busy-query

3439	   Namespace: urn:ietf:params:xml:ns:caldav

3441	   Purpose: CalDAV REPORT used to generate a VFREEBUSY to determine busy
3442	      time over a specific time range.

3444	   Description: See Section 7.9.

3446	   Definition:

3448	         <!ELEMENT free-busy-query (time-range)>

3450	10.  Internationalization Considerations

3452	   CalDAV allows internationalized strings to be stored and retrieved
3453	   for the description of calendar collections (see Section 5.2.1).

3455	11.  Security Considerations

3457	   HTTP protocol transactions are sent in the clear over the network
3458	   unless protection from snooping is negotiated.  This can be
3459	   accomplished by use of TLS as defined in [RFC2818].  In particular,
3460	   HTTP Basic authentication MUST NOT be used unless TLS is in effect.

3462	   Servers MUST take adequate precautions to ensure malicious clients
3463	   cannot consume excessive server resources (CPU, memory, disk, etc.)
3464	   through carefully crafted reports.  For example, a client could
3465	   upload an event with a recurrence rule that specifies a recurring
3466	   event occurring every second for the next 100 years which would
3467	   result in approximately 3 x 10^9 instances!  A REPORT that asks for
3468	   recurrences to be expanded over that range would likely constitute a
3469	   denial-of-service attack on the server.

3471	   When creating new resources (including calendar collections), clients
3472	   MUST ensure that the resource name (the last path segment of the
3473	   resource URI) assigned to the new resource does not expose any data
3474	   from within the iCalendar resource itself and information about the
3475	   nature of a calendar collection.  This is required to ensure that the
3476	   presence of a specific iCalendar component or nature of components in
3477	   a collection cannot be inferred based on the name of a resource.

3479	   Security considerations described in iCalendar [RFC2445] and iTIP
3480	   [RFC2446] are also applicable to CalDAV.

3482	   Beyond these, CalDAV does not raise any security considerations that
3483	   are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253],
3484	   [RFC3744], as discussed in those documents.

3486	12.  IANA Consideration

3488	   This document uses one new URN to identify a new XML namespace.  The
3489	   URN conforms to a registry mechanism described in [RFC3688].

3491	12.1.  Namespace Registration

3493	   Registration request for the CalDAV namespace:

3495	   URI: urn:ietf:params:xml:ns:caldav

3497	   Registrant Contact: See the "Author's Address" section of this
3498	   document.

3500	   XML: None.  Namespace URIs do not represent an XML specification.

3502	13.  Acknowledgements

3504	   The authors would like to thank the following individuals for
3505	   contributing their ideas and support for writing this specification:
3506	   Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Mike Douglass,
3507	   Helge Hess, Dan Mosedale, Kervin L. Pierre, Julian F. Reschke, Mike
3508	   Shaver, Simon Vaillancourt, Wilfredo Sanchez Vega and Jim Whitehead.

3510	   The authors would also like to thank the Calendaring and Scheduling
3511	   Consortium for advice with this specification, and for organizing
3512	   interoperability testing events to help refine it.

3514	14.  References

3516	14.1.  Normative References

3518	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
3519	              Requirement Levels", BCP 14, RFC 2119, March 1997.

3521	   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
3522	              RFC 2246, January 1999.

3524	   [RFC2445]  Dawson, F. and Stenerson, D., "Internet Calendaring and
3525	              Scheduling Core Object Specification (iCalendar)",
3526	              RFC 2445, November 1998.

3528	   [RFC2446]  Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
3529	              "iCalendar Transport-Independent Interoperability Protocol
3530	              (iTIP) Scheduling Events, BusyTime, To-dos and Journal
3531	              Entries", RFC 2446, November 1998.

3533	   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
3534	              Jensen, "HTTP Extensions for Distributed Authoring --
3535	              WEBDAV", RFC 2518, February 1999.

3537	   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3538	              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3539	              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

3541	   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

3543	   [RFC3253]  Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
3544	              Whitehead, "Versioning Extensions to WebDAV (Web
3545	              Distributed Authoring and Versioning)", RFC 3253,
3546	              March 2002.

3548	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3549	              January 2004.

3551	   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
3552	              Distributed Authoring and Versioning (WebDAV) Access
3553	              Control Protocol", RFC 3744, May 2004.

3555	   [UNICODE4]
3556	              The Unicode Consortium, "The Unicode Standard, Version
3557	              4.0", Addison-Wesley, Boston, MA. ISBN 0-321-18578-1,
3558	              August 2003,
3559	              <http://www.unicode.org/versions/Unicode4.0.0/>.

3561	   [W3C.REC-xml-20040204]
3562	              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
3563	              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
3564	              Edition)", W3C REC REC-xml-20040204, February 2004.

3566	14.2.  Informative References

3568	   [I-D.ietf-webdav-quota]
3569	              Korver, B. and L. Dusseault, "Quota and Size Properties
3570	              for DAV Collections", draft-ietf-webdav-quota-07 (work in
3571	              progress), April 2005.

3573	   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
3574	              Access Protocol (v3)", RFC 2251, December 1997.

3576	   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
3577	              RFC 2426, September 1998.

3579	   [RFC2739]  Small, T., Hennessy, D., and F. Dawson, "Calendar
3580	              Attributes for vCard and LDAP", RFC 2739, January 2000.

3582	Appendix A.  CalDAV Method Privilege Table (Normative)

3584	   The following table extends the WebDAV Method Privilege Table
3585	   specified in Appendix B of [RFC3744].

3587	   +------------+------------------------------------------------------+
3588	   | METHOD     | PRIVILEGES                                           |
3589	   +------------+------------------------------------------------------+
3590	   | MKCALENDAR | DAV:bind                                             |
3591	   | REPORT     | DAV:read or CALDAV:read-free-busy (on all referenced |
3592	   |            | resources)                                           |
3593	   +------------+------------------------------------------------------+

3595	Appendix B.  Calendar collections used in the examples

3597	   This appendix shows the calendar object resources contained in the
3598	   calendar collection queried in the examples throughout this document.

3600	   The content of the calendar collection is being shown as it would be
3601	   returned by a CALDAV:calendar-query REPORT request designed to return
3602	   all the calendar data in the collection:

3604	   >> Request <<

3606	      REPORT /bernard/work/ HTTP/1.1
3607	      Host: cal.example.com
3608	      Depth: 1
3609	      Content-Type: application/xml; charset="utf-8"
3610	      Content-Length: xxxx

3612	   >> Response <<

3614	      <?xml version="1.0" encoding="utf-8" ?>
3615	      <C:calendar-query xmlns:D="DAV:"
3616	                        xmlns:C="urn:ietf:params:xml:ns:caldav">
3617	        <D:prop>
3618	          <D:getetag/>
3619	          <C:calendar-data/>
3620	        </D:prop>
3621	        <C:filter>
3622	          <C:comp-filter name="VCALENDAR">
3623	            <C:allprop/>
3624	            <C:allcomp/>
3625	          </C:comp-filter>
3626	        </C:filter>
3627	      </C:calendar-query>

3629	      <?xml version="1.0" encoding="utf-8" ?>
3630	      <D:multistatus xmlns:D="DAV:"
3631	                     xmlns:C="urn:ietf:params:xml:ns:caldav">

3633	        <D:response>
3634	          <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
3635	          <D:propstat>
3636	            <D:prop>
3637	              <D:getetag>"fffff-abcd1"</D:getetag>
3638	              <C:calendar-data>BEGIN:VCALENDAR
3639	      VERSION:2.0
3640	      PRODID:-//Example Corp.//CalDAV Client//EN
3641	      BEGIN:VTIMEZONE
3642	      LAST-MODIFIED:20040110T032845Z
3643	      TZID:US/Eastern
3644	      BEGIN:DAYLIGHT
3645	      DTSTART:20000404T020000
3646	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3647	      TZNAME:EDT
3648	      TZOFFSETFROM:-0500
3649	      TZOFFSETTO:-0400
3650	      END:DAYLIGHT
3651	      BEGIN:STANDARD
3652	      DTSTART:20001026T020000
3653	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3654	      TZNAME:EST
3655	      TZOFFSETFROM:-0400
3656	      TZOFFSETTO:-0500
3657	      END:STANDARD
3658	      END:VTIMEZONE
3659	      BEGIN:VEVENT
3660	      DTSTAMP:20060206T001102Z
3661	      DTSTART;TZID=US/Eastern:20060102T100000
3662	      DURATION:PT1H
3663	      SUMMARY:Event #1
3664	      Description:Go Steelers!
3665	      UID:74855313FA803DA593CD579A@example.com
3666	      END:VEVENT
3667	      END:VCALENDAR
3668	      </C:calendar-data>
3669	            </D:prop>
3670	            <D:status>HTTP/1.1 200 OK</D:status>
3671	          </D:propstat>
3672	        </D:response>

3674	        <D:response>
3675	          <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
3676	          <D:propstat>
3677	            <D:prop>
3678	              <D:getetag>"fffff-abcd2"</D:getetag>
3679	              <C:calendar-data>BEGIN:VCALENDAR
3680	      VERSION:2.0
3681	      PRODID:-//Example Corp.//CalDAV Client//EN
3682	      BEGIN:VTIMEZONE
3683	      LAST-MODIFIED:20040110T032845Z
3684	      TZID:US/Eastern
3685	      BEGIN:DAYLIGHT
3686	      DTSTART:20000404T020000
3687	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3688	      TZNAME:EDT
3689	      TZOFFSETFROM:-0500
3690	      TZOFFSETTO:-0400
3691	      END:DAYLIGHT
3692	      BEGIN:STANDARD
3693	      DTSTART:20001026T020000
3694	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3695	      TZNAME:EST
3696	      TZOFFSETFROM:-0400
3697	      TZOFFSETTO:-0500
3698	      END:STANDARD
3699	      END:VTIMEZONE
3700	      BEGIN:VEVENT
3701	      DTSTAMP:20060206T001121Z
3702	      DTSTART;TZID=US/Eastern:20060102T120000
3703	      DURATION:PT1H
3704	      RRULE:FREQ=DAILY;COUNT=5
3705	      SUMMARY:Event #2
3706	      UID:00959BC664CA650E933C892C@example.com
3707	      END:VEVENT
3708	      BEGIN:VEVENT
3709	      DTSTAMP:20060206T001121Z
3710	      DTSTART;TZID=US/Eastern:20060104T140000
3711	      DURATION:PT1H
3712	      RECURRENCE-ID;TZID=US/Eastern:20060104T120000
3713	      SUMMARY:Event #2 bis
3714	      UID:00959BC664CA650E933C892C@example.com
3715	      END:VEVENT
3716	      END:VCALENDAR
3717	      </C:calendar-data>
3718	            </D:prop>
3719	            <D:status>HTTP/1.1 200 OK</D:status>
3720	          </D:propstat>
3721	        </D:response>

3723	        <D:response>
3724	          <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
3725	          <D:propstat>
3726	            <D:prop>
3727	              <D:getetag>"fffff-abcd3"</D:getetag>
3728	              <C:calendar-data>BEGIN:VCALENDAR
3729	      VERSION:2.0
3730	      PRODID:-//Example Corp.//CalDAV Client//EN
3731	      BEGIN:VTIMEZONE
3732	      LAST-MODIFIED:20040110T032845Z
3733	      TZID:US/Eastern
3734	      BEGIN:DAYLIGHT
3735	      DTSTART:20000404T020000
3736	      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3737	      TZNAME:EDT
3738	      TZOFFSETFROM:-0500
3739	      TZOFFSETTO:-0400
3740	      END:DAYLIGHT
3741	      BEGIN:STANDARD
3742	      DTSTART:20001026T020000
3743	      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3744	      TZNAME:EST
3745	      TZOFFSETFROM:-0400
3746	      TZOFFSETTO:-0500
3747	      END:STANDARD
3748	      END:VTIMEZONE
3749	      BEGIN:VEVENT
3750	      ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
3751	      ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
3752	      DTSTAMP:20060206T001220Z
3753	      DTSTART;TZID=US/Eastern:20060104T100000
3754	      DURATION:PT1H
3755	      LAST-MODIFIED:20060206T001330Z
3756	      ORGANIZER:mailto:cyrus@example.com
3757	      SEQUENCE:1
3758	      STATUS:TENTATIVE
3759	      SUMMARY:Event #3
3760	      UID:DC6C50A017428C5216A2F1CD@example.com
3761	      END:VEVENT
3762	      END:VCALENDAR
3763	      </C:calendar-data>
3764	            </D:prop>
3765	            <D:status>HTTP/1.1 200 OK</D:status>
3766	          </D:propstat>
3767	        </D:response>

3769	        <D:response>
3770	          <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
3771	          <D:propstat>
3772	            <D:prop>
3773	              <D:getetag>"fffff-abcd4"</D:getetag>
3774	              <C:calendar-data>BEGIN:VCALENDAR
3775	      VERSION:2.0
3776	      PRODID:-//Example Corp.//CalDAV Client//EN
3777	      BEGIN:VTODO
3778	      DTSTAMP:20060205T235335Z
3779	      DUE;VALUE=DATE:20060104
3780	      STATUS:NEEDS-ACTION
3781	      SUMMARY:Task #1
3782	      UID:DDDEEB7915FA61233B861457@example.com
3783	      BEGIN:VALARM
3784	      ACTION:AUDIO
3785	      TRIGGER;RELATED=START:-PT10M
3786	      END:VALARM
3787	      END:VTODO
3788	      END:VCALENDAR
3789	      </C:calendar-data>
3790	            </D:prop>
3791	            <D:status>HTTP/1.1 200 OK</D:status>
3792	          </D:propstat>

3794	        </D:response>

3796	        <D:response>
3797	          <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
3798	          <D:propstat>
3799	            <D:prop>
3800	              <D:getetag>"fffff-abcd5"</D:getetag>
3801	              <C:calendar-data>BEGIN:VCALENDAR
3802	      VERSION:2.0
3803	      PRODID:-//Example Corp.//CalDAV Client//EN
3804	      BEGIN:VTODO
3805	      DTSTAMP:20060205T235300Z
3806	      DUE;VALUE=DATE:20060106
3807	      LAST-MODIFIED:20060205T235308Z
3808	      SEQUENCE:1
3809	      STATUS:NEEDS-ACTION
3810	      SUMMARY:Task #2
3811	      UID:E10BA47467C5C69BB74E8720@example.com
3812	      BEGIN:VALARM
3813	      ACTION:AUDIO
3814	      TRIGGER;RELATED=START:-PT10M
3815	      END:VALARM
3816	      END:VTODO
3817	      END:VCALENDAR
3818	      </C:calendar-data>
3819	            </D:prop>
3820	            <D:status>HTTP/1.1 200 OK</D:status>
3821	          </D:propstat>
3822	        </D:response>

3824	        <D:response>
3825	          <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
3826	          <D:propstat>
3827	            <D:prop>
3828	              <D:getetag>"fffff-abcd6"</D:getetag>
3829	              <C:calendar-data>BEGIN:VCALENDAR
3830	      VERSION:2.0
3831	      PRODID:-//Example Corp.//CalDAV Client//EN
3832	      BEGIN:VFREEBUSY
3833	      ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
3834	      UID:76ef34-54a3d2@example.com
3835	      DTSTAMP:20050530T123421Z
3836	      DTSTART:20060101T000000Z
3837	      DTEND:20060108T000000Z
3838	      FREEBUSY:20050531T230000Z/20050601T010000Z
3839	      FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
3840	      FREEBUSY:20060103T100000Z/20060103T120000Z
3841	      FREEBUSY:20060104T100000Z/20060104T120000Z
3842	      FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
3843	      FREEBUSY:20060106T100000Z/20060106T120000Z
3844	      END:VFREEBUSY
3845	      END:VCALENDAR
3846	      </C:calendar-data>
3847	            </D:prop>
3848	            <D:status>HTTP/1.1 200 OK</D:status>
3849	          </D:propstat>
3850	        </D:response>

3852	      </D:multistatus>

3854	Appendix C.  Changes

3856	C.1.  Changes in -10

3858	   a.  Added new section about support for X- items when storing data.

3860	   b.  Added new precondition to allow servers to reject queries on
3861	       unsupported X- items, and a new example.

3863	   c.  Added new text about always supporting X- in calendar-data.

3865	   d.  Created new section for PUT, COPY and MOVE preconditions.

3867	   e.  Report examples re-done with full listing of calendar data in
3868	       Appendix.

3870	   f.  Removed description of using UID, SUMMARY etc as resource name.

3872	   g.  Indicate that calendar object resource may contain only
3873	       overridden components.

3875	   h.  Add security consideration about not expose details in resource
3876	       names.

3878	   i.  Add constraint that free-busy-query can only be run on a
3879	       collection.

3881	   j.  Add preconditions for calendar-timezone property/elements in
3882	       MKCALENDAR, PROPPATCH and calendar-query REPORT.

3884	   k.  Fix principal-match example.

3886	C.2.  Changes in -09

3888	   a.   Numerous editorial changes.

3890	   b.   Removed the CALDAV:is-defined XML element.

3892	   c.   Removed section on privilege aggregation.

3894	   d.   Renamed the CALDAV:expand-recurrence-set XML element to CALDAV:
3895	        expand and clarified the server behavior.

3897	   e.   Renamed the CALDAV:calendar-component-restriction-set XML
3898	        element to CALDAV:supported-calendar-component-set.

3900	   f.   Renamed the CALDAV:calendar-restrictions XML element to CALDAV:
3901	        supported-calendar-data.

3903	   g.   Renamed some preconditions as "success conditions" instead of
3904	        "failure causes".  For instance, the precondition CALDAV:
3905	        calendar-collection-location-bad has been renamed to CALDAV:
3906	        calendar-collection-location-ok.

3908	   h.   Reordered some sections.

3910	   i.   Clarified the definition of CALDAV:time-range to specify that a
3911	        repeating VALARM component is said to intersect a given time
3912	        range if at least one of its trigger intersect the time range.

3914	   j.   Clarified that calendar object resources stored in calendar
3915	        collections MUST NOT specify the iCalendar METHOD property.

3917	   k.   Clarified that CALDAV:calendar-data XML element is not a WebDAV
3918	        property even though it is specified in the DAV:prop XML element
3919	        in both calendaring REPORT requests and responses.

3921	   l.   Clarified CALDAV:limit-recurrence-set with respect to the RANGE
3922	        parameter on the RECURRENCE-ID property.

3924	   m.   Changed the CALDAV:free-busy-query XML element to contain
3925	        exactly one CALDAV:time-range XML element.

3927	   n.   Changed many ELEMENT and ATTLIST declarations to comply with DTD
3928	        syntax.

3930	   o.   Changed XML element CALDAV:calendar-query to allow new XML
3931	        element CALDAV:timezone.

3933	   p.   Changed the XML elements CALDAV:time-range, CALDAV:expand and
3934	        CALDAV:limit-recurrence-set to only allow DATE-TIME with UTC
3935	        time values for the "start" and "end" attributes.

3937	   q.   Changed description of CALDAV:limit-recurrence-set to specify
3938	        that re-scheduled "overridden" recurrence instances whose
3939	        original scheduled time used to overlap the time range specified
3940	        by the "start" and "end" attribute should always be returned in
3941	        a REPORT response.

3943	   r.   Changed the description of the value of CALDAV:calendar-data XML
3944	        element to specify that the CR character (US-ASCII decimal 13)
3945	        MAY be omitted in the iCalendar object specified in this XML
3946	        element.

3948	   s.   Added specific requirements for entity tags support.

3950	   t.   Added more preconditions.

3952	   u.   Added further guidelines about finding calendars.

3954	   v.   Added XML element CALDAV:limit-freebusy-set to limit the set of
3955	        FREEBUSY property values returned in VFREEBUSY components.

3957	   w.   Added property CALDAV:calendar-timezone on calendar collections.

3959	   x.   Added XML element CALDAV:timezone to override the CALDAV:
3960	        calendar-timezone property for a given CALDAV:calendar-query
3961	        REPORT request.

3963	   y.   Added text on the conversion of "floating date" and "floating
3964	        time" values to date with UTC time values.

3966	   z.   Completed internationalization considerations section.

3968	   aa.  Completed security considerations section.

3970	C.3.  Changes in -08

3972	   a.  Removed statement that said that client SHOULD always request
3973	       DAV:getetag in calendar REPORTs.

3975	   b.  Removed redefiniton of DAV:response.

3977	   c.  Removed XML elements CALDAV:calendar-data-only.

3979	   d.  Removed resource type CALDAV:calendar-home.

3981	   e.  Moved the CALDAV:calendar-data element in the DAV:prop element in
3982	       requests, and in the DAV:propstat element in responses.

3984	   f.  Further defined the request body of MKCALENDAR to allow clients
3985	       to set properties at calendar collection creation time.

3987	   g.  Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set

3989	   h.  Clarified the fact that calendar collections may only contain
3990	       calendar object resources and ordinary collections.

3992	   i.  Clarified that calendar REPORTs should only be applied to
3993	       calendar object resources contained in calendar collections.

3995	   j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
3996	       calendar-restriction properties to always be protected.

3998	   k.  Changed to use existing postcondition DAV:needs-privileges
3999	       instead of a new CALDAV:insufficient-privilege postcondition.

4001	   l.  Added example for limit-recurrence-set.

4003	   m.  Added example for expand-recurrence-set.

4005	   n.  Moved CALDAV:calendar-address-set in the calendar-schedule draft
4006	       and renamed it to CALDAV:calendar-user-address-set.

4008	   o.  Added guidelines on attachments and alarms.

4010	C.4.  Changes in -07

4012	   a.  Various editorial changes.

4014	   b.  Added properties calendar-restrictions and calendar-component-
4015	       restriction-set on calendar collections.

4017	   c.  Added properties calendar-home-URL and calendar-address-set on
4018	       principal resources.

4020	   d.  Removed property calendar-URL on principal resources.

4022	   e.  Added pre- and postconditions to reports.

4024	   f.  Added new XML elements calendar-data-only and limit-recurrent-
4025	       set.

4027	   g.  Modified calendar-data XML element to support the attributes
4028	       content-type and version.

4030	   h.  Reorganised sections 3, 4, 5 & 6 into two sections and re-ordered
4031	       sub-sections.

4033	   i.  Added comment about client not setting a duplicate displayname.

4035	   j.  Removed three CalDAV OPTIONS requests.

4037	   k.  Changed "authenticated user" to "user" in various places.

4039	   l.  Rewrote section on calendar object resource restrictions for
4040	       better clarity.

4042	C.5.  Changes in -06

4044	   a.  Reworded section "Recurrence and the Data Model".

4046	   b.  Removed timezone collection feature.

4048	   c.  Removed ability for a server to return the Location header on a
4049	       successful PUT request.

4051	   d.  Clarified restrictions on calendar object resources contained in
4052	       calendar collections.

4054	   e.  Added preconditions on PUT in calendar collections.

4056	   f.  Added informative "Guidelines" section, with information on
4057	       locking and how to find calendar collections.

4059	   g.  Moved "Sychronization Operations" section in the "Guidelines"
4060	       section.

4062	C.6.  Changes in -05

4064	   a.  Removed a lot of non-normative text.

4066	   b.  Removed property promotion/demotion requirements.

4068	   c.  Removed calendar-owner and cal-scale properties.

4070	   d.  Removed 'ical' prefix/text from element names.

4072	   e.  Relaxed WebDAV Class 2 (locking) requirement to a MAY.

4074	   f.  Relaxed MKCALENDAR requirement to a SHOULD.

4076	   g.  Moved the XML Namespace section in the Introduction.

4078	   h.  Added CALDAV: prefix to CalDAV XML elements in the text.

4080	   i.  Added CALDAV:calendar-multiget report.

4082	   j.  Added CALDAV:free-busy-query report.

4084	   k.  Added CALDAV:calendar-description property.

4086	   l.  Changed CALDAV:calendar-query-result element name to CALDAV:
4087	       calendar-data

4089	   m.  Added description and examples of handling timezones.

4091	   n.  Added mandatory "start" and "end" attributes to the CALDAV:
4092	       expand-recurrence-set element.

4094	   o.  Added three CalDAV OPTIONS requests.

4096	   p.  Grouped XML Element declarations in a separate section.

4098	C.7.  Changes in -04

4100	   a.  Added a note about the HTTP Location response header.

4102	   b.  Added report calendar-query.

4104	   c.  Removed reports calendar-property-search and calendar-time-range.

4106	   d.  Removed section on CalDAV and timezones.

4108	   e.  Added requirement to return ETag on creation.

4110	   f.  Revised data model to remove sub-collections from calendar
4111	       collection.

4113	   g.  Added informative references section.

4115	   h.  Removed dependencies on DASL.

4117	C.8.  Changes in -03

4119	   a.  Removed Calendar Containers (simplification that doesn't seem to
4120	       remove much functionality)

4122	   b.  Added MKCALENDAR to create calendars and all sub-collections

4124	   c.  Added cal-scale property to calendars

4126	C.9.  Changes in -02

4128	   Basically still adding major sections of content:

4130	   a.  Defined new field values to the OPTIONS "DAV:" response header

4132	   b.  Added new resource properties

4134	   c.  Added new principal properties

4136	   d.  Added new SCHEDULE method and related headers

4138	   e.  Added new privileges for scheduling

4140	C.10.  Changes in -01

4142	   a.  Added section on privileges for calendaring, extending WebDAV ACL
4143	       privilege set

4145	   b.  Defined what to do with unrecognized properties in the bodies of
4146	       iCalendar events, with respect to property promotion/demotion

4148	Authors' Addresses

4150	   Cyrus Daboo

4152	   Email: cyrus@daboo.name

4154	   Bernard Desruisseaux
4155	   Oracle Corporation
4156	   600 Blvd. de Maisonneuve West
4157	   Suite 1900
4158	   Montreal, QC  H3A 3J2
4159	   CA

4161	   Email: bernard.desruisseaux@oracle.com
4162	   URI:   http://www.oracle.com/

4164	   Lisa Dusseault
4165	   Open Source Application Foundation
4166	   2064 Edgewood Dr.
4167	   Palo Alto, CA  94303
4168	   US

4170	   Email: lisa@osafoundation.org
4171	   URI:   http://www.osafoundation.org/

4173	Intellectual Property Statement

4175	   The IETF takes no position regarding the validity or scope of any
4176	   Intellectual Property Rights or other rights that might be claimed to
4177	   pertain to the implementation or use of the technology described in
4178	   this document or the extent to which any license under such rights
4179	   might or might not be available; nor does it represent that it has
4180	   made any independent effort to identify any such rights.  Information
4181	   on the procedures with respect to rights in RFC documents can be
4182	   found in BCP 78 and BCP 79.

4184	   Copies of IPR disclosures made to the IETF Secretariat and any
4185	   assurances of licenses to be made available, or the result of an
4186	   attempt made to obtain a general license or permission for the use of
4187	   such proprietary rights by implementers or users of this
4188	   specification can be obtained from the IETF on-line IPR repository at
4189	   http://www.ietf.org/ipr.

4191	   The IETF invites any interested party to bring to its attention any
4192	   copyrights, patents or patent applications, or other proprietary
4193	   rights that may cover technology that may be required to implement
4194	   this standard.  Please address the information to the IETF at
4195	   ietf-ipr@ietf.org.

4197	Disclaimer of Validity

4199	   This document and the information contained herein are provided on an
4200	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
4201	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
4202	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
4203	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
4204	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
4205	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

4207	Copyright Statement

4209	   Copyright (C) The Internet Society (2006).  This document is subject
4210	   to the rights, licenses and restrictions contained in BCP 78, and
4211	   except as set forth therein, the authors retain all their rights.

4213	Acknowledgment

4215	   Funding for the RFC Editor function is currently provided by the
4216	   Internet Society.