7 Network Working Group C. Daboo
8 Request for Comments: 4791 Apple
9 Category: Standards Track B. Desruisseaux
16 Calendaring Extensions to WebDAV (CalDAV)
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 Copyright (C) The IETF Trust (2007).
32 This document defines extensions to the Web Distributed Authoring and
33 Versioning (WebDAV) protocol to specify a standard way of accessing,
34 managing, and sharing calendaring and scheduling information based on
35 the iCalendar format. This document defines the "calendar-access"
58 Daboo, et al. Standards Track [Page 1]
60 RFC 4791 CalDAV March 2007
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
66 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
67 1.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5
68 1.3. Method Preconditions and Postconditions . . . . . . . . . 6
69 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6
70 3. Calendaring Data Model . . . . . . . . . . . . . . . . . . . . 7
71 3.1. Calendar Server . . . . . . . . . . . . . . . . . . . . . 7
72 3.2. Recurrence and the Data Model . . . . . . . . . . . . . . 8
73 4. Calendar Resources . . . . . . . . . . . . . . . . . . . . . . 9
74 4.1. Calendar Object Resources . . . . . . . . . . . . . . . . 9
75 4.2. Calendar Collection . . . . . . . . . . . . . . . . . . . 10
76 5. Calendar Access Feature . . . . . . . . . . . . . . . . . . . 11
77 5.1. Calendar Access Support . . . . . . . . . . . . . . . . . 11
78 5.1.1. Example: Using OPTIONS for the Discovery of
79 Calendar Access Support . . . . . . . . . . . . . . . 12
80 5.2. Calendar Collection Properties . . . . . . . . . . . . . . 12
81 5.2.1. CALDAV:calendar-description Property . . . . . . . . . 12
82 5.2.2. CALDAV:calendar-timezone Property . . . . . . . . . . 13
83 5.2.3. CALDAV:supported-calendar-component-set Property . . . 14
84 5.2.4. CALDAV:supported-calendar-data Property . . . . . . . 15
85 5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 16
86 5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 17
87 5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 18
88 5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 19
89 5.2.9. CALDAV:max-attendees-per-instance Property . . . . . . 19
90 5.2.10. Additional Precondition for PROPPATCH . . . . . . . . 20
91 5.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 20
92 5.3.1. MKCALENDAR Method . . . . . . . . . . . . . . . . . . 20
93 5.3.1.1. Status Codes . . . . . . . . . . . . . . . . . . . 22
94 5.3.1.2. Example: Successful MKCALENDAR Request . . . . . . 23
95 5.3.2. Creating Calendar Object Resources . . . . . . . . . . 25
96 5.3.2.1. Additional Preconditions for PUT, COPY, and
97 MOVE . . . . . . . . . . . . . . . . . . . . . . . 26
98 5.3.3. Non-Standard Components, Properties, and Parameters . 28
99 5.3.4. Calendar Object Resource Entity Tag . . . . . . . . . 28
100 6. Calendaring Access Control . . . . . . . . . . . . . . . . . . 29
101 6.1. Calendaring Privilege . . . . . . . . . . . . . . . . . . 29
102 6.1.1. CALDAV:read-free-busy Privilege . . . . . . . . . . . 29
103 6.2. Additional Principal Property . . . . . . . . . . . . . . 30
104 6.2.1. CALDAV:calendar-home-set Property . . . . . . . . . . 30
105 7. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . 31
106 7.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 31
107 7.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 31
108 7.3. Date and Floating Time . . . . . . . . . . . . . . . . . . 32
109 7.4. Time Range Filtering . . . . . . . . . . . . . . . . . . . 32
110 7.5. Searching Text: Collations . . . . . . . . . . . . . . . . 33
114 Daboo, et al. Standards Track [Page 2]
116 RFC 4791 CalDAV March 2007
119 7.5.1. CALDAV:supported-collation-set Property . . . . . . . 34
120 7.6. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 34
121 7.7. Non-Standard Components, Properties, and Parameters . . . 35
122 7.8. CALDAV:calendar-query REPORT . . . . . . . . . . . . . . . 36
123 7.8.1. Example: Partial Retrieval of Events by Time Range . . 38
124 7.8.2. Example: Partial Retrieval of Recurring Events . . . . 42
125 7.8.3. Example: Expanded Retrieval of Recurring Events . . . 45
126 7.8.4. Example: Partial Retrieval of Stored Free Busy
127 Components . . . . . . . . . . . . . . . . . . . . . . 48
128 7.8.5. Example: Retrieval of To-Dos by Alarm Time Range . . . 50
129 7.8.6. Example: Retrieval of Event by UID . . . . . . . . . . 51
130 7.8.7. Example: Retrieval of Events by PARTSTAT . . . . . . . 53
131 7.8.8. Example: Retrieval of Events Only . . . . . . . . . . 55
132 7.8.9. Example: Retrieval of All Pending To-Dos . . . . . . . 59
133 7.8.10. Example: Attempt to Query Unsupported Property . . . . 62
134 7.9. CALDAV:calendar-multiget REPORT . . . . . . . . . . . . . 63
135 7.9.1. Example: Successful CALDAV:calendar-multiget REPORT . 64
136 7.10. CALDAV:free-busy-query REPORT . . . . . . . . . . . . . . 66
137 7.10.1. Example: Successful CALDAV:free-busy-query REPORT . . 68
138 8. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 69
139 8.1. Client-to-Client Interoperability . . . . . . . . . . . . 69
140 8.2. Synchronization Operations . . . . . . . . . . . . . . . . 69
141 8.2.1. Use of Reports . . . . . . . . . . . . . . . . . . . . 69
142 8.2.1.1. Restrict the Time Range . . . . . . . . . . . . . 69
143 8.2.1.2. Synchronize by Time Range . . . . . . . . . . . . 70
144 8.2.1.3. Synchronization Process . . . . . . . . . . . . . 70
145 8.2.2. Restrict the Properties Returned . . . . . . . . . . . 72
146 8.3. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 72
147 8.4. Finding Calendars . . . . . . . . . . . . . . . . . . . . 72
148 8.5. Storing and Using Attachments . . . . . . . . . . . . . . 74
149 8.5.1. Inline Attachments . . . . . . . . . . . . . . . . . . 74
150 8.5.2. External Attachments . . . . . . . . . . . . . . . . . 75
151 8.6. Storing and Using Alarms . . . . . . . . . . . . . . . . . 76
152 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 77
153 9.1. CALDAV:calendar XML Element . . . . . . . . . . . . . . . 77
154 9.2. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . 77
155 9.3. CALDAV:mkcalendar-response XML Element . . . . . . . . . . 78
156 9.4. CALDAV:supported-collation XML Element . . . . . . . . . . 78
157 9.5. CALDAV:calendar-query XML Element . . . . . . . . . . . . 78
158 9.6. CALDAV:calendar-data XML Element . . . . . . . . . . . . . 79
159 9.6.1. CALDAV:comp XML Element . . . . . . . . . . . . . . . 80
160 9.6.2. CALDAV:allcomp XML Element . . . . . . . . . . . . . . 81
161 9.6.3. CALDAV:allprop XML Element . . . . . . . . . . . . . . 81
162 9.6.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 82
163 9.6.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 82
164 9.6.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 83
165 9.6.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 84
166 9.7. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 85
170 Daboo, et al. Standards Track [Page 3]
172 RFC 4791 CalDAV March 2007
175 9.7.1. CALDAV:comp-filter XML Element . . . . . . . . . . . . 85
176 9.7.2. CALDAV:prop-filter XML Element . . . . . . . . . . . . 86
177 9.7.3. CALDAV:param-filter XML Element . . . . . . . . . . . 87
178 9.7.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 88
179 9.7.5. CALDAV:text-match XML Element . . . . . . . . . . . . 88
180 9.8. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 89
181 9.9. CALDAV:time-range XML Element . . . . . . . . . . . . . . 90
182 9.10. CALDAV:calendar-multiget XML Element . . . . . . . . . . . 94
183 9.11. CALDAV:free-busy-query XML Element . . . . . . . . . . . . 95
184 10. Internationalization Considerations . . . . . . . . . . . . . 95
185 11. Security Considerations . . . . . . . . . . . . . . . . . . . 95
186 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
187 12.1. Namespace Registration . . . . . . . . . . . . . . . . . . 96
188 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 96
189 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97
190 14.1. Normative References . . . . . . . . . . . . . . . . . . . 97
191 14.2. Informative References . . . . . . . . . . . . . . . . . . 98
192 Appendix A. CalDAV Method Privilege Table (Normative) . . . . . . 99
193 Appendix B. Calendar Collections Used in the Examples . . . . . . 99
226 Daboo, et al. Standards Track [Page 4]
228 RFC 4791 CalDAV March 2007
233 The concept of using HTTP [RFC2616] and WebDAV [RFC2518] as a basis
234 for a calendar access protocol is by no means a new concept: it was
235 discussed in the IETF CALSCH working group as early as 1997 or 1998.
236 Several companies have implemented calendar access protocols using
237 HTTP to upload and download iCalendar [RFC2445] objects, and using
238 WebDAV to get listings of resources. However, those implementations
239 do not interoperate because there are many small and big decisions to
240 be made in how to model calendaring data as WebDAV resources, as well
241 as how to implement required features that aren't already part of
242 WebDAV. This document proposes a way to model calendar data in
243 WebDAV, with additional features to make an interoperable calendar
246 1.1. Notational Conventions
248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
250 document are to be interpreted as described in [RFC2119].
252 The term "protected" is used in the Conformance field of property
253 definitions as defined in Section 1.4.2 of [RFC3253].
255 When XML element types in the namespaces "DAV:" and
256 "urn:ietf:params:xml:ns:caldav" are referenced in this document
257 outside of the context of an XML fragment, the string "DAV:" and
258 "CALDAV:" will be prefixed to the element type names, respectively.
260 1.2. XML Namespaces and Processing
262 Definitions of XML elements in this document use XML element type
263 declarations (as found in XML Document Type Declarations), described
264 in Section 3.2 of [W3C.REC-xml-20060816].
266 The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
267 elements defined in this specification, its revisions, and related
268 CalDAV specifications. XML elements defined by individual
269 implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav"
270 namespace, and instead should use a namespace that they control.
272 The XML declarations used in this document do not include namespace
273 information. Thus, implementers must not use these declarations as
274 the only way to create valid CalDAV properties or to validate CalDAV
275 XML element types. Some of the declarations refer to XML elements
276 defined by WebDAV [RFC2518], which use the "DAV:" namespace.
277 Wherever such XML elements appear, they are explicitly prefixed with
278 "DAV:" to avoid confusion.
282 Daboo, et al. Standards Track [Page 5]
284 RFC 4791 CalDAV March 2007
287 Also note that some CalDAV XML element names are identical to WebDAV
288 XML element names, though their namespace differs. Care must be
289 taken not to confuse the two sets of names.
291 Processing of XML by CalDAV clients and servers MUST follow the rules
292 described in [RFC2518]; in particular, Section 14, and Appendix 3 of
295 1.3. Method Preconditions and Postconditions
297 A "precondition" of a method describes the state of the server that
298 must be true for that method to be performed. A "postcondition" of a
299 method describes the state of the server that must be true after that
300 method has been completed. If a method precondition or postcondition
301 for a request is not satisfied, the response status of the request
302 MUST either be 403 (Forbidden), if the request should not be repeated
303 because it will always fail, or 409 (Conflict), if it is expected
304 that the user might be able to resolve the conflict and resubmit the
307 In order to allow better client handling of 403 and 409 responses, a
308 distinct XML element type is associated with each method precondition
309 and postcondition of a request. When a particular precondition is
310 not satisfied or a particular postcondition cannot be achieved, the
311 appropriate XML element MUST be returned as the child of a top-level
312 DAV:error element in the response body, unless otherwise negotiated
315 2. Requirements Overview
317 This section lists what functionality is required of a CalDAV server.
318 To advertise support for CalDAV, a server:
320 o MUST support iCalendar [RFC2445] as a media type for the calendar
321 object resource format;
323 o MUST support WebDAV Class 1 [RFC2518] (note that [rfc2518bis]
324 describes clarifications to [RFC2518] that aid interoperability);
326 o MUST support WebDAV ACL [RFC3744] with the additional privilege
327 defined in Section 6.1 of this document;
329 o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
330 (note that [RFC2246] has been obsoleted by [RFC4346]);
332 o MUST support ETags [RFC2616] with additional requirements
333 specified in Section 5.3.4 of this document;
338 Daboo, et al. Standards Track [Page 6]
340 RFC 4791 CalDAV March 2007
343 o MUST support all calendaring reports defined in Section 7 of this
346 o MUST advertise support on all calendar collections and calendar
347 object resources for the calendaring reports in the DAV:supported-
348 report-set property, as defined in Versioning Extensions to WebDAV
351 In addition, a server:
353 o SHOULD support the MKCALENDAR method defined in Section 5.3.1 of
356 3. Calendaring Data Model
358 One of the features that has made WebDAV a successful protocol is its
359 firm data model. This makes it a useful framework for other
360 applications such as calendaring. This specification follows the
361 same pattern by developing all features based on a well-described
364 As a brief overview, a CalDAV calendar is modeled as a WebDAV
365 collection with a defined structure; each calendar collection
366 contains a number of resources representing calendar objects as its
367 direct child resource. Each resource representing a calendar object
368 (event, to-do, journal entry, or other calendar components) is called
369 a "calendar object resource". Each calendar object resource and each
370 calendar collection can be individually locked and have individual
371 WebDAV properties. Requirements derived from this model are provided
372 in Section 4.1 and Section 4.2.
376 A CalDAV server is a calendaring-aware engine combined with a WebDAV
377 repository. A WebDAV repository is a set of WebDAV collections,
378 containing other WebDAV resources, within a unified URL namespace.
379 For example, the repository "http://www.example.com/webdav/" may
380 contain WebDAV collections and resources, all of which have URLs
381 beginning with "http://www.example.com/webdav/". Note that the root
382 URL, "http://www.example.com/", may not itself be a WebDAV repository
383 (for example, if the WebDAV support is implemented through a servlet
384 or other Web server extension).
386 A WebDAV repository MAY include calendar data in some parts of its
387 URL namespace, and non-calendaring data in other parts.
389 A WebDAV repository can advertise itself as a CalDAV server if it
390 supports the functionality defined in this specification at any point
394 Daboo, et al. Standards Track [Page 7]
396 RFC 4791 CalDAV March 2007
399 within the root of the repository. That might mean that calendaring
400 data is spread throughout the repository and mixed with non-calendar
401 data in nearby collections (e.g., calendar data may be found in
402 /home/lisa/calendars/ as well as in /home/bernard/calendars/, and
403 non-calendar data in /home/lisa/contacts/). Or, it might mean that
404 calendar data can be found only in certain sections of the repository
405 (e.g., /calendar/). Calendaring features are only required in the
406 repository sections that are or contain calendar object resources.
407 Therefore, a repository confining calendar data to the /calendar/
408 collection would only need to support the CalDAV required features
409 within that collection.
411 The CalDAV server or repository is the canonical location for
412 calendar data and state information. Clients may submit requests to
413 change data or download data. Clients may store calendar objects
414 offline and attempt to synchronize at a later time. However, clients
415 MUST be prepared for calendar data on the server to change between
416 the time of last synchronization and when attempting an update, as
417 calendar collections may be shared and accessible via multiple
418 clients. Entity tags and other features make this possible.
420 3.2. Recurrence and the Data Model
422 Recurrence is an important part of the data model because it governs
423 how many resources are expected to exist. This specification models
424 a recurring calendar component and its recurrence exceptions as a
425 single resource. In this model, recurrence rules, recurrence dates,
426 exception rules, and exception dates are all part of the data in a
427 single calendar object resource. This model avoids problems of
428 limiting how many recurrence instances to store in the repository,
429 how to keep recurrence instances in sync with the recurring calendar
430 component, and how to link recurrence exceptions with the recurring
431 calendar component. It also results in less data to synchronize
432 between client and server, and makes it easier to make changes to all
433 recurrence instances or to a recurrence rule. It makes it easier to
434 create a recurring calendar component and to delete all recurrence
437 Clients are not forced to retrieve information about all recurrence
438 instances of a recurring component. The CALDAV:calendar-query and
439 CALDAV:calendar-multiget reports defined in this document allow
440 clients to retrieve only recurrence instances that overlap a given
450 Daboo, et al. Standards Track [Page 8]
452 RFC 4791 CalDAV March 2007
455 4. Calendar Resources
457 4.1. Calendar Object Resources
459 Calendar object resources contained in calendar collections MUST NOT
460 contain more than one type of calendar component (e.g., VEVENT,
461 VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
462 components, which MUST be specified for each unique TZID parameter
463 value specified in the iCalendar object. For instance, a calendar
464 object resource can contain one VEVENT component and one VTIMEZONE
465 component, but it cannot contain one VEVENT component and one VTODO
466 component. Instead, the VEVENT and VTODO components would have to be
467 stored in separate calendar object resources in the same collection.
469 Calendar object resources contained in calendar collections MUST NOT
470 specify the iCalendar METHOD property.
472 The UID property value of the calendar components contained in a
473 calendar object resource MUST be unique in the scope of the calendar
474 collection in which they are stored.
476 Calendar components in a calendar collection that have different UID
477 property values MUST be stored in separate calendar object resources.
479 Calendar components with the same UID property value, in a given
480 calendar collection, MUST be contained in the same calendar object
481 resource. This ensures that all components in a recurrence "set" are
482 contained in the same calendar object resource. It is possible for a
483 calendar object resource to just contain components that represent
484 "overridden" instances (ones that modify the behavior of a regular
485 instance, and thus include a RECURRENCE-ID property) without also
486 including the "master" recurring component (the one that defines the
487 recurrence "set" and does not contain any RECURRENCE-ID property).
506 Daboo, et al. Standards Track [Page 9]
508 RFC 4791 CalDAV March 2007
511 For example, given the following iCalendar object:
514 PRODID:-//Example Corp.//CalDAV Client//EN
518 SUMMARY:One-off Meeting
519 DTSTAMP:20041210T183904Z
520 DTSTART:20041207T120000Z
521 DTEND:20041207T130000Z
525 SUMMARY:Weekly Meeting
526 DTSTAMP:20041210T183838Z
527 DTSTART:20041206T120000Z
528 DTEND:20041206T130000Z
533 SUMMARY:Weekly Meeting
534 RECURRENCE-ID:20041213T120000Z
535 DTSTAMP:20041210T183838Z
536 DTSTART:20041213T130000Z
537 DTEND:20041213T140000Z
541 The VEVENT component with the UID value "1@example.com" would be
542 stored in its own calendar object resource. The two VEVENT
543 components with the UID value "2@example.com", which represent a
544 recurring event where one recurrence instance has been overridden,
545 would be stored in the same calendar object resource.
547 4.2. Calendar Collection
549 A calendar collection contains calendar object resources that
550 represent calendar components within a calendar. A calendar
551 collection is manifested to clients as a WebDAV resource collection
552 identified by a URL. A calendar collection MUST report the DAV:
553 collection and CALDAV:calendar XML elements in the value of the DAV:
554 resourcetype property. The element type declaration for CALDAV:
557 <!ELEMENT calendar EMPTY>
562 Daboo, et al. Standards Track [Page 10]
564 RFC 4791 CalDAV March 2007
567 A calendar collection can be created through provisioning (i.e.,
568 automatically created when a user's account is provisioned), or it
569 can be created with the MKCALENDAR method (see Section 5.3.1). This
570 method can be useful for a user to create additional calendars (e.g.,
571 soccer schedule) or for users to share a calendar (e.g., team events
572 or conference rooms). However, note that this document doesn't
573 define the purpose of extra calendar collections. Users must rely on
574 non-standard cues to find out what a calendar collection is for, or
575 use the CALDAV:calendar-description property defined in Section 5.2.1
576 to provide such a cue.
578 The following restrictions are applied to the resources within a
581 a. Calendar collections MUST only contain calendar object resources
582 and collections that are not calendar collections, i.e., the only
583 "top-level" non-collection resources allowed in a calendar
584 collection are calendar object resources. This ensures that
585 calendar clients do not have to deal with non-calendar data in a
586 calendar collection, though they do have to distinguish between
587 calendar object resources and collections when using standard
588 WebDAV techniques to examine the contents of a collection.
590 b. Collections contained in calendar collections MUST NOT contain
591 calendar collections at any depth, i.e., "nesting" of calendar
592 collections within other calendar collections at any depth is not
593 allowed. This specification does not define how collections
594 contained in a calendar collection are used or how they relate to
595 any calendar object resources contained in the calendar
598 Multiple calendar collections MAY be children of the same collection.
600 5. Calendar Access Feature
602 5.1. Calendar Access Support
604 A server supporting the features described in this document MUST
605 include "calendar-access" as a field in the DAV response header from
606 an OPTIONS request on any resource that supports any calendar
607 properties, reports, method, or privilege. A value of "calendar-
608 access" in the DAV response header MUST indicate that the server
609 supports all MUST level requirements specified in this document.
618 Daboo, et al. Standards Track [Page 11]
620 RFC 4791 CalDAV March 2007
623 5.1.1. Example: Using OPTIONS for the Discovery of Calendar Access
628 OPTIONS /home/bernard/calendars/ HTTP/1.1
629 Host: cal.example.com
634 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
635 Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
636 DAV: 1, 2, access-control, calendar-access
637 Date: Sat, 11 Nov 2006 09:32:12 GMT
640 In this example, the OPTIONS method returns the value "calendar-
641 access" in the DAV response header to indicate that the collection
642 "/home/bernard/calendars/" supports the properties, reports, method,
643 or privilege defined in this specification.
645 5.2. Calendar Collection Properties
647 This section defines properties for calendar collections.
649 5.2.1. CALDAV:calendar-description Property
651 Name: calendar-description
653 Namespace: urn:ietf:params:xml:ns:caldav
655 Purpose: Provides a human-readable description of the calendar
658 Conformance: This property MAY be defined on any calendar
659 collection. If defined, it MAY be protected and SHOULD NOT be
660 returned by a PROPFIND DAV:allprop request (as defined in Section
661 12.14.1 of [RFC2518]). An xml:lang attribute indicating the human
662 language of the description SHOULD be set for this property by
663 clients or through server provisioning. Servers MUST return any
664 xml:lang attribute if set for the property.
666 Description: If present, the property contains a description of the
667 calendar collection that is suitable for presentation to a user.
668 If not present, the client should assume no description for the
674 Daboo, et al. Standards Track [Page 12]
676 RFC 4791 CalDAV March 2007
681 <!ELEMENT calendar-description (#PCDATA)>
686 <C:calendar-description xml:lang="fr-CA"
687 xmlns:C="urn:ietf:params:xml:ns:caldav"
688 >Calendrier de Mathilde Desruisseaux</C:calendar-description>
690 5.2.2. CALDAV:calendar-timezone Property
692 Name: calendar-timezone
694 Namespace: urn:ietf:params:xml:ns:caldav
696 Purpose: Specifies a time zone on a calendar collection.
698 Conformance: This property SHOULD be defined on all calendar
699 collections. If defined, it SHOULD NOT be returned by a PROPFIND
700 DAV:allprop request (as defined in Section 12.14.1 of [RFC2518]).
702 Description: The CALDAV:calendar-timezone property is used to
703 specify the time zone the server should rely on to resolve "date"
704 values and "date with local time" values (i.e., floating time) to
705 "date with UTC time" values. The server will require this
706 information to determine if a calendar component scheduled with
707 "date" values or "date with local time" values overlaps a CALDAV:
708 time-range specified in a CALDAV:calendar-query REPORT. The
709 server will also require this information to compute the proper
710 FREEBUSY time period as "date with UTC time" in the VFREEBUSY
711 component returned in a response to a CALDAV:free-busy-query
712 REPORT request that takes into account calendar components
713 scheduled with "date" values or "date with local time" values. In
714 the absence of this property, the server MAY rely on the time zone
717 Note: The iCalendar data embedded within the CALDAV:calendar-
718 timezone XML element MUST follow the standard XML character data
719 encoding rules, including use of <, >, & etc. entity
720 encoding or the use of a <![CDATA[ ... ]]> construct. In the
721 later case, the iCalendar data cannot contain the character
722 sequence "]]>", which is the end delimiter for the CDATA section.
730 Daboo, et al. Standards Track [Page 13]
732 RFC 4791 CalDAV March 2007
737 <!ELEMENT calendar-timezone (#PCDATA)>
738 PCDATA value: an iCalendar object with exactly one VTIMEZONE
744 xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR
745 PRODID:-//Example Corp.//CalDAV Client//EN
749 LAST-MODIFIED:19870101T000000Z
751 DTSTART:19671029T020000
752 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
755 TZNAME:Eastern Standard Time (US & Canada)
758 DTSTART:19870405T020000
759 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
762 TZNAME:Eastern Daylight Time (US & Canada)
766 </C:calendar-timezone>
768 5.2.3. CALDAV:supported-calendar-component-set Property
770 Name: supported-calendar-component-set
772 Namespace: urn:ietf:params:xml:ns:caldav
774 Purpose: Specifies the calendar component types (e.g., VEVENT,
775 VTODO, etc.) that calendar object resources can contain in the
778 Conformance: This property MAY be defined on any calendar
779 collection. If defined, it MUST be protected and SHOULD NOT be
780 returned by a PROPFIND DAV:allprop request (as defined in Section
781 12.14.1 of [RFC2518]).
786 Daboo, et al. Standards Track [Page 14]
788 RFC 4791 CalDAV March 2007
791 Description: The CALDAV:supported-calendar-component-set property is
792 used to specify restrictions on the calendar component types that
793 calendar object resources may contain in a calendar collection.
794 Any attempt by the client to store calendar object resources with
795 component types not listed in this property, if it exists, MUST
796 result in an error, with the CALDAV:supported-calendar-component
797 precondition (Section 5.3.2.1) being violated. Since this
798 property is protected, it cannot be changed by clients using a
799 PROPPATCH request. However, clients can initialize the value of
800 this property when creating a new calendar collection with
801 MKCALENDAR. The empty-element tag <C:comp name="VTIMEZONE"/> MUST
802 only be specified if support for calendar object resources that
803 only contain VTIMEZONE components is provided or desired. Support
804 for VTIMEZONE components in calendar object resources that contain
805 VEVENT or VTODO components is always assumed. In the absence of
806 this property, the server MUST accept all component types, and the
807 client can assume that all component types are accepted.
811 <!ELEMENT supported-calendar-component-set (comp+)>
815 <C:supported-calendar-component-set
816 xmlns:C="urn:ietf:params:xml:ns:caldav">
817 <C:comp name="VEVENT"/>
818 <C:comp name="VTODO"/>
819 </C:supported-calendar-component-set>
821 5.2.4. CALDAV:supported-calendar-data Property
823 Name: supported-calendar-data
825 Namespace: urn:ietf:params:xml:ns:caldav
827 Purpose: Specifies what media types are allowed for calendar object
828 resources in a calendar collection.
830 Conformance: This property MAY be defined on any calendar
831 collection. If defined, it MUST be protected and SHOULD NOT be
832 returned by a PROPFIND DAV:allprop request (as defined in Section
833 12.14.1 of [RFC2518]).
835 Description: The CALDAV:supported-calendar-data property is used to
836 specify the media type supported for the calendar object resources
837 contained in a given calendar collection (e.g., iCalendar version
838 2.0). Any attempt by the client to store calendar object
842 Daboo, et al. Standards Track [Page 15]
844 RFC 4791 CalDAV March 2007
847 resources with a media type not listed in this property MUST
848 result in an error, with the CALDAV:supported-calendar-data
849 precondition (Section 5.3.2.1) being violated. In the absence of
850 this property, the server MUST only accept data with the media
851 type "text/calendar" and iCalendar version 2.0, and clients can
852 assume that the server will only accept this data.
856 <!ELEMENT supported-calendar-data (calendar-data+)>
860 <C:supported-calendar-data
861 xmlns:C="urn:ietf:params:xml:ns:caldav">
862 <C:calendar-data content-type="text/calendar" version="2.0"/>
863 </C:supported-calendar-data>
865 5.2.5. CALDAV:max-resource-size Property
867 Name: max-resource-size
869 Namespace: urn:ietf:params:xml:ns:caldav
871 Purpose: Provides a numeric value indicating the maximum size of a
872 resource in octets that the server is willing to accept when a
873 calendar object resource is stored in a calendar collection.
875 Conformance: This property MAY be defined on any calendar
876 collection. If defined, it MUST be protected and SHOULD NOT be
877 returned by a PROPFIND DAV:allprop request (as defined in Section
878 12.14.1 of [RFC2518]).
880 Description: The CALDAV:max-resource-size is used to specify a
881 numeric value that represents the maximum size in octets that the
882 server is willing to accept when a calendar object resource is
883 stored in a calendar collection. Any attempt to store a calendar
884 object resource exceeding this size MUST result in an error, with
885 the CALDAV:max-resource-size precondition (Section 5.3.2.1) being
886 violated. In the absence of this property, the client can assume
887 that the server will allow storing a resource of any reasonable
892 <!ELEMENT max-resource-size (#PCDATA)>
893 PCDATA value: a numeric value (positive integer)
898 Daboo, et al. Standards Track [Page 16]
900 RFC 4791 CalDAV March 2007
905 <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"
906 >102400</C:max-resource-size>
908 5.2.6. CALDAV:min-date-time Property
912 Namespace: urn:ietf:params:xml:ns:caldav
914 Purpose: Provides a DATE-TIME value indicating the earliest date and
915 time (in UTC) that the server is willing to accept for any DATE or
916 DATE-TIME value in a calendar object resource stored in a calendar
919 Conformance: This property MAY be defined on any calendar
920 collection. If defined, it MUST be protected and SHOULD NOT be
921 returned by a PROPFIND DAV:allprop request (as defined in Section
922 12.14.1 of [RFC2518]).
924 Description: The CALDAV:min-date-time is used to specify an
925 iCalendar DATE-TIME value in UTC that indicates the earliest
926 inclusive date that the server is willing to accept for any
927 explicit DATE or DATE-TIME value in a calendar object resource
928 stored in a calendar collection. Any attempt to store a calendar
929 object resource using a DATE or DATE-TIME value earlier than this
930 value MUST result in an error, with the CALDAV:min-date-time
931 precondition (Section 5.3.2.1) being violated. Note that servers
932 MUST accept recurring components that specify instances beyond
933 this limit, provided none of those instances have been overridden.
934 In that case, the server MAY simply ignore those instances outside
935 of the acceptable range when processing reports on the calendar
936 object resource. In the absence of this property, the client can
937 assume any valid iCalendar date may be used at least up to the
938 CALDAV:max-date-time value, if that is defined.
942 <!ELEMENT min-date-time (#PCDATA)>
943 PCDATA value: an iCalendar format DATE-TIME value in UTC
947 <C:min-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
948 >19000101T000000Z</C:min-date-time>
954 Daboo, et al. Standards Track [Page 17]
956 RFC 4791 CalDAV March 2007
959 5.2.7. CALDAV:max-date-time Property
963 Namespace: urn:ietf:params:xml:ns:caldav
965 Purpose: Provides a DATE-TIME value indicating the latest date and
966 time (in UTC) that the server is willing to accept for any DATE or
967 DATE-TIME value in a calendar object resource stored in a calendar
970 Conformance: This property MAY be defined on any calendar
971 collection. If defined, it MUST be protected and SHOULD NOT be
972 returned by a PROPFIND DAV:allprop request (as defined in Section
973 12.14.1 of [RFC2518]).
975 Description: The CALDAV:max-date-time is used to specify an
976 iCalendar DATE-TIME value in UTC that indicates the inclusive
977 latest date that the server is willing to accept for any date or
978 time value in a calendar object resource stored in a calendar
979 collection. Any attempt to store a calendar object resource using
980 a DATE or DATE-TIME value later than this value MUST result in an
981 error, with the CALDAV:max-date-time precondition
982 (Section 5.3.2.1) being violated. Note that servers MUST accept
983 recurring components that specify instances beyond this limit,
984 provided none of those instances have been overridden. In that
985 case, the server MAY simply ignore those instances outside of the
986 acceptable range when processing reports on the calendar object
987 resource. In the absence of this property, the client can assume
988 any valid iCalendar date may be used at least down to the CALDAV:
989 min-date-time value, if that is defined.
993 <!ELEMENT max-date-time (#PCDATA)>
994 PCDATA value: an iCalendar format DATE-TIME value in UTC
998 <C:max-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
999 >20491231T235959Z</C:max-date-time>
1010 Daboo, et al. Standards Track [Page 18]
1012 RFC 4791 CalDAV March 2007
1015 5.2.8. CALDAV:max-instances Property
1019 Namespace: urn:ietf:params:xml:ns:caldav
1021 Purpose: Provides a numeric value indicating the maximum number of
1022 recurrence instances that a calendar object resource stored in a
1023 calendar collection can generate.
1025 Conformance: This property MAY be defined on any calendar
1026 collection. If defined, it MUST be protected and SHOULD NOT be
1027 returned by a PROPFIND DAV:allprop request (as defined in Section
1028 12.14.1 of [RFC2518]).
1030 Description: The CALDAV:max-instances is used to specify a numeric
1031 value that indicates the maximum number of recurrence instances
1032 that a calendar object resource stored in a calendar collection
1033 can generate. Any attempt to store a calendar object resource
1034 with a recurrence pattern that generates more instances than this
1035 value MUST result in an error, with the CALDAV:max-instances
1036 precondition (Section 5.3.2.1) being violated. In the absence of
1037 this property, the client can assume that the server has no limits
1038 on the number of recurrence instances it can handle or expand.
1042 <!ELEMENT max-instances (#PCDATA)>
1043 PCDATA value: a numeric value (integer greater than zero)
1047 <C:max-instances xmlns:C="urn:ietf:params:xml:ns:caldav"
1048 >100</C:max-instances>
1050 5.2.9. CALDAV:max-attendees-per-instance Property
1052 Name: max-attendees-per-instance
1054 Namespace: urn:ietf:params:xml:ns:caldav
1056 Purpose: Provides a numeric value indicating the maximum number of
1057 ATTENDEE properties in any instance of a calendar object resource
1058 stored in a calendar collection.
1060 Conformance: This property MAY be defined on any calendar
1061 collection. If defined, it MUST be protected and SHOULD NOT be
1066 Daboo, et al. Standards Track [Page 19]
1068 RFC 4791 CalDAV March 2007
1071 returned by a PROPFIND DAV:allprop request (as defined in Section
1072 12.14.1 of [RFC2518]).
1074 Description: The CALDAV:max-attendees-per-instance is used to
1075 specify a numeric value that indicates the maximum number of
1076 iCalendar ATTENDEE properties on any one instance of a calendar
1077 object resource stored in a calendar collection. Any attempt to
1078 store a calendar object resource with more ATTENDEE properties per
1079 instance than this value MUST result in an error, with the CALDAV:
1080 max-attendees-per-instance precondition (Section 5.3.2.1) being
1081 violated. In the absence of this property, the client can assume
1082 that the server can handle any number of ATTENDEE properties in a
1087 <!ELEMENT max-attendees-per-instance (#PCDATA)>
1088 PCDATA value: a numeric value (integer greater than zero)
1092 <C:max-attendees-per-instance
1093 xmlns:C="urn:ietf:params:xml:ns:caldav"
1094 >25</C:max-attendees-per-instance>
1096 5.2.10. Additional Precondition for PROPPATCH
1098 This specification requires an additional Precondition for the
1099 PROPPATCH method. The precondition is:
1101 (CALDAV:valid-calendar-data): The time zone specified in CALDAV:
1102 calendar-timezone property MUST be a valid iCalendar object
1103 containing a single valid VTIMEZONE component.
1105 5.3. Creating Resources
1107 Calendar collections and calendar object resources may be created by
1108 either a CalDAV client or by the CalDAV server. This specification
1109 defines restrictions and a data model that both clients and servers
1110 MUST adhere to when manipulating such calendar data.
1112 5.3.1. MKCALENDAR Method
1114 An HTTP request using the MKCALENDAR method creates a new calendar
1115 collection resource. A server MAY restrict calendar collection
1116 creation to particular collections.
1122 Daboo, et al. Standards Track [Page 20]
1124 RFC 4791 CalDAV March 2007
1127 Support for MKCALENDAR on the server is only RECOMMENDED and not
1128 REQUIRED because some calendar stores only support one calendar per
1129 user (or principal), and those are typically pre-created for each
1130 account. However, servers and clients are strongly encouraged to
1131 support MKCALENDAR whenever possible to allow users to create
1132 multiple calendar collections to help organize their data better.
1134 Clients SHOULD use the DAV:displayname property for a human-readable
1135 name of the calendar. Clients can either specify the value of the
1136 DAV:displayname property in the request body of the MKCALENDAR
1137 request, or alternatively issue a PROPPATCH request to change the
1138 DAV:displayname property to the appropriate value immediately after
1139 issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV:
1140 displayname property to be the same as any other calendar collection
1141 at the same URI "level". When displaying calendar collections to
1142 users, clients SHOULD check the DAV:displayname property and use that
1143 value as the name of the calendar. In the event that the DAV:
1144 displayname property is empty, the client MAY use the last part of
1145 the calendar collection URI as the name; however, that path segment
1146 may be "opaque" and not represent any meaningful human-readable text.
1148 If a MKCALENDAR request fails, the server state preceding the request
1152 If a request body is included, it MUST be a CALDAV:mkcalendar XML
1153 element. Instruction processing MUST occur in the order
1154 instructions are received (i.e., from top to bottom).
1155 Instructions MUST either all be executed or none executed. Thus,
1156 if any error occurs during processing, all executed instructions
1157 MUST be undone and a proper error result returned. Instruction
1158 processing details can be found in the definition of the DAV:set
1159 instruction in Section 12.13.2 of [RFC2518].
1161 <!ELEMENT mkcalendar (DAV:set)>
1163 If a response body for a successful request is included, it MUST
1164 be a CALDAV:mkcalendar-response XML element.
1166 <!ELEMENT mkcalendar-response ANY>
1168 The response MUST include a Cache-Control:no-cache header.
1172 (DAV:resource-must-be-null): A resource MUST NOT exist at the
1178 Daboo, et al. Standards Track [Page 21]
1180 RFC 4791 CalDAV March 2007
1183 (CALDAV:calendar-collection-location-ok): The Request-URI MUST
1184 identify a location where a calendar collection can be created;
1186 (CALDAV:valid-calendar-data): The time zone specified in the
1187 CALDAV:calendar-timezone property MUST be a valid iCalendar object
1188 containing a single valid VTIMEZONE component;
1190 (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
1191 the current user on the parent collection of the Request-URI.
1195 (CALDAV:initialize-calendar-collection): A new calendar collection
1196 exists at the Request-URI. The DAV:resourcetype of the calendar
1197 collection MUST contain both DAV:collection and CALDAV:calendar
1200 5.3.1.1. Status Codes
1202 The following are examples of response codes one would expect to get
1203 in a response to a MKCALENDAR request. Note that this list is by no
1206 201 (Created) - The calendar collection resource was created in
1209 207 (Multi-Status) - The calendar collection resource was not
1210 created since one or more DAV:set instructions specified in the
1211 request body could not be processed successfully. The following
1212 are examples of response codes one would expect to be used in a
1213 207 (Multi-Status) response in this situation:
1215 403 (Forbidden) - The client, for reasons the server chooses
1216 not to specify, cannot alter one of the properties;
1218 409 (Conflict) - The client has provided a value whose
1219 semantics are not appropriate for the property. This includes
1220 trying to set read-only properties;
1222 424 (Failed Dependency) - The DAV:set instruction on the
1223 specified resource would have succeeded if it were not for the
1224 failure of another DAV:set instruction specified in the request
1227 423 (Locked) - The specified resource is locked and the client
1228 either is not a lock owner or the lock type requires a lock
1229 token to be submitted and the client did not submit it; and
1234 Daboo, et al. Standards Track [Page 22]
1236 RFC 4791 CalDAV March 2007
1239 507 (Insufficient Storage) - The server did not have sufficient
1240 space to record the property;
1242 403 (Forbidden) - This indicates at least one of two conditions:
1243 1) the server does not allow the creation of calendar collections
1244 at the given location in its namespace, or 2) the parent
1245 collection of the Request-URI exists but cannot accept members;
1247 409 (Conflict) - A collection cannot be made at the Request-URI
1248 until one or more intermediate collections have been created;
1250 415 (Unsupported Media Type) - The server does not support the
1251 request type of the body; and
1253 507 (Insufficient Storage) - The resource does not have sufficient
1254 space to record the state of the resource after the execution of
1257 5.3.1.2. Example: Successful MKCALENDAR Request
1259 This example creates a calendar collection called /home/lisa/
1260 calendars/events/ on the server cal.example.com with specific values
1261 for the properties DAV:displayname, CALDAV:calendar-description,
1262 CALDAV:supported-calendar-component-set, and CALDAV:calendar-
1290 Daboo, et al. Standards Track [Page 23]
1292 RFC 4791 CalDAV March 2007
1297 MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
1298 Host: cal.example.com
1299 Content-Type: application/xml; charset="utf-8"
1300 Content-Length: xxxx
1302 <?xml version="1.0" encoding="utf-8" ?>
1303 <C:mkcalendar xmlns:D="DAV:"
1304 xmlns:C="urn:ietf:params:xml:ns:caldav">
1307 <D:displayname>Lisa's Events</D:displayname>
1308 <C:calendar-description xml:lang="en"
1309 >Calendar restricted to events.</C:calendar-description>
1310 <C:supported-calendar-component-set>
1311 <C:comp name="VEVENT"/>
1312 </C:supported-calendar-component-set>
1313 <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR
1314 PRODID:-//Example Corp.//CalDAV Client//EN
1318 LAST-MODIFIED:19870101T000000Z
1320 DTSTART:19671029T020000
1321 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
1324 TZNAME:Eastern Standard Time (US & Canada)
1327 DTSTART:19870405T020000
1328 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
1331 TZNAME:Eastern Daylight Time (US & Canada)
1335 ]]></C:calendar-timezone>
1346 Daboo, et al. Standards Track [Page 24]
1348 RFC 4791 CalDAV March 2007
1353 HTTP/1.1 201 Created
1354 Cache-Control: no-cache
1355 Date: Sat, 11 Nov 2006 09:32:12 GMT
1358 5.3.2. Creating Calendar Object Resources
1360 Clients populate calendar collections with calendar object resources.
1361 The URL for each calendar object resource is entirely arbitrary and
1362 does not need to bear a specific relationship to the calendar object
1363 resource's iCalendar properties or other metadata. New calendar
1364 object resources MUST be created with a PUT request targeted at an
1365 unmapped URI. A PUT request targeted at a mapped URI updates an
1366 existing calendar object resource.
1368 When servers create new resources, it's not hard for the server to
1369 choose an unmapped URI. It's slightly tougher for clients, because a
1370 client might not want to examine all resources in the collection and
1371 might not want to lock the entire collection to ensure that a new
1372 resource isn't created with a name collision. However, there is an
1373 HTTP feature to mitigate this. If the client intends to create a new
1374 non-collection resource, such as a new VEVENT, the client SHOULD use
1375 the HTTP request header "If-None-Match: *" on the PUT request. The
1376 Request-URI on the PUT request MUST include the target collection,
1377 where the resource is to be created, plus the name of the resource in
1378 the last path segment. The "If-None-Match: *" request header ensures
1379 that the client will not inadvertently overwrite an existing resource
1380 if the last path segment turned out to already be used.
1402 Daboo, et al. Standards Track [Page 25]
1404 RFC 4791 CalDAV March 2007
1409 PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1
1411 Host: cal.example.com
1412 Content-Type: text/calendar
1413 Content-Length: xxxx
1417 PRODID:-//Example Corp.//CalDAV Client//EN
1419 UID:20010712T182145Z-123401@example.com
1420 DTSTAMP:20060712T182145Z
1421 DTSTART:20060714T170000Z
1422 DTEND:20060715T040000Z
1423 SUMMARY:Bastille Day Party
1429 HTTP/1.1 201 Created
1431 Date: Sat, 11 Nov 2006 09:32:12 GMT
1432 ETag: "123456789-000-111"
1434 The request to change an existing event is the same, but with a
1435 specific ETag in the "If-Match" header, rather than the "If-None-
1438 As indicated in Section 3.10 of [RFC2445], the URL of calendar object
1439 resources containing (an arbitrary set of) calendaring and scheduling
1440 information may be suffixed by ".ics", and the URL of calendar object
1441 resources containing free or busy time information may be suffixed by
1444 5.3.2.1. Additional Preconditions for PUT, COPY, and MOVE
1446 This specification creates additional Preconditions for PUT, COPY,
1447 and MOVE methods. These preconditions apply when a PUT operation of
1448 a calendar object resource into a calendar collection occurs, or when
1449 a COPY or MOVE operation of a calendar object resource into a
1450 calendar collection occurs, or when a COPY or MOVE operation occurs
1451 on a calendar collection.
1458 Daboo, et al. Standards Track [Page 26]
1460 RFC 4791 CalDAV March 2007
1463 The new preconditions are:
1465 (CALDAV:supported-calendar-data): The resource submitted in the
1466 PUT request, or targeted by a COPY or MOVE request, MUST be a
1467 supported media type (i.e., iCalendar) for calendar object
1470 (CALDAV:valid-calendar-data): The resource submitted in the PUT
1471 request, or targeted by a COPY or MOVE request, MUST be valid data
1472 for the media type being specified (i.e., MUST contain valid
1475 (CALDAV:valid-calendar-object-resource): The resource submitted in
1476 the PUT request, or targeted by a COPY or MOVE request, MUST obey
1477 all restrictions specified in Section 4.1 (e.g., calendar object
1478 resources MUST NOT contain more than one type of calendar
1479 component, calendar object resources MUST NOT specify the
1480 iCalendar METHOD property, etc.);
1482 (CALDAV:supported-calendar-component): The resource submitted in
1483 the PUT request, or targeted by a COPY or MOVE request, MUST
1484 contain a type of calendar component that is supported in the
1485 targeted calendar collection;
1487 (CALDAV:no-uid-conflict): The resource submitted in the PUT
1488 request, or targeted by a COPY or MOVE request, MUST NOT specify
1489 an iCalendar UID property value already in use in the targeted
1490 calendar collection or overwrite an existing calendar object
1491 resource with one that has a different UID property value.
1492 Servers SHOULD report the URL of the resource that is already
1493 making use of the same UID property value in the DAV:href element;
1495 <!ELEMENT no-uid-conflict (DAV:href)>
1497 (CALDAV:calendar-collection-location-ok): In a COPY or MOVE
1498 request, when the Request-URI is a calendar collection, the
1499 Destination-URI MUST identify a location where a calendar
1500 collection can be created;
1502 (CALDAV:max-resource-size): The resource submitted in the PUT
1503 request, or targeted by a COPY or MOVE request, MUST have an octet
1504 size less than or equal to the value of the CALDAV:max-resource-
1505 size property value (Section 5.2.5) on the calendar collection
1506 where the resource will be stored;
1508 (CALDAV:min-date-time): The resource submitted in the PUT request,
1509 or targeted by a COPY or MOVE request, MUST have all of its
1510 iCalendar DATE or DATE-TIME property values (for each recurring
1514 Daboo, et al. Standards Track [Page 27]
1516 RFC 4791 CalDAV March 2007
1519 instance) greater than or equal to the value of the CALDAV:min-
1520 date-time property value (Section 5.2.6) on the calendar
1521 collection where the resource will be stored;
1523 (CALDAV:max-date-time): The resource submitted in the PUT request,
1524 or targeted by a COPY or MOVE request, MUST have all of its
1525 iCalendar DATE or DATE-TIME property values (for each recurring
1526 instance) less than the value of the CALDAV:max-date-time property
1527 value (Section 5.2.7) on the calendar collection where the
1528 resource will be stored;
1530 (CALDAV:max-instances): The resource submitted in the PUT request,
1531 or targeted by a COPY or MOVE request, MUST generate a number of
1532 recurring instances less than or equal to the value of the CALDAV:
1533 max-instances property value (Section 5.2.8) on the calendar
1534 collection where the resource will be stored;
1536 (CALDAV:max-attendees-per-instance): The resource submitted in the
1537 PUT request, or targeted by a COPY or MOVE request, MUST have a
1538 number of ATTENDEE properties on any one instance less than or
1539 equal to the value of the CALDAV:max-attendees-per-instance
1540 property value (Section 5.2.9) on the calendar collection where
1541 the resource will be stored;
1543 5.3.3. Non-Standard Components, Properties, and Parameters
1545 iCalendar provides a "standard mechanism for doing non-standard
1546 things". This extension support allows implementers to make use of
1547 non-standard components, properties, and parameters whose names are
1548 prefixed with the text "X-".
1550 Servers MUST support the use of non-standard components, properties,
1551 and parameters in calendar object resources stored via the PUT
1554 Servers may need to enforce rules for their own "private" components,
1555 properties, or parameters, so servers MAY reject any attempt by the
1556 client to change those or use values for those outside of any
1557 restrictions the server may have. Servers SHOULD ensure that any
1558 "private" components, properties, or parameters it uses follow the
1559 convention of including a vendor id in the "X-" name, as described in
1560 Section 4.2 of [RFC2445], e.g., "X-ABC-PRIVATE".
1562 5.3.4. Calendar Object Resource Entity Tag
1564 The DAV:getetag property MUST be defined and set to a strong entity
1565 tag on all calendar object resources.
1570 Daboo, et al. Standards Track [Page 28]
1572 RFC 4791 CalDAV March 2007
1575 A response to a GET request targeted at a calendar object resource
1576 MUST contain an ETag response header field indicating the current
1577 value of the strong entity tag of the calendar object resource.
1579 Servers SHOULD return a strong entity tag (ETag header) in a PUT
1580 response when the stored calendar object resource is equivalent by
1581 octet equality to the calendar object resource submitted in the body
1582 of the PUT request. This allows clients to reliably use the returned
1583 strong entity tag for data synchronization purposes. For instance,
1584 the client can do a PROPFIND request on the stored calendar object
1585 resource and have the DAV:getetag property returned, and compare that
1586 value with the strong entity tag it received on the PUT response, and
1587 know that if they are equal, then the calendar object resource on the
1588 server has not been changed.
1590 In the case where the data stored by a server as a result of a PUT
1591 request is not equivalent by octet equality to the submitted calendar
1592 object resource, the behavior of the ETag response header is not
1593 specified here, with the exception that a strong entity tag MUST NOT
1594 be returned in the response. As a result, clients may need to
1595 retrieve the modified calendar object resource (and ETag) as a basis
1596 for further changes, rather than use the calendar object resource it
1597 had sent with the PUT request.
1599 6. Calendaring Access Control
1601 6.1. Calendaring Privilege
1603 CalDAV servers MUST support and adhere to the requirements of WebDAV
1604 ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set
1605 of privileges that can be applied to WebDAV collections and ordinary
1606 resources. CalDAV servers MUST also support the calendaring
1607 privilege defined in this section.
1609 6.1.1. CALDAV:read-free-busy Privilege
1611 Calendar users often wish to allow other users to see their busy time
1612 information, without viewing the other details of the calendar
1613 components (e.g., location, summary, attendees). This allows a
1614 significant amount of privacy while still allowing other users to
1615 schedule meetings at times when the user is likely to be free.
1617 The CALDAV:read-free-busy privilege controls which calendar
1618 collections, regular collections, and calendar object resources are
1619 examined when a CALDAV:free-busy-query REPORT request is processed
1620 (see Section 7.10). This privilege can be granted on calendar
1621 collections, regular collections, or calendar object resources.
1626 Daboo, et al. Standards Track [Page 29]
1628 RFC 4791 CalDAV March 2007
1631 Servers MUST support this privilege on all calendar collections,
1632 regular collections, and calendar object resources.
1635 <!ELEMENT read-free-busy EMPTY>
1637 The CALDAV:read-free-busy privilege MUST be aggregated in the DAV:
1638 read privilege. Servers MUST allow the CALDAV:read-free-busy to be
1639 granted without the DAV:read privilege being granted.
1641 Clients should note that when only the CALDAV:read-free-busy
1642 privilege has been granted on a resource, access to GET, HEAD,
1643 OPTIONS, and PROPFIND on the resource is not implied (those
1644 operations are governed by the DAV:read privilege).
1646 6.2. Additional Principal Property
1648 This section defines an additional property for WebDAV principal
1649 resources, as defined in [RFC3744].
1651 6.2.1. CALDAV:calendar-home-set Property
1653 Name: calendar-home-set
1655 Namespace: urn:ietf:params:xml:ns:caldav
1657 Purpose: Identifies the URL of any WebDAV collections that contain
1658 calendar collections owned by the associated principal resource.
1660 Conformance: This property SHOULD be defined on a principal
1661 resource. If defined, it MAY be protected and SHOULD NOT be
1662 returned by a PROPFIND DAV:allprop request (as defined in Section
1663 12.14.1 of [RFC2518]).
1665 Description: The CALDAV:calendar-home-set property is meant to allow
1666 users to easily find the calendar collections owned by the
1667 principal. Typically, users will group all the calendar
1668 collections that they own under a common collection. This
1669 property specifies the URL of collections that are either calendar
1670 collections or ordinary collections that have child or descendant
1671 calendar collections owned by the principal.
1675 <!ELEMENT calendar-home-set (DAV:href*)>
1682 Daboo, et al. Standards Track [Page 30]
1684 RFC 4791 CalDAV March 2007
1689 <C:calendar-home-set xmlns:D="DAV:"
1690 xmlns:C="urn:ietf:params:xml:ns:caldav">
1691 <D:href>http://cal.example.com/home/bernard/calendars/</D:href>
1692 </C:calendar-home-set>
1694 7. Calendaring Reports
1696 This section defines the reports that CalDAV servers MUST support on
1697 calendar collections and calendar object resources.
1699 CalDAV servers MUST advertise support for these reports on all
1700 calendar collections and calendar object resources with the DAV:
1701 supported-report-set property, defined in Section 3.1.5 of [RFC3253].
1702 CalDAV servers MAY also advertise support for these reports on
1703 ordinary collections.
1705 Some of these reports allow calendar data (from possibly multiple
1706 resources) to be returned.
1710 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
1711 extensible mechanism for obtaining information about one or more
1712 resources. Unlike the PROPFIND method, which returns the value of
1713 one or more named properties, the REPORT method can involve more
1714 complex processing. REPORT is valuable in cases where the server has
1715 access to all of the information needed to perform the complex
1716 request (such as a query), and where it would require multiple
1717 requests for the client to retrieve the information needed to perform
1720 CalDAV servers MUST support the DAV:expand-property REPORT defined in
1721 Section 3.8 of [RFC3253].
1723 7.2. Ordinary Collections
1725 Servers MAY support the reports defined in this document on ordinary
1726 collections (collections that are not calendar collections), in
1727 addition to calendar collections or calendar object resources. In
1728 computing responses to the reports on ordinary collections, servers
1729 MUST only consider calendar object resources contained in calendar
1730 collections that are targeted by the REPORT request, based on the
1731 value of the Depth request header.
1738 Daboo, et al. Standards Track [Page 31]
1740 RFC 4791 CalDAV March 2007
1743 7.3. Date and Floating Time
1745 iCalendar provides a way to specify DATE and DATE-TIME values that
1746 are not bound to any time zone in particular, hereafter called
1747 "floating date" and "floating time", respectively. These values are
1748 used to represent the same day, hour, minute, and second value,
1749 regardless of which time zone is being observed. For instance, the
1750 DATE value "20051111", represents November 11, 2005 in no specific
1751 time zone, while the DATE-TIME value "20051111T111100" represents
1752 November 11, 2005, at 11:11 A.M. in no specific time zone.
1754 CalDAV servers may need to convert "floating date" and "floating
1755 time" values in date with UTC time values in the processing of
1756 calendaring REPORT requests.
1758 For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the
1759 value of the CALDAV:timezone XML element, if specified as part of the
1760 request body, to perform the proper conversion of "floating date" and
1761 "floating time" values to date with UTC time values. If the CALDAV:
1762 timezone XML element is not specified in the request body, CalDAV
1763 servers MUST rely on the value of the CALDAV:calendar-timezone
1764 property, if defined, or else the CalDAV servers MAY rely on the time
1765 zone of their choice.
1767 For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on
1768 the value of the CALDAV:calendar-timezone property, if defined, to
1769 compute the proper FREEBUSY time period value as date with UTC time
1770 for calendar components scheduled with "floating date" or "floating
1771 time". If the CALDAV:calendar-timezone property is not defined,
1772 CalDAV servers MAY rely on the time zone of their choice.
1774 7.4. Time Range Filtering
1776 Some of the reports defined in this section can include a time range
1777 filter that is used to restrict the set of calendar object resources
1778 returned to just those that overlap the specified time range. The
1779 time range filter can be applied to a calendar component as a whole,
1780 or to specific calendar component properties with DATE or DATE-TIME
1783 To determine whether a calendar object resource matches the time
1784 range filter element, the start and end times for the targeted
1785 component or property are determined and then compared to the
1786 requested time range. If there is an overlap with the requested time
1787 range, then the calendar object resource matches the filter element.
1788 The rules defined in [RFC2445] for determining the actual start and
1789 end times of calendar components MUST be used, and these are fully
1790 enumerated in Section 9.9 of this document.
1794 Daboo, et al. Standards Track [Page 32]
1796 RFC 4791 CalDAV March 2007
1799 When such time range filtering is used, special consideration must be
1800 given to recurring calendar components, such as VEVENT and VTODO.
1801 The server MUST expand recurring components to determine whether any
1802 recurrence instances overlap the specified time range. If one or
1803 more recurrence instances overlap the time range, then the calendar
1804 object resource matches the filter element.
1806 7.5. Searching Text: Collations
1808 Some of the reports defined in this section do text matches of
1809 character strings provided by the client and are compared to stored
1810 calendar data. Since iCalendar data is, by default, encoded in the
1811 UTF-8 charset and may include characters outside the US-ASCII charset
1812 range in some property and parameter values, there is a need to
1813 ensure that text matching follows well-defined rules.
1815 To deal with this, this specification makes use of the IANA Collation
1816 Registry defined in [RFC4790] to specify collations that may be used
1817 to carry out the text comparison operations with a well-defined rule.
1819 The comparisons used in CalDAV are all "substring" matches, as per
1820 [RFC4790], Section 4.2. Collations supported by the server MUST
1821 support "substring" match operations.
1823 CalDAV servers are REQUIRED to support the "i;ascii-casemap" and
1824 "i;octet" collations, as described in [RFC4790], and MAY support
1827 Servers MUST advertise the set of collations that they support via
1828 the CALDAV:supported-collation-set property defined on any resource
1829 that supports reports that use collations.
1831 Clients MUST only use collations from the list advertised by the
1834 In the absence of a collation explicitly specified by the client, or
1835 if the client specifies the "default" collation identifier (as
1836 defined in [RFC4790], Section 3.1), the server MUST default to using
1837 "i;ascii-casemap" as the collation.
1839 Wildcards (as defined in [RFC4790], Section 3.2) MUST NOT be used in
1840 the collation identifier.
1842 If the client chooses a collation not supported by the server, the
1843 server MUST respond with a CALDAV:supported-collation precondition
1850 Daboo, et al. Standards Track [Page 33]
1852 RFC 4791 CalDAV March 2007
1855 7.5.1. CALDAV:supported-collation-set Property
1857 Name: supported-collation-set
1859 Namespace: urn:ietf:params:xml:ns:caldav
1861 Purpose: Identifies the set of collations supported by the server
1862 for text matching operations.
1864 Conformance: This property MUST be defined on any resource that
1865 supports a report that does text matching. If defined, it MUST be
1866 protected and SHOULD NOT be returned by a PROPFIND DAV:allprop
1867 request (as defined in Section 12.14.1 of [RFC2518]).
1869 Description: The CALDAV:supported-collation-set property contains
1870 zero or more CALDAV:supported-collation elements, which specify
1871 the collection identifiers of the collations supported by the
1876 <!ELEMENT supported-collation-set (supported-collation*)>
1878 <!ELEMENT supported-collation (#PCDATA)>
1882 <C:supported-collation-set
1883 xmlns:C="urn:ietf:params:xml:ns:caldav">
1884 <C:supported-collation>i;ascii-casemap</C:supported-collation>
1885 <C:supported-collation>i;octet</C:supported-collation>
1886 </C:supported-collation-set>
1888 7.6. Partial Retrieval
1890 Some calendaring reports defined in this document allow partial
1891 retrieval of calendar object resources. A CalDAV client can specify
1892 what information to return in the body of a calendaring REPORT
1895 A CalDAV client can request particular WebDAV property values, all
1896 WebDAV property values, or a list of the names of the resource's
1897 WebDAV properties. A CalDAV client can also request calendar data to
1898 be returned and specify whether all calendar components and
1899 properties should be returned, or only particular ones. See CALDAV:
1900 calendar-data in Section 9.6.
1906 Daboo, et al. Standards Track [Page 34]
1908 RFC 4791 CalDAV March 2007
1911 By default, the returned calendar data will include the component
1912 that defines the recurrence set, referred to as the "master
1913 component", as well as the components that define exceptions to the
1914 recurrence set, referred to as the "overridden components".
1916 A CalDAV client that is only interested in the recurrence instances
1917 that overlap a specified time range can request to receive only the
1918 "master component", along with the "overridden components" that
1919 impact the specified time range, and thus, limit the data returned by
1920 the server (see CALDAV:limit-recurrence-set in Section 9.6.6). An
1921 overridden component impacts a time range if its current start and
1922 end times overlap the time range, or if the original start and end
1923 times -- the ones that would have been used if the instance were not
1924 overridden -- overlap the time range, or if it affects other
1925 instances that overlap the time range.
1927 A CalDAV client with no support for recurrence properties (i.e.,
1928 EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components,
1929 or a client unwilling to perform recurrence expansion because of
1930 limited processing capability, can request to receive only the
1931 recurrence instances that overlap a specified time range as separate
1932 calendar components that each define exactly one recurrence instance
1933 (see CALDAV:expand in Section 9.6.5.)
1935 Finally, in the case of VFREEBUSY components, a CalDAV client can
1936 request to receive only the FREEBUSY property values that overlap a
1937 specified time range (see CALDAV:limit-freebusy-set in
1940 7.7. Non-Standard Components, Properties, and Parameters
1942 Servers MUST support the use of non-standard component, property, or
1943 parameter names in the CALDAV:calendar-data XML element in
1944 calendaring REPORT requests to allow clients to request that non-
1945 standard components, properties, and parameters be returned in the
1946 calendar data provided in the response.
1948 Servers MAY support the use of non-standard component, property, or
1949 parameter names in the CALDAV:comp-filter, CALDAV:prop-filter, and
1950 CALDAV:param-filter XML elements specified in the CALDAV:filter XML
1951 element of calendaring REPORT requests.
1953 Servers MUST fail with the CALDAV:supported-filter precondition if a
1954 calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop-
1955 filter, or CALDAV:param-filter XML element that makes reference to a
1956 non-standard component, property, or parameter name on which the
1957 server does not support queries.
1962 Daboo, et al. Standards Track [Page 35]
1964 RFC 4791 CalDAV March 2007
1967 7.8. CALDAV:calendar-query REPORT
1969 The CALDAV:calendar-query REPORT performs a search for all calendar
1970 object resources that match a specified filter. The response of this
1971 report will contain all the WebDAV properties and calendar object
1972 resource data specified in the request. In the case of the CALDAV:
1973 calendar-data XML element, one can explicitly specify the calendar
1974 components and properties that should be returned in the calendar
1975 object resource data that matches the filter.
1977 The format of this report is modeled on the PROPFIND method. The
1978 request and response bodies of the CALDAV:calendar-query REPORT use
1979 XML elements that are also used by PROPFIND. In particular, the
1980 request can include XML elements to request WebDAV properties to be
1981 returned. When that occurs, the response should follow the same
1982 behavior as PROPFIND with respect to the DAV:multistatus response
1983 elements used to return specific property results. For instance, a
1984 request to retrieve the value of a property that does not exist is an
1985 error and MUST be noted with a response XML element that contains a
1986 404 (Not Found) status value.
1988 Support for the CALDAV:calendar-query REPORT is REQUIRED.
1992 The request body MUST be a CALDAV:calendar-query XML element, as
1993 defined in Section 9.5.
1995 The request MAY include a Depth header. If no Depth header is
1996 included, Depth:0 is assumed.
1998 The response body for a successful request MUST be a DAV:
1999 multistatus XML element (i.e., the response uses the same format
2000 as the response for PROPFIND). In the case where there are no
2001 response elements, the returned DAV:multistatus XML element is
2004 The response body for a successful CALDAV:calendar-query REPORT
2005 request MUST contain a DAV:response element for each iCalendar
2006 object that matched the search filter. Calendar data is being
2007 returned in the CALDAV:calendar-data XML element inside the DAV:
2008 propstat XML element.
2012 (CALDAV:supported-calendar-data): The attributes "content-type"
2013 and "version" of the CALDAV:calendar-data XML element (see
2018 Daboo, et al. Standards Track [Page 36]
2020 RFC 4791 CalDAV March 2007
2023 Section 9.6) specify a media type supported by the server for
2024 calendar object resources.
2026 (CALDAV:valid-filter): The CALDAV:filter XML element (see
2027 Section 9.7) specified in the REPORT request MUST be valid. For
2028 instance, a CALDAV:filter cannot nest a <C:comp name="VEVENT">
2029 element in a <C:comp name="VTODO"> element, and a CALDAV:filter
2030 cannot nest a <C:time-range start="..." end="..."> element in a
2031 <C:prop name="SUMMARY"> element.
2033 (CALDAV:supported-filter): The CALDAV:comp-filter (see
2034 Section 9.7.1), CALDAV:prop-filter (see Section 9.7.2), and
2035 CALDAV:param-filter (see Section 9.7.3) XML elements used in the
2036 CALDAV:filter XML element (see Section 9.7) in the REPORT request
2037 only make reference to components, properties, and parameters for
2038 which queries are supported by the server, i.e., if the CALDAV:
2039 filter element attempts to reference an unsupported component,
2040 property, or parameter, this precondition is violated. Servers
2041 SHOULD report the CALDAV:comp-filter, CALDAV:prop-filter, or
2042 CALDAV:param-filter for which it does not provide support.
2044 <!ELEMENT supported-filter (comp-filter*,
2048 (CALDAV:valid-calendar-data): The time zone specified in the
2049 REPORT request MUST be a valid iCalendar object containing a
2050 single valid VTIMEZONE component.
2052 (CALDAV:min-date-time): Any XML element specifying a range of time
2053 MUST have its start or end DATE or DATE-TIME values greater than
2054 or equal to the value of the CALDAV:min-date-time property value
2055 (Section 5.2.6) on the calendar collections being targeted by the
2058 (CALDAV:max-date-time): Any XML element specifying a range of time
2059 MUST have its start or end DATE or DATE-TIME values less than or
2060 equal to the value of the CALDAV:max-date-time property value
2061 (Section 5.2.7) on the calendar collections being targeted by the
2064 (CALDAV:supported-collation): Any XML attribute specifying a
2065 collation MUST specify a collation supported by the server as
2066 described in Section 7.5.
2074 Daboo, et al. Standards Track [Page 37]
2076 RFC 4791 CalDAV March 2007
2081 (DAV:number-of-matches-within-limits): The number of matching
2082 calendar object resources must fall within server-specific,
2083 predefined limits. For example, this condition might be triggered
2084 if a search specification would cause the return of an extremely
2085 large number of responses.
2087 7.8.1. Example: Partial Retrieval of Events by Time Range
2089 In this example, the client requests the server to return specific
2090 components and properties of the VEVENT components that overlap the
2091 time range from January 4, 2006, at 00:00:00 A.M. UTC to January 5,
2092 2006, at 00:00:00 A.M. UTC. In addition, the DAV:getetag property is
2093 also requested and returned as part of the response. Note that the
2094 first calendar object returned is a recurring event whose first
2095 instance lies outside the requested time range, but whose third
2096 instance does overlap the time range. Note that due to the CALDAV:
2097 calendar-data element restrictions, the DTSTAMP property in VEVENT
2098 components has not been returned, and the only property returned in
2099 the VCALENDAR object is VERSION.
2101 See Appendix B for the calendar data being targeted by this example.
2130 Daboo, et al. Standards Track [Page 38]
2132 RFC 4791 CalDAV March 2007
2137 REPORT /bernard/work/ HTTP/1.1
2138 Host: cal.example.com
2140 Content-Type: application/xml; charset="utf-8"
2141 Content-Length: xxxx
2143 <?xml version="1.0" encoding="utf-8" ?>
2144 <C:calendar-query xmlns:D="DAV:"
2145 xmlns:C="urn:ietf:params:xml:ns:caldav">
2149 <C:comp name="VCALENDAR">
2150 <C:prop name="VERSION"/>
2151 <C:comp name="VEVENT">
2152 <C:prop name="SUMMARY"/>
2153 <C:prop name="UID"/>
2154 <C:prop name="DTSTART"/>
2155 <C:prop name="DTEND"/>
2156 <C:prop name="DURATION"/>
2157 <C:prop name="RRULE"/>
2158 <C:prop name="RDATE"/>
2159 <C:prop name="EXRULE"/>
2160 <C:prop name="EXDATE"/>
2161 <C:prop name="RECURRENCE-ID"/>
2163 <C:comp name="VTIMEZONE"/>
2168 <C:comp-filter name="VCALENDAR">
2169 <C:comp-filter name="VEVENT">
2170 <C:time-range start="20060104T000000Z"
2171 end="20060105T000000Z"/>
2179 HTTP/1.1 207 Multi-Status
2180 Date: Sat, 11 Nov 2006 09:32:12 GMT
2181 Content-Type: application/xml; charset="utf-8"
2182 Content-Length: xxxx
2186 Daboo, et al. Standards Track [Page 39]
2188 RFC 4791 CalDAV March 2007
2191 <?xml version="1.0" encoding="utf-8" ?>
2192 <D:multistatus xmlns:D="DAV:"
2193 xmlns:C="urn:ietf:params:xml:ns:caldav">
2195 <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
2198 <D:getetag>"fffff-abcd2"</D:getetag>
2199 <C:calendar-data>BEGIN:VCALENDAR
2202 LAST-MODIFIED:20040110T032845Z
2205 DTSTART:20000404T020000
2206 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2212 DTSTART:20001026T020000
2213 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2220 DTSTART;TZID=US/Eastern:20060102T120000
2222 RRULE:FREQ=DAILY;COUNT=5
2224 UID:00959BC664CA650E933C892C@example.com
2227 DTSTART;TZID=US/Eastern:20060104T140000
2229 RECURRENCE-ID;TZID=US/Eastern:20060104T120000
2230 SUMMARY:Event #2 bis
2231 UID:00959BC664CA650E933C892C@example.com
2234 DTSTART;TZID=US/Eastern:20060106T140000
2236 RECURRENCE-ID;TZID=US/Eastern:20060106T120000
2237 SUMMARY:Event #2 bis bis
2238 UID:00959BC664CA650E933C892C@example.com
2242 Daboo, et al. Standards Track [Page 40]
2244 RFC 4791 CalDAV March 2007
2251 <D:status>HTTP/1.1 200 OK</D:status>
2255 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
2258 <D:getetag>"fffff-abcd3"</D:getetag>
2259 <C:calendar-data>BEGIN:VCALENDAR
2261 PRODID:-//Example Corp.//CalDAV Client//EN
2263 LAST-MODIFIED:20040110T032845Z
2266 DTSTART:20000404T020000
2267 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2273 DTSTART:20001026T020000
2274 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2281 DTSTART;TZID=US/Eastern:20060104T100000
2284 UID:DC6C50A017428C5216A2F1CD@example.com
2289 <D:status>HTTP/1.1 200 OK</D:status>
2298 Daboo, et al. Standards Track [Page 41]
2300 RFC 4791 CalDAV March 2007
2303 7.8.2. Example: Partial Retrieval of Recurring Events
2305 In this example, the client requests the server to return VEVENT
2306 components that overlap the time range from January 3, 2006, at 00:
2307 00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC. Use of the
2308 CALDAV:limit-recurrence-set element causes the server to only return
2309 overridden recurrence components that overlap the time range
2310 specified in that element or that affect other instances that overlap
2311 the time range (e.g., in the case of a THISANDFUTURE behavior). In
2312 this example, the first overridden component in the matching resource
2313 is returned, but the second one is not.
2315 See Appendix B for the calendar data being targeted by this example.
2319 REPORT /bernard/work/ HTTP/1.1
2320 Host: cal.example.com
2322 Content-Type: application/xml; charset="utf-8"
2323 Content-Length: xxxx
2325 <?xml version="1.0" encoding="utf-8" ?>
2326 <C:calendar-query xmlns:D="DAV:"
2327 xmlns:C="urn:ietf:params:xml:ns:caldav">
2330 <C:limit-recurrence-set start="20060103T000000Z"
2331 end="20060105T000000Z"/>
2335 <C:comp-filter name="VCALENDAR">
2336 <C:comp-filter name="VEVENT">
2337 <C:time-range start="20060103T000000Z"
2338 end="20060105T000000Z"/>
2346 HTTP/1.1 207 Multi-Status
2347 Date: Sat, 11 Nov 2006 09:32:12 GMT
2348 Content-Type: application/xml; charset="utf-8"
2349 Content-Length: xxxx
2354 Daboo, et al. Standards Track [Page 42]
2356 RFC 4791 CalDAV March 2007
2359 <?xml version="1.0" encoding="utf-8" ?>
2360 <D:multistatus xmlns:D="DAV:"
2361 xmlns:C="urn:ietf:params:xml:ns:caldav">
2363 <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
2366 <D:getetag>"fffff-abcd2"</D:getetag>
2367 <C:calendar-data>BEGIN:VCALENDAR
2369 PRODID:-//Example Corp.//CalDAV Client//EN
2371 LAST-MODIFIED:20040110T032845Z
2374 DTSTART:20000404T020000
2375 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2381 DTSTART:20001026T020000
2382 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2389 DTSTAMP:20060206T001121Z
2390 DTSTART;TZID=US/Eastern:20060102T120000
2392 RRULE:FREQ=DAILY;COUNT=5
2394 UID:00959BC664CA650E933C892C@example.com
2397 DTSTAMP:20060206T001121Z
2398 DTSTART;TZID=US/Eastern:20060104T140000
2400 RECURRENCE-ID;TZID=US/Eastern:20060104T120000
2401 SUMMARY:Event #2 bis
2402 UID:00959BC664CA650E933C892C@example.com
2410 Daboo, et al. Standards Track [Page 43]
2412 RFC 4791 CalDAV March 2007
2415 <D:status>HTTP/1.1 200 OK</D:status>
2419 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
2422 <D:getetag>"fffff-abcd3"</D:getetag>
2423 <C:calendar-data>BEGIN:VCALENDAR
2425 PRODID:-//Example Corp.//CalDAV Client//EN
2427 LAST-MODIFIED:20040110T032845Z
2430 DTSTART:20000404T020000
2431 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2437 DTSTART:20001026T020000
2438 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2445 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
2446 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
2447 DTSTAMP:20060206T001220Z
2448 DTSTART;TZID=US/Eastern:20060104T100000
2450 LAST-MODIFIED:20060206T001330Z
2451 ORGANIZER:mailto:cyrus@example.com
2455 UID:DC6C50A017428C5216A2F1CD@example.com
2456 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
2461 <D:status>HTTP/1.1 200 OK</D:status>
2466 Daboo, et al. Standards Track [Page 44]
2468 RFC 4791 CalDAV March 2007
2474 7.8.3. Example: Expanded Retrieval of Recurring Events
2476 In this example, the client requests the server to return VEVENT
2477 components that overlap the time range from January 2, 2006, at 00:
2478 00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC and to return
2479 recurring calendar components expanded into individual recurrence
2480 instance calendar components. Use of the CALDAV:expand element
2481 causes the server to only return overridden recurrence instances that
2482 overlap the time range specified in that element.
2484 See Appendix B for the calendar data being targeted by this example.
2488 REPORT /bernard/work/ HTTP/1.1
2489 Host: cal.example.com
2491 Content-Type: application/xml; charset="utf-8"
2492 Content-Length: xxxx
2494 <?xml version="1.0" encoding="utf-8" ?>
2495 <C:calendar-query xmlns:D="DAV:"
2496 xmlns:C="urn:ietf:params:xml:ns:caldav">
2499 <C:expand start="20060103T000000Z"
2500 end="20060105T000000Z"/>
2504 <C:comp-filter name="VCALENDAR">
2505 <C:comp-filter name="VEVENT">
2506 <C:time-range start="20060103T000000Z"
2507 end="20060105T000000Z"/>
2515 HTTP/1.1 207 Multi-Status
2516 Date: Sat, 11 Nov 2006 09:32:12 GMT
2517 Content-Type: application/xml; charset="utf-8"
2518 Content-Length: xxxx
2522 Daboo, et al. Standards Track [Page 45]
2524 RFC 4791 CalDAV March 2007
2527 <?xml version="1.0" encoding="utf-8" ?>
2528 <D:multistatus xmlns:D="DAV:"
2529 xmlns:C="urn:ietf:params:xml:ns:caldav">
2531 <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
2534 <D:getetag>"fffff-abcd2"</D:getetag>
2535 <C:calendar-data>BEGIN:VCALENDAR
2537 PRODID:-//Example Corp.//CalDAV Client//EN
2539 DTSTAMP:20060206T001121Z
2540 DTSTART:20060103T170000
2542 RECURRENCE-ID:20060103T170000
2544 UID:00959BC664CA650E933C892C@example.com
2547 DTSTAMP:20060206T001121Z
2548 DTSTART:20060104T190000
2550 RECURRENCE-ID:20060104T170000
2551 SUMMARY:Event #2 bis
2552 UID:00959BC664CA650E933C892C@example.com
2557 <D:status>HTTP/1.1 200 OK</D:status>
2561 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
2564 <D:getetag>"fffff-abcd3"</D:getetag>
2565 <C:calendar-data>BEGIN:VCALENDAR
2567 PRODID:-//Example Corp.//CalDAV Client//EN
2569 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
2570 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
2571 DTSTAMP:20060206T001220Z
2572 DTSTART:20060104T150000
2574 LAST-MODIFIED:20060206T001330Z
2578 Daboo, et al. Standards Track [Page 46]
2580 RFC 4791 CalDAV March 2007
2583 ORGANIZER:mailto:cyrus@example.com
2587 UID:DC6C50A017428C5216A2F1CD@example.com
2588 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
2593 <D:status>HTTP/1.1 200 OK</D:status>
2634 Daboo, et al. Standards Track [Page 47]
2636 RFC 4791 CalDAV March 2007
2639 7.8.4. Example: Partial Retrieval of Stored Free Busy Components
2641 In this example, the client requests the server to return the
2642 VFREEBUSY components that have free busy information that overlap the
2643 time range from January 2, 2006, at 00:00:00 A.M. UTC (inclusively)
2644 to January 3, 2006, at 00:00:00 A.M. UTC (exclusively). Use of the
2645 CALDAV:limit-freebusy-set element causes the server to only return
2646 the FREEBUSY property values that overlap the time range specified in
2647 that element. Note that this is not an example of discovering when
2648 the calendar owner is busy.
2650 See Appendix B for the calendar data being targeted by this example.
2654 REPORT /bernard/work/ HTTP/1.1
2655 Host: cal.example.com
2657 Content-Type: application/xml; charset="utf-8"
2658 Content-Length: xxxx
2660 <?xml version="1.0" encoding="utf-8" ?>
2661 <C:calendar-query xmlns:D="DAV:"
2662 xmlns:C="urn:ietf:params:xml:ns:caldav">
2665 <C:limit-freebusy-set start="20060102T000000Z"
2666 end="20060103T000000Z"/>
2670 <C:comp-filter name="VCALENDAR">
2671 <C:comp-filter name="VFREEBUSY">
2672 <C:time-range start="20060102T000000Z"
2673 end="20060103T000000Z"/>
2690 Daboo, et al. Standards Track [Page 48]
2692 RFC 4791 CalDAV March 2007
2697 HTTP/1.1 207 Multi-Status
2698 Date: Sat, 11 Nov 2006 09:32:12 GMT
2699 Content-Type: application/xml; charset="utf-8"
2700 Content-Length: xxxx
2702 <?xml version="1.0" encoding="utf-8" ?>
2703 <D:multistatus xmlns:D="DAV:"
2704 xmlns:C="urn:ietf:params:xml:ns:caldav">
2706 <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
2709 <D:getetag>"fffff-abcd8"</D:getetag>
2710 <C:calendar-data>BEGIN:VCALENDAR
2712 PRODID:-//Example Corp.//CalDAV Client//EN
2714 ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
2715 UID:76ef34-54a3d2@example.com
2716 DTSTAMP:20050530T123421Z
2717 DTSTART:20060101T100000Z
2718 DTEND:20060108T100000Z
2719 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
2724 <D:status>HTTP/1.1 200 OK</D:status>
2746 Daboo, et al. Standards Track [Page 49]
2748 RFC 4791 CalDAV March 2007
2751 7.8.5. Example: Retrieval of To-Dos by Alarm Time Range
2753 In this example, the client requests the server to return the VTODO
2754 components that have an alarm trigger scheduled in the specified time
2757 See Appendix B for the calendar data being targeted by this example.
2761 REPORT /bernard/work/ HTTP/1.1
2762 Host: cal.example.com
2764 Content-Type: application/xml; charset="utf-8"
2765 Content-Length: xxxx
2767 <?xml version="1.0" encoding="utf-8" ?>
2768 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2769 <D:prop xmlns:D="DAV:">
2774 <C:comp-filter name="VCALENDAR">
2775 <C:comp-filter name="VTODO">
2776 <C:comp-filter name="VALARM">
2777 <C:time-range start="20060106T100000Z"
2778 end="20060107T100000Z"/>
2802 Daboo, et al. Standards Track [Page 50]
2804 RFC 4791 CalDAV March 2007
2809 HTTP/1.1 207 Multi-Status
2810 Date: Sat, 11 Nov 2006 09:32:12 GMT
2811 Content-Type: application/xml; charset="utf-8"
2812 Content-Length: xxxx
2814 <?xml version="1.0" encoding="utf-8" ?>
2815 <D:multistatus xmlns:D="DAV:"
2816 xmlns:C="urn:ietf:params:xml:ns:caldav">
2818 <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
2821 <D:getetag>"fffff-abcd4"</D:getetag>
2822 <C:calendar-data>BEGIN:VCALENDAR
2824 PRODID:-//Example Corp.//CalDAV Client//EN
2826 DTSTAMP:20060205T235300Z
2827 DUE;TZID=US/Eastern:20060106T120000
2828 LAST-MODIFIED:20060205T235308Z
2832 UID:E10BA47467C5C69BB74E8720@example.com
2835 TRIGGER;RELATED=START:-PT10M
2841 <D:status>HTTP/1.1 200 OK</D:status>
2846 7.8.6. Example: Retrieval of Event by UID
2848 In this example, the client requests the server to return the VEVENT
2849 component that has the UID property set to
2850 "DC6C50A017428C5216A2F1CD@example.com".
2852 See Appendix B for the calendar data being targeted by this example.
2858 Daboo, et al. Standards Track [Page 51]
2860 RFC 4791 CalDAV March 2007
2865 REPORT /bernard/work/ HTTP/1.1
2866 Host: cal.example.com
2868 Content-Type: application/xml; charset="utf-8"
2869 Content-Length: xxxx
2871 <?xml version="1.0" encoding="utf-8" ?>
2872 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2873 <D:prop xmlns:D="DAV:">
2878 <C:comp-filter name="VCALENDAR">
2879 <C:comp-filter name="VEVENT">
2880 <C:prop-filter name="UID">
2881 <C:text-match collation="i;octet"
2882 >DC6C50A017428C5216A2F1CD@example.com</C:text-match>
2891 HTTP/1.1 207 Multi-Status
2892 Date: Sat, 11 Nov 2006 09:32:12 GMT
2893 Content-Type: application/xml; charset="utf-8"
2894 Content-Length: xxxx
2896 <?xml version="1.0" encoding="utf-8" ?>
2897 <D:multistatus xmlns:D="DAV:"
2898 xmlns:C="urn:ietf:params:xml:ns:caldav">
2900 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
2903 <D:getetag>"fffff-abcd3"</D:getetag>
2904 <C:calendar-data>BEGIN:VCALENDAR
2906 PRODID:-//Example Corp.//CalDAV Client//EN
2908 LAST-MODIFIED:20040110T032845Z
2914 Daboo, et al. Standards Track [Page 52]
2916 RFC 4791 CalDAV March 2007
2919 DTSTART:20000404T020000
2920 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
2926 DTSTART:20001026T020000
2927 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
2934 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
2935 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
2936 DTSTAMP:20060206T001220Z
2937 DTSTART;TZID=US/Eastern:20060104T100000
2939 LAST-MODIFIED:20060206T001330Z
2940 ORGANIZER:mailto:cyrus@example.com
2944 UID:DC6C50A017428C5216A2F1CD@example.com
2945 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
2950 <D:status>HTTP/1.1 200 OK</D:status>
2955 7.8.7. Example: Retrieval of Events by PARTSTAT
2957 In this example, the client requests the server to return the VEVENT
2958 components that have the ATTENDEE property with the value
2959 "mailto:lisa@example.com" and for which the PARTSTAT parameter is set
2962 See Appendix B for the calendar data being targeted by this example.
2970 Daboo, et al. Standards Track [Page 53]
2972 RFC 4791 CalDAV March 2007
2977 REPORT /bernard/work/ HTTP/1.1
2978 Host: cal.example.com
2980 Content-Type: application/xml; charset="utf-8"
2981 Content-Length: xxxx
2983 <?xml version="1.0" encoding="utf-8" ?>
2984 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
2985 <D:prop xmlns:D="DAV:">
2990 <C:comp-filter name="VCALENDAR">
2991 <C:comp-filter name="VEVENT">
2992 <C:prop-filter name="ATTENDEE">
2993 <C:text-match collation="i;ascii-casemap"
2994 >mailto:lisa@example.com</C:text-match>
2995 <C:param-filter name="PARTSTAT">
2996 <C:text-match collation="i;ascii-casemap"
2997 >NEEDS-ACTION</C:text-match>
3007 HTTP/1.1 207 Multi-Status
3008 Date: Sat, 11 Nov 2006 09:32:12 GMT
3009 Content-Type: application/xml; charset="utf-8"
3010 Content-Length: xxxx
3012 <?xml version="1.0" encoding="utf-8" ?>
3013 <D:multistatus xmlns:D="DAV:"
3014 xmlns:C="urn:ietf:params:xml:ns:caldav">
3016 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
3019 <D:getetag>"fffff-abcd3"</D:getetag>
3020 <C:calendar-data>BEGIN:VCALENDAR
3022 PRODID:-//Example Corp.//CalDAV Client//EN
3026 Daboo, et al. Standards Track [Page 54]
3028 RFC 4791 CalDAV March 2007
3032 LAST-MODIFIED:20040110T032845Z
3035 DTSTART:20000404T020000
3036 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3042 DTSTART:20001026T020000
3043 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3050 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
3051 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
3052 DTSTAMP:20060206T001220Z
3053 DTSTART;TZID=US/Eastern:20060104T100000
3055 LAST-MODIFIED:20060206T001330Z
3056 ORGANIZER:mailto:cyrus@example.com
3060 UID:DC6C50A017428C5216A2F1CD@example.com
3061 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
3066 <D:status>HTTP/1.1 200 OK</D:status>
3071 7.8.8. Example: Retrieval of Events Only
3073 In this example, the client requests the server to return all VEVENT
3076 See Appendix B for the calendar data being targeted by this example.
3082 Daboo, et al. Standards Track [Page 55]
3084 RFC 4791 CalDAV March 2007
3089 REPORT /bernard/work/ HTTP/1.1
3090 Host: cal.example.com
3092 Content-Type: application/xml; charset="utf-8"
3093 Content-Length: xxxx
3095 <?xml version="1.0" encoding="utf-8" ?>
3096 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
3097 <D:prop xmlns:D="DAV:">
3102 <C:comp-filter name="VCALENDAR">
3103 <C:comp-filter name="VEVENT"/>
3110 HTTP/1.1 207 Multi-Status
3111 Date: Sat, 11 Nov 2006 09:32:12 GMT
3112 Content-Type: application/xml; charset="utf-8"
3113 Content-Length: xxxx
3115 <?xml version="1.0" encoding="utf-8" ?>
3116 <D:multistatus xmlns:D="DAV:"
3117 xmlns:C="urn:ietf:params:xml:ns:caldav">
3119 <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
3122 <D:getetag>"fffff-abcd1"</D:getetag>
3123 <C:calendar-data>BEGIN:VCALENDAR
3125 PRODID:-//Example Corp.//CalDAV Client//EN
3127 LAST-MODIFIED:20040110T032845Z
3130 DTSTART:20000404T020000
3131 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3138 Daboo, et al. Standards Track [Page 56]
3140 RFC 4791 CalDAV March 2007
3145 DTSTART:20001026T020000
3146 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3153 DTSTAMP:20060206T001102Z
3154 DTSTART;TZID=US/Eastern:20060102T100000
3157 Description:Go Steelers!
3158 UID:74855313FA803DA593CD579A@example.com
3163 <D:status>HTTP/1.1 200 OK</D:status>
3167 <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
3170 <D:getetag>"fffff-abcd2"</D:getetag>
3171 <C:calendar-data>BEGIN:VCALENDAR
3173 PRODID:-//Example Corp.//CalDAV Client//EN
3175 LAST-MODIFIED:20040110T032845Z
3178 DTSTART:20000404T020000
3179 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3185 DTSTART:20001026T020000
3186 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3194 Daboo, et al. Standards Track [Page 57]
3196 RFC 4791 CalDAV March 2007
3201 DTSTAMP:20060206T001121Z
3202 DTSTART;TZID=US/Eastern:20060102T120000
3204 RRULE:FREQ=DAILY;COUNT=5
3206 UID:00959BC664CA650E933C892C@example.com
3209 DTSTAMP:20060206T001121Z
3210 DTSTART;TZID=US/Eastern:20060104T140000
3212 RECURRENCE-ID;TZID=US/Eastern:20060104T120000
3213 SUMMARY:Event #2 bis
3214 UID:00959BC664CA650E933C892C@example.com
3217 DTSTAMP:20060206T001121Z
3218 DTSTART;TZID=US/Eastern:20060106T140000
3220 RECURRENCE-ID;TZID=US/Eastern:20060106T120000
3221 SUMMARY:Event #2 bis bis
3222 UID:00959BC664CA650E933C892C@example.com
3227 <D:status>HTTP/1.1 200 OK</D:status>
3231 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
3234 <D:getetag>"fffff-abcd3"</D:getetag>
3235 <C:calendar-data>BEGIN:VCALENDAR
3237 PRODID:-//Example Corp.//CalDAV Client//EN
3239 LAST-MODIFIED:20040110T032845Z
3242 DTSTART:20000404T020000
3243 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3250 Daboo, et al. Standards Track [Page 58]
3252 RFC 4791 CalDAV March 2007
3257 DTSTART:20001026T020000
3258 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3265 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
3266 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
3267 DTSTAMP:20060206T001220Z
3268 DTSTART;TZID=US/Eastern:20060104T100000
3270 LAST-MODIFIED:20060206T001330Z
3271 ORGANIZER:mailto:cyrus@example.com
3275 UID:DC6C50A017428C5216A2F1CD@example.com
3276 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
3281 <D:status>HTTP/1.1 200 OK</D:status>
3286 7.8.9. Example: Retrieval of All Pending To-Dos
3288 In this example, the client requests the server to return all VTODO
3289 components that do not include a COMPLETED property and do not have a
3290 STATUS property value matching CANCELLED, i.e., VTODOs that still
3291 need to be worked on.
3293 See Appendix B for the calendar data being targeted by this example.
3306 Daboo, et al. Standards Track [Page 59]
3308 RFC 4791 CalDAV March 2007
3313 REPORT /bernard/work/ HTTP/1.1
3314 Host: cal.example.com
3316 Content-Type: application/xml; charset="utf-8"
3317 Content-Length: xxxx
3319 <?xml version="1.0" encoding="utf-8" ?>
3320 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
3321 <D:prop xmlns:D="DAV:">
3326 <C:comp-filter name="VCALENDAR">
3327 <C:comp-filter name="VTODO">
3328 <C:prop-filter name="COMPLETED">
3331 <C:prop-filter name="STATUS">
3333 negate-condition="yes">CANCELLED</C:text-match>
3342 HTTP/1.1 207 Multi-Status
3343 Date: Sat, 11 Nov 2006 09:32:12 GMT
3344 Content-Type: application/xml; charset="utf-8"
3345 Content-Length: xxxx
3347 <?xml version="1.0" encoding="utf-8" ?>
3348 <D:multistatus xmlns:D="DAV:"
3349 xmlns:C="urn:ietf:params:xml:ns:caldav">
3351 <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
3354 <D:getetag>"fffff-abcd4"</D:getetag>
3355 <C:calendar-data>BEGIN:VCALENDAR
3357 PRODID:-//Example Corp.//CalDAV Client//EN
3362 Daboo, et al. Standards Track [Page 60]
3364 RFC 4791 CalDAV March 2007
3367 DTSTAMP:20060205T235335Z
3368 DUE;VALUE=DATE:20060104
3371 UID:DDDEEB7915FA61233B861457@example.com
3374 TRIGGER;RELATED=START:-PT10M
3380 <D:status>HTTP/1.1 200 OK</D:status>
3385 <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
3388 <D:getetag>"fffff-abcd5"</D:getetag>
3389 <C:calendar-data>BEGIN:VCALENDAR
3391 PRODID:-//Example Corp.//CalDAV Client//EN
3393 DTSTAMP:20060205T235300Z
3394 DUE;VALUE=DATE:20060106
3395 LAST-MODIFIED:20060205T235308Z
3399 UID:E10BA47467C5C69BB74E8720@example.com
3402 TRIGGER;RELATED=START:-PT10M
3408 <D:status>HTTP/1.1 200 OK</D:status>
3418 Daboo, et al. Standards Track [Page 61]
3420 RFC 4791 CalDAV March 2007
3423 7.8.10. Example: Attempt to Query Unsupported Property
3425 In this example, the client requests the server to return all VEVENT
3426 components that include an X-ABC-GUID property with a value matching
3427 "ABC". However, the server does not support querying that non-
3428 standard property, and instead returns an error response.
3430 See Appendix B for the calendar data being targeted by this example.
3434 REPORT /bernard/work/ HTTP/1.1
3435 Host: cal.example.com
3437 Content-Type: application/xml; charset="utf-8"
3438 Content-Length: xxxx
3440 <?xml version="1.0" encoding="utf-8" ?>
3441 <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
3442 <D:prop xmlns:D="DAV:">
3447 <C:comp-filter name="VCALENDAR">
3448 <C:comp-filter name="VEVENT">
3449 <C:prop-filter name="X-ABC-GUID">
3450 <C:text-match>ABC</C:text-match>
3459 HTTP/1.1 403 Forbidden
3460 Date: Sat, 11 Nov 2005 09:32:12 GMT
3461 Content-Type: application/xml; charset="utf-8"
3462 Content-Length: xxxx
3464 <?xml version="1.0" encoding="utf-8" ?>
3466 <C:supported-filter>
3467 <C:prop-filter name="X-ABC-GUID"/>
3468 </C:supported-filter>
3474 Daboo, et al. Standards Track [Page 62]
3476 RFC 4791 CalDAV March 2007
3479 7.9. CALDAV:calendar-multiget REPORT
3481 The CALDAV:calendar-multiget REPORT is used to retrieve specific
3482 calendar object resources from within a collection, if the Request-
3483 URI is a collection, or to retrieve a specific calendar object
3484 resource, if the Request-URI is a calendar object resource. This
3485 report is similar to the CALDAV:calendar-query REPORT (see
3486 Section 7.8), except that it takes a list of DAV:href elements,
3487 instead of a CALDAV:filter element, to determine which calendar
3488 object resources to return.
3490 Support for the CALDAV:calendar-multiget REPORT is REQUIRED.
3494 The request body MUST be a CALDAV:calendar-multiget XML element
3495 (see Section 9.10). If the Request-URI is a collection resource,
3496 then the DAV:href elements MUST refer to calendar object resources
3497 within that collection, and they MAY refer to calendar object
3498 resources at any depth within the collection. As a result, the
3499 "Depth" header MUST be ignored by the server and SHOULD NOT be
3500 sent by the client. If the Request-URI refers to a non-collection
3501 resource, then there MUST be a single DAV:href element that is
3502 equivalent to the Request-URI.
3504 The response body for a successful request MUST be a DAV:
3505 multistatus XML element.
3507 The response body for a successful CALDAV:calendar-multiget REPORT
3508 request MUST contain a DAV:response element for each calendar
3509 object resource referenced by the provided set of DAV:href
3510 elements. Calendar data is being returned in the CALDAV:calendar-
3511 data element inside the DAV:prop element.
3513 In the case of an error accessing any of the provided DAV:href
3514 resources, the server MUST return the appropriate error status
3515 code in the DAV:status element of the corresponding DAV:response
3520 (CALDAV:supported-calendar-data): The attributes "content-type"
3521 and "version" of the CALDAV:calendar-data XML elements (see
3522 Section 9.6) specify a media type supported by the server for
3523 calendar object resources.
3525 (CALDAV:min-date-time): Any XML element specifying a range of time
3526 MUST have its start or end DATE or DATE-TIME values greater than
3530 Daboo, et al. Standards Track [Page 63]
3532 RFC 4791 CalDAV March 2007
3535 or equal to the value of the CALDAV:min-date-time property value
3536 (Section 5.2.6) on the calendar collections being targeted by the
3539 (CALDAV:max-date-time): Any XML element specifying a range of time
3540 MUST have its start or end DATE or DATE-TIME values less than or
3541 equal to the value of the CALDAV:max-date-time property value
3542 (Section 5.2.7) on the calendar collections being targeted by the
3549 7.9.1. Example: Successful CALDAV:calendar-multiget REPORT
3551 In this example, the client requests the server to return specific
3552 properties of the VEVENT components referenced by specific URIs. In
3553 addition, the DAV:getetag property is also requested and returned as
3554 part of the response. Note that in this example, the resource at
3555 http://cal.example.com/bernard/work/mtg1.ics does not exist,
3556 resulting in an error status response.
3558 See Appendix B for the calendar data being targeted by this example.
3562 REPORT /bernard/work/ HTTP/1.1
3563 Host: cal.example.com
3564 Content-Type: application/xml; charset="utf-8"
3565 Content-Length: xxxx
3567 <?xml version="1.0" encoding="utf-8" ?>
3568 <C:calendar-multiget xmlns:D="DAV:"
3569 xmlns:C="urn:ietf:params:xml:ns:caldav">
3574 <D:href>/bernard/work/abcd1.ics</D:href>
3575 <D:href>/bernard/work/mtg1.ics</D:href>
3576 </C:calendar-multiget>
3580 HTTP/1.1 207 Multi-Status
3581 Date: Sat, 11 Nov 2006 09:32:12 GMT
3582 Content-Type: application/xml; charset="utf-8"
3586 Daboo, et al. Standards Track [Page 64]
3588 RFC 4791 CalDAV March 2007
3591 Content-Length: xxxx
3593 <?xml version="1.0" encoding="utf-8" ?>
3594 <D:multistatus xmlns:D="DAV:"
3595 xmlns:C="urn:ietf:params:xml:ns:caldav">
3597 <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
3600 <D:getetag>"fffff-abcd1"</D:getetag>
3601 <C:calendar-data>BEGIN:VCALENDAR
3603 PRODID:-//Example Corp.//CalDAV Client//EN
3605 LAST-MODIFIED:20040110T032845Z
3608 DTSTART:20000404T020000
3609 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
3615 DTSTART:20001026T020000
3616 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
3623 DTSTAMP:20060206T001102Z
3624 DTSTART;TZID=US/Eastern:20060102T100000
3627 Description:Go Steelers!
3628 UID:74855313FA803DA593CD579A@example.com
3633 <D:status>HTTP/1.1 200 OK</D:status>
3637 <D:href>http://cal.example.com/bernard/work/mtg1.ics</D:href>
3638 <D:status>HTTP/1.1 404 Not Found</D:status>
3642 Daboo, et al. Standards Track [Page 65]
3644 RFC 4791 CalDAV March 2007
3650 7.10. CALDAV:free-busy-query REPORT
3652 The CALDAV:free-busy-query REPORT generates a VFREEBUSY component
3653 containing free busy information for all the calendar object
3654 resources targeted by the request and that have the CALDAV:read-free-
3655 busy or DAV:read privilege granted to the current user.
3657 Only VEVENT components without a TRANSP property or with the TRANSP
3658 property set to OPAQUE, and VFREEBUSY components SHOULD be considered
3659 in generating the free busy time information.
3661 In the case of VEVENT components, the free or busy time type (FBTYPE)
3662 of the FREEBUSY properties in the returned VFREEBUSY component SHOULD
3663 be derived from the value of the TRANSP and STATUS properties, as
3664 outlined in the table below:
3666 +---------------------------++------------------+
3667 | VEVENT || VFREEBUSY |
3668 +-------------+-------------++------------------+
3669 | TRANSP | STATUS || FBTYPE |
3670 +=============+=============++==================+
3671 | | CONFIRMED || BUSY |
3673 | OPAQUE +-------------++------------------+
3674 | (default) | CANCELLED || FREE |
3675 | +-------------++------------------+
3676 | | TENTATIVE || BUSY-TENTATIVE |
3677 | +-------------++------------------+
3678 | | x-name || BUSY or |
3680 +-------------+-------------++------------------+
3682 | TRANSPARENT | CANCELLED || FREE |
3685 +-------------+-------------++------------------+
3687 Duplicate busy time periods with the same FBTYPE parameter value
3688 SHOULD NOT be specified in the returned VFREEBUSY component. Servers
3689 SHOULD coalesce consecutive or overlapping busy time periods of the
3690 same type. Busy time periods with different FBTYPE parameter values
3693 Support for the CALDAV:free-busy-query REPORT is REQUIRED.
3698 Daboo, et al. Standards Track [Page 66]
3700 RFC 4791 CalDAV March 2007
3705 The request body MUST be a CALDAV:free-busy-query XML element (see
3706 Section 9.11), which MUST contain exactly one CALDAV:time-range
3707 XML element, as defined in Section 9.9.
3709 The request MAY include a Depth header. If no Depth header is
3710 included, Depth:0 is assumed.
3712 The response body for a successful request MUST be an iCalendar
3713 object that contains exactly one VFREEBUSY component that
3714 describes the busy time intervals for the calendar object
3715 resources containing VEVENT, or VFREEBUSY components that satisfy
3716 the Depth value and for which the current user is at least granted
3717 the CALDAV:read-free-busy privilege. If no calendar object
3718 resources are found to satisfy these conditions, a VFREEBUSY
3719 component with no FREEBUSY property MUST be returned. This report
3720 only returns busy time information. Free time information can be
3721 inferred from the returned busy time information.
3723 If the current user is not granted the CALDAV:read-free-busy or
3724 DAV:read privileges on the Request-URI, the CALDAV:free-busy-query
3725 REPORT request MUST fail and return a 404 (Not Found) status
3726 value. This restriction will prevent users from discovering URLs
3727 of resources for which they are only granted the CALDAV:read-free-
3730 The CALDAV:free-busy-query REPORT request can only be run against
3731 a collection (either a regular collection or a calendar
3732 collection). An attempt to run the report on a calendar object
3733 resource MUST fail and return a 403 (Forbidden) status value.
3741 (DAV:number-of-matches-within-limits): The number of matching
3742 calendar object resources must fall within server-specific,
3743 predefined limits. For example, this postcondition might fail if
3744 the specified CALDAV:time-range would cause an extremely large
3745 number of calendar object resources to be considered in computing
3754 Daboo, et al. Standards Track [Page 67]
3756 RFC 4791 CalDAV March 2007
3759 7.10.1. Example: Successful CALDAV:free-busy-query REPORT
3761 In this example, the client requests the server to return free busy
3762 information on the calendar collection /bernard/work/, between 9:00
3763 A.M. and 5:00 P.M. EST (2:00 P.M. and 10:00 P.M. UTC) on the January
3764 4, 2006. The server responds, indicating two busy time intervals of
3765 one hour, one of which is tentative.
3767 See Appendix B for the calendar data being targeted by this example.
3771 REPORT /bernard/work/ HTTP/1.1
3772 Host: cal.example.com
3774 Content-Type: application/xml; charset="utf-8"
3775 Content-Length: xxxx
3777 <?xml version="1.0" encoding="utf-8" ?>
3778 <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
3779 <C:time-range start="20060104T140000Z"
3780 end="20060105T220000Z"/>
3781 </C:free-busy-query>
3786 Date: Sat, 11 Nov 2006 09:32:12 GMT
3787 Content-Type: text/calendar
3788 Content-Length: xxxx
3792 PRODID:-//Example Corp.//CalDAV Server//EN
3794 DTSTAMP:20050125T090000Z
3795 DTSTART:20060104T140000Z
3796 DTEND:20060105T220000Z
3797 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
3798 FREEBUSY:20060104T190000Z/PT1H
3810 Daboo, et al. Standards Track [Page 68]
3812 RFC 4791 CalDAV March 2007
3817 8.1. Client-to-Client Interoperability
3819 There are a number of actions clients can take that will be legal
3820 (the server will not return errors), but that can degrade
3821 interoperability with other client implementations accessing the same
3822 data. For example, a recurrence rule could be replaced with a set of
3823 recurrence dates, a single recurring event could be replaced with a
3824 set of independent resources to represent each recurrence, or the
3825 start/end time values can be translated from the original time zone
3826 to another time zone. Although this advice amounts to iCalendar
3827 interoperability best practices and is not limited only to CalDAV
3828 usage, interoperability problems are likely to be more evident in
3831 8.2. Synchronization Operations
3833 WebDAV already provides functionality required to synchronize a
3834 collection or set of collections, to make changes offline, and
3835 provides a simple way to resolve conflicts when reconnected. ETags
3836 are the key to making this work, but these are not required of all
3837 WebDAV servers. Since offline functionality is more important to
3838 calendar applications than to some other WebDAV applications, CalDAV
3839 servers MUST support ETags, as specified in Section 5.3.4.
3841 8.2.1. Use of Reports
3843 8.2.1.1. Restrict the Time Range
3845 The reports provided in CalDAV can be used by clients to optimize
3846 their performance in terms of network bandwidth usage and resource
3847 consumption on the local client machine. Both are certainly major
3848 considerations for mobile or handheld devices with limited capacity,
3849 but they are also relevant to desktop client applications in cases
3850 where the calendar collections contain large amounts of data.
3852 Typically, clients present calendar data to users in views that span
3853 a finite time interval, so whenever possible, clients should only
3854 retrieve calendar components from the server using CALDAV:calendar-
3855 query REPORT, combined with a CALDAV:time-range element, to limit the
3856 set of returned components to just those needed to populate the
3866 Daboo, et al. Standards Track [Page 69]
3868 RFC 4791 CalDAV March 2007
3871 8.2.1.2. Synchronize by Time Range
3873 Typically in a calendar, historical data (events, to-dos, etc. that
3874 have completed prior to the current date) do not change, though they
3875 may be deleted. As a result, a client can speed up the
3876 synchronization process by only considering data for the present time
3877 and the future up to a reasonable limit (e.g., one week, one month).
3878 If the user then tries to examine a portion of the calendar outside
3879 the range that has been synchronized, the client can perform another
3880 synchronization operation on the new time interval being examined.
3881 This "just-in-time" synchronization can minimize bandwidth for common
3882 user interaction behaviors.
3884 8.2.1.3. Synchronization Process
3886 If a client wants to support calendar data synchronization, as
3887 opposed to downloading calendar data each time it is needed, the
3888 client needs to cache the calendar object resource's URI and ETag,
3889 along with the actual calendar data. While the URI remains static
3890 for the lifetime of the calendar object resource, the ETag will
3891 change with each successive change to the calendar object resource.
3892 Thus, to synchronize a local data cache with the server, the client
3893 can first fetch the URI/ETag pairs for the time interval being
3894 considered, and compare those results with the cached data. Any
3895 cached component whose ETag differs from that on the server needs to
3898 In order to properly detect the changes between the server and client
3899 data, the client will need to keep a record of which calendar object
3900 resources have been created, changed, or deleted since the last
3901 synchronization operation so that it can reconcile those changes with
3902 the data on the server.
3904 Here's an example of how to do that:
3906 The client issues a CALDAV:calendar-query REPORT request for a
3907 specific time range and asks for only the DAV:getetag property to be
3922 Daboo, et al. Standards Track [Page 70]
3924 RFC 4791 CalDAV March 2007
3927 REPORT /bernard/work/ HTTP/1.1
3928 Host: cal.example.com
3930 Content-Type: application/xml; charset="utf-8"
3931 Content-Length: xxxx
3933 <?xml version="1.0" encoding="utf-8" ?>
3934 <C:calendar-query xmlns:D="DAV:"
3935 xmlns:C="urn:ietf:params:xml:ns:caldav">
3940 <C:comp-filter name="VCALENDAR">
3941 <C:comp-filter name="VEVENT">
3942 <C:time-range start="20040902T000000Z"
3943 end="20040903T000000Z"/>
3949 The client then uses the results to determine which calendar object
3950 resources have changed, been created, or deleted on the server, and
3951 how those relate to locally cached calendar object resources that may
3952 have changed, been created, or deleted. If the client determines
3953 that there are calendar object resources on the server that need to
3954 be fetched, the client issues a CALDAV:calendar-multiget REPORT
3955 request to fetch its calendar data:
3957 REPORT /bernard/work/ HTTP/1.1
3958 Host: cal.example.com
3959 Content-Type: application/xml; charset="utf-8"
3960 Content-Length: xxxx
3962 <?xml version="1.0" encoding="utf-8" ?>
3963 <C:calendar-multiget xmlns:D="DAV:"
3964 xmlns:C="urn:ietf:params:xml:ns:caldav">
3969 <D:href>/bernard/work/abcd1.ics</D:href>
3970 <D:href>/bernard/work/mtg1.ics</D:href>
3971 </C:calendar-multiget>
3978 Daboo, et al. Standards Track [Page 71]
3980 RFC 4791 CalDAV March 2007
3983 8.2.2. Restrict the Properties Returned
3985 A client may not need all the calendar properties of a calendar
3986 object resource when presenting information to the user. Since some
3987 calendar property values can be large (e.g., ATTACH or ATTENDEE), a
3988 client can choose to restrict the calendar properties to be returned
3989 in a calendaring REPORT request to those it knows it will use.
3991 However, if a client needs to make a change to a calendar object
3992 resource, it can only change the entire calendar object resource via
3993 a PUT request. There is currently no way to incrementally make a
3994 change to a set of calendar properties of a calendar object resource.
3995 As a result, the client will have to get the entire calendar object
3996 resource that is being changed.
4000 WebDAV locks can be used to prevent two clients that are modifying
4001 the same resource from either overwriting each others' changes
4002 (though that problem can also be solved by using ETags) or wasting
4003 time making changes that will conflict with another set of changes.
4004 In a multi-user calendar system, an interactive calendar client could
4005 lock an event while the user is editing the event, and unlock the
4006 event when the user finishes or cancels. Locks can also be used to
4007 prevent changes while data is being reorganized. For example, a
4008 calendar client might lock two calendar collections prior to moving a
4009 bunch of calendar resources from one to another.
4011 Clients are responsible for requesting a lock timeout period that is
4012 appropriate to the use case. When the user explicitly decides to
4013 reserve a resource and prevent other changes, a long timeout might be
4014 appropriate, but in cases where the client automatically decides to
4015 lock the resource, the timeout should be short (and the client can
4016 always refresh the lock should it need to). A short lock timeout
4017 means that if the client is unable to remove the lock, the other
4018 calendar users aren't prevented from making changes.
4020 8.4. Finding Calendars
4022 Much of the time, a calendar client (or agent) will discover a new
4023 calendar's location by being provided directly with the URL. For
4024 example, a user will type his or her own calendar location into
4025 client configuration information or copy and paste a URL from email
4026 into the calendar application. The client need only confirm that the
4027 URL points to a resource that is a calendar collection. The client
4028 may also be able to browse WebDAV collections to find calendar
4034 Daboo, et al. Standards Track [Page 72]
4036 RFC 4791 CalDAV March 2007
4039 The choice of HTTP URLs means that calendar object resources are
4040 backward compatible with existing software, but does have the
4041 disadvantage that existing software does not usually know to look at
4042 the OPTIONS response to that URL to determine what can be done with
4043 it. This is somewhat of a barrier for WebDAV usage as well as with
4044 CalDAV usage. This specification does not offer a way through this
4045 other than making the information available in the OPTIONS response
4046 should this be requested.
4048 For calendar sharing and scheduling use cases, one might wish to find
4049 the calendar belonging to another user. If the other user has a
4050 calendar in the same repository, that calendar can be found by using
4051 the principal namespace required by WebDAV ACL support. For other
4052 cases, the authors have no universal solution, but implementers can
4053 consider whether to use vCard [RFC2426] or LDAP [RFC4511] standards
4054 together with calendar attributes [RFC2739].
4056 Because CalDAV requires servers to support WebDAV ACL [RFC3744],
4057 including principal namespaces, and with the addition of the CALDAV:
4058 calendar-home-set property, there are a couple options for CalDAV
4059 clients to find one's own calendar or another user's calendar.
4061 In this case, a DAV:principal-match REPORT is used to find a named
4062 property (the CALDAV:calendar-home-set) on the Principal-URL of the
4063 current user. Using this, a WebDAV client can learn "who am I" and
4064 "where are my calendars". The REPORT request body looks like this:
4066 <?xml version="1.0" encoding="utf-8" ?>
4067 <D:principal-match xmlns:D="DAV:">
4070 <C:calendar-home-set
4071 xmlns:C="urn:ietf:params:xml:ns:caldav"/>
4073 </D:principal-match>
4075 To find other users' calendars, the DAV:principal-property-search
4076 REPORT can be used to filter on some properties and return others.
4077 To search for a calendar owned by a user named "Laurie", the REPORT
4078 request body would look like this:
4090 Daboo, et al. Standards Track [Page 73]
4092 RFC 4791 CalDAV March 2007
4095 <?xml version="1.0" encoding="utf-8" ?>
4096 <D:principal-property-search xmlns:D="DAV:">
4101 <D:match>Laurie</D:match>
4102 </D:property-search>
4104 <C:calendar-home-set
4105 xmlns:C="urn:ietf:params:xml:ns:caldav"/>
4108 </D:principal-property-search>
4110 The server performs a case-sensitive or caseless search for a
4111 matching string subset of "Laurie" within the DAV:displayname
4112 property. Thus, the server might return "Laurie Dusseault", "Laurier
4113 Desruisseaux", or "Wilfrid Laurier" as matching DAV:displayname
4114 values, and return the calendars for each of these.
4116 8.5. Storing and Using Attachments
4118 CalDAV clients MAY create attachments in calendar components either
4119 as inline or external. This section contains some guidelines for
4120 creating and managing attachments.
4122 8.5.1. Inline Attachments
4124 CalDAV clients MUST support inline attachments as specified in
4125 iCalendar [RFC2445]. CalDAV servers MUST support inline attachments,
4126 so clients can rely on being able to create attachments this way. On
4127 the other hand, inline attachments have some drawbacks:
4129 o Servers MAY impose limitations on the size of calendar object
4130 resources (i.e., refusing PUT requests of very large iCalendar
4131 objects). Servers that impose such limitations MUST use the
4132 CALDAV:max-resource-size property on a calendar collection to
4133 inform the client as to what the limitation is (see
4136 o Servers MAY impose storage quota limitations on calendar
4137 collections (See [RFC4331]).
4139 o Any change to a calendar object resource containing an inline
4140 attachment requires the entire inline attachment to be re-
4146 Daboo, et al. Standards Track [Page 74]
4148 RFC 4791 CalDAV March 2007
4151 o Clients synchronizing a changed calendar object resource have to
4152 download the entire calendar object resource, even if the
4153 attachment is unchanged.
4155 8.5.2. External Attachments
4157 CalDAV clients SHOULD support downloading of external attachments
4158 referenced by arbitrary URI schemes, by either processing them
4159 directly, or by passing the attachment URI to a suitable "helper
4160 application" for processing, if such an application exists. CalDAV
4161 clients MUST support downloading of external attachments referenced
4162 by the "http" or "https" URI schemes. An external attachment could
4165 o In a collection in the calendar collection containing the calendar
4168 o Somewhere else in the same repository that hosts the calendar
4171 o On an HTTP or FTP server elsewhere.
4173 CalDAV servers MAY provide support for child collections in calendar
4174 collections. CalDAV servers MAY allow the MKCOL method to create
4175 child collections in calendar collections. Child collections of
4176 calendar collections MAY contain any type of resource except calendar
4177 collections that they MUST NOT contain. Some CalDAV servers won't
4178 allow child collections in calendar collections, and it may be
4179 possible on such a server to discover other locations where
4180 attachments can be stored.
4182 Clients are entirely responsible for maintaining reference
4183 consistency with calendar components that link to external
4184 attachments. A client deleting a calendar component with an external
4185 attachment might therefore also delete the attachment if that's
4186 appropriate; however, appropriateness can be very hard to determine.
4187 A new component might easily reference some pre-existing Web resource
4188 that is intended to have independent existence from the calendar
4189 component (the "attachment" could be a major proposal to be discussed
4190 in a meeting, for instance). Best practices will probably emerge and
4191 should probably be documented, but for now, clients should be wary of
4192 engaging in aggressive "cleanup" of external attachments. A client
4193 could involve the user in making decisions about removing
4194 unreferenced documents, or a client could be conservative in only
4195 deleting attachments it had created.
4197 Also, clients are responsible for consistency of permissions when
4198 using external attachments. One reason for servers to support the
4202 Daboo, et al. Standards Track [Page 75]
4204 RFC 4791 CalDAV March 2007
4207 storage of attachments within child collections of calendar
4208 collections is that ACL inheritance might make it easier to grant the
4209 same permissions to attachments that are granted on the calendar
4210 collection. Otherwise, it can be very difficult to keep permissions
4211 synchronized. With attachments stored on separate repositories, it
4212 can be impossible to keep permissions consistent -- the two
4213 repositories may not support the same permissions or have the same
4214 set of principals. Some systems have used tickets or other anonymous
4215 access control mechanisms to provide partially satisfactory solutions
4216 to these kinds of problems.
4218 8.6. Storing and Using Alarms
4220 Note that all CalDAV calendar collections (including those the user
4221 might treat as public or group calendars) can contain alarm
4222 information on events and to-dos. Users can synchronize a calendar
4223 between multiple devices and decide to have alarms execute on a
4224 different device than the device that created the alarm. Not all
4225 alarm action types are completely interoperable (e.g., those that
4226 name a sound file to play).
4228 When the action is AUDIO and the client is configured to execute
4229 the alarm, the client SHOULD play the suggested sound if it's
4230 available or play another sound, but SHOULD NOT rewrite the alarm
4231 just to replace the suggested sound with a sound that's locally
4234 When the action is DISPLAY and the client is configured to execute
4235 the alarm, the client SHOULD execute a display alarm by displaying
4236 according to the suggested description or some reasonable
4237 replacement, but SHOULD NOT rewrite the alarm for its own
4240 When the action is EMAIL and the client is incapable of sending
4241 email, it SHOULD ignore the alarm, but it MUST continue to
4242 synchronize the alarm itself.
4244 This specification makes no recommendations about executing alarms
4245 of type PROCEDURE, except to note that clients are advised to take
4246 care to avoid creating security holes by executing these.
4248 Non-interoperable alarm information (e.g., should somebody define a
4249 color to be used in a display alarm) should be put in non-standard
4250 properties inside the VALARM component in order to keep the basic
4251 alarm usable on all devices.
4253 Clients that allow changes to calendar object resources MUST
4254 synchronize the alarm data that already exists in the resources.
4258 Daboo, et al. Standards Track [Page 76]
4260 RFC 4791 CalDAV March 2007
4263 Clients MAY execute alarms that are downloaded in this fashion,
4264 possibly based on user preference. If a client is only doing read
4265 operations on a calendar and there is no risk of losing alarm
4266 information, then the client MAY discard alarm information.
4268 This specification makes no attempt to provide multi-user alarms on
4269 group calendars or to find out for whom an alarm is intended.
4270 Addressing those issues might require extensions to iCalendar; for
4271 example, to store alarms per-user, or to indicate for which user a
4272 VALARM was intended. In the meantime, clients might maximize
4273 interoperability by generally not uploading alarm information to
4274 public, group, or resource calendars.
4276 9. XML Element Definitions
4278 9.1. CALDAV:calendar XML Element
4282 Namespace: urn:ietf:params:xml:ns:caldav
4284 Purpose: Specifies the resource type of a calendar collection.
4286 Description: See Section 4.2.
4290 <!ELEMENT calendar EMPTY>
4292 9.2. CALDAV:mkcalendar XML Element
4296 Namespace: urn:ietf:params:xml:ns:caldav
4298 Purpose: Specifies a request that includes the WebDAV property
4299 values to be set for a calendar collection resource when it is
4302 Description: See Section 5.3.1.
4306 <!ELEMENT mkcalendar (DAV:set)>
4314 Daboo, et al. Standards Track [Page 77]
4316 RFC 4791 CalDAV March 2007
4319 9.3. CALDAV:mkcalendar-response XML Element
4321 Name: mkcalendar-response
4323 Namespace: urn:ietf:params:xml:ns:caldav
4325 Purpose: Specifies a response body for a successful MKCALENDAR
4328 Description: See Section 5.3.1.
4332 <!ELEMENT mkcalendar-response ANY>
4334 9.4. CALDAV:supported-collation XML Element
4336 Name: supported-collation
4338 Namespace: urn:ietf:params:xml:ns:caldav
4340 Purpose: Identifies a single collation via its collation identifier,
4341 as defined by [RFC4790].
4343 Description: The CALDAV:supported-collation contains the text of a
4344 collation identifier, as described in Section 7.5.1.
4348 <!ELEMENT supported-collation (#PCDATA)>
4349 PCDATA value: collation identifier
4351 9.5. CALDAV:calendar-query XML Element
4353 Name: calendar-query
4355 Namespace: urn:ietf:params:xml:ns:caldav
4357 Purpose: Defines a report for querying calendar object resources.
4359 Description: See Section 7.8.
4363 <!ELEMENT calendar-query ((DAV:allprop |
4365 DAV:prop)?, filter, timezone?)>
4370 Daboo, et al. Standards Track [Page 78]
4372 RFC 4791 CalDAV March 2007
4375 9.6. CALDAV:calendar-data XML Element
4379 Namespace: urn:ietf:params:xml:ns:caldav
4381 Purpose: Specified one of the following:
4383 1. A supported media type for calendar object resources when
4384 nested in the CALDAV:supported-calendar-data property;
4386 2. The parts of a calendar object resource should be returned by
4387 a calendaring report;
4389 3. The content of a calendar object resource in a response to a
4392 Description: When nested in the CALDAV:supported-calendar-data
4393 property, the CALDAV:calendar-data XML element specifies a media
4394 type supported by the CalDAV server for calendar object resources.
4396 When used in a calendaring REPORT request, the CALDAV:calendar-
4397 data XML element specifies which parts of calendar object
4398 resources need to be returned in the response. If the CALDAV:
4399 calendar-data XML element doesn't contain any CALDAV:comp element,
4400 calendar object resources will be returned in their entirety.
4402 Finally, when used in a calendaring REPORT response, the CALDAV:
4403 calendar-data XML element specifies the content of a calendar
4404 object resource. Given that XML parsers normalize the two-
4405 character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal
4406 10) to a single LF character (US-ASCII decimal 10), the CR
4407 character (US-ASCII decimal 13) MAY be omitted in calendar object
4408 resources specified in the CALDAV:calendar-data XML element.
4409 Furthermore, calendar object resources specified in the CALDAV:
4410 calendar-data XML element MAY be invalid per their media type
4411 specification if the CALDAV:calendar-data XML element part of the
4412 calendaring REPORT request did not specify required properties
4413 (e.g., UID, DTSTAMP, etc.), or specified a CALDAV:prop XML element
4414 with the "novalue" attribute set to "yes".
4416 Note: The CALDAV:calendar-data XML element is specified in requests
4417 and responses inside the DAV:prop XML element as if it were a
4418 WebDAV property. However, the CALDAV:calendar-data XML element is
4419 not a WebDAV property and, as such, is not returned in PROPFIND
4420 responses, nor used in PROPPATCH requests.
4426 Daboo, et al. Standards Track [Page 79]
4428 RFC 4791 CalDAV March 2007
4431 Note: The iCalendar data embedded within the CALDAV:calendar-data
4432 XML element MUST follow the standard XML character data encoding
4433 rules, including use of <, >, & etc. entity encoding or
4434 the use of a <![CDATA[ ... ]]> construct. In the later case, the
4435 iCalendar data cannot contain the character sequence "]]>", which
4436 is the end delimiter for the CDATA section.
4440 <!ELEMENT calendar-data EMPTY>
4442 when nested in the CALDAV:supported-calendar-data property
4443 to specify a supported media type for calendar object
4446 <!ELEMENT calendar-data (comp?,
4447 (expand | limit-recurrence-set)?,
4448 limit-freebusy-set?)>
4450 when nested in the DAV:prop XML element in a calendaring
4451 REPORT request to specify which parts of calendar object
4452 resources should be returned in the response;
4454 <!ELEMENT calendar-data (#PCDATA)>
4455 PCDATA value: iCalendar object
4457 when nested in the DAV:prop XML element in a calendaring
4458 REPORT response to specify the content of a returned
4459 calendar object resource.
4461 <!ATTLIST calendar-data content-type CDATA "text/calendar"
4462 version CDATA "2.0">
4463 content-type value: a MIME media type
4464 version value: a version string
4466 attributes can be used on all three variants of the
4467 CALDAV:calendar-data XML element.
4469 9.6.1. CALDAV:comp XML Element
4473 Namespace: urn:ietf:params:xml:ns:caldav
4475 Purpose: Defines which component types to return.
4482 Daboo, et al. Standards Track [Page 80]
4484 RFC 4791 CalDAV March 2007
4487 Description: The name value is a calendar component name (e.g.,
4492 <!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>
4494 <!ATTLIST comp name CDATA #REQUIRED>
4495 name value: a calendar component name
4497 Note: The CALDAV:prop and CALDAV:allprop elements have the same name
4498 as the DAV:prop and DAV:allprop elements defined in [RFC2518].
4499 However, the CALDAV:prop and CALDAV:allprop elements are defined
4500 in the "urn:ietf:params:xml:ns:caldav" namespace instead of the
4503 9.6.2. CALDAV:allcomp XML Element
4507 Namespace: urn:ietf:params:xml:ns:caldav
4509 Purpose: Specifies that all components shall be returned.
4511 Description: The CALDAV:allcomp XML element can be used when the
4512 client wants all types of components returned by a calendaring
4517 <!ELEMENT allcomp EMPTY>
4519 9.6.3. CALDAV:allprop XML Element
4523 Namespace: urn:ietf:params:xml:ns:caldav
4525 Purpose: Specifies that all properties shall be returned.
4527 Description: The CALDAV:allprop XML element can be used when the
4528 client wants all properties of components returned by a
4529 calendaring REPORT request.
4533 <!ELEMENT allprop EMPTY>
4538 Daboo, et al. Standards Track [Page 81]
4540 RFC 4791 CalDAV March 2007
4543 Note: The CALDAV:allprop element has the same name as the DAV:
4544 allprop element defined in [RFC2518]. However, the CALDAV:allprop
4545 element is defined in the "urn:ietf:params:xml:ns:caldav"
4546 namespace instead of the "DAV:" namespace.
4548 9.6.4. CALDAV:prop XML Element
4552 Namespace: urn:ietf:params:xml:ns:caldav
4554 Purpose: Defines which properties to return in the response.
4556 Description: The "name" attribute specifies the name of the calendar
4557 property to return (e.g., ATTENDEE). The "novalue" attribute can
4558 be used by clients to request that the actual value of the
4559 property not be returned (if the "novalue" attribute is set to
4560 "yes"). In that case, the server will return just the iCalendar
4561 property name and any iCalendar parameters and a trailing ":"
4562 without the subsequent value data.
4566 <!ELEMENT prop EMPTY>
4568 <!ATTLIST prop name CDATA #REQUIRED
4569 novalue (yes | no) "no">
4570 name value: a calendar property name
4571 novalue value: "yes" or "no"
4573 Note: The CALDAV:prop element has the same name as the DAV:prop
4574 element defined in [RFC2518]. However, the CALDAV:prop element is
4575 defined in the "urn:ietf:params:xml:ns:caldav" namespace instead
4576 of the "DAV:" namespace.
4578 9.6.5. CALDAV:expand XML Element
4582 Namespace: urn:ietf:params:xml:ns:caldav
4584 Purpose: Forces the server to expand recurring components into
4585 individual recurrence instances.
4587 Description: The CALDAV:expand XML element specifies that for a
4588 given calendaring REPORT request, the server MUST expand the
4589 recurrence set into calendar components that define exactly one
4594 Daboo, et al. Standards Track [Page 82]
4596 RFC 4791 CalDAV March 2007
4599 recurrence instance, and MUST return only those whose scheduled
4600 time intersect a specified time range.
4602 The "start" attribute specifies the inclusive start of the time
4603 range, and the "end" attribute specifies the non-inclusive end of
4604 the time range. Both attributes are specified as date with UTC
4605 time value. The value of the "end" attribute MUST be greater than
4606 the value of the "start" attribute.
4608 The server MUST use the same logic as defined for CALDAV:time-
4609 range to determine if a recurrence instance intersects the
4610 specified time range.
4612 Recurring components, other than the initial instance, MUST
4613 include a RECURRENCE-ID property indicating which instance they
4616 The returned calendar components MUST NOT use recurrence
4617 properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT
4618 have reference to or include VTIMEZONE components. Date and local
4619 time with reference to time zone information MUST be converted
4620 into date with UTC time.
4624 <!ELEMENT expand EMPTY>
4626 <!ATTLIST expand start CDATA #REQUIRED
4627 end CDATA #REQUIRED>
4628 start value: an iCalendar "date with UTC time"
4629 end value: an iCalendar "date with UTC time"
4631 9.6.6. CALDAV:limit-recurrence-set XML Element
4633 Name: limit-recurrence-set
4635 Namespace: urn:ietf:params:xml:ns:caldav
4637 Purpose: Specifies a time range to limit the set of "overridden
4638 components" returned by the server.
4640 Description: The CALDAV:limit-recurrence-set XML element specifies
4641 that for a given calendaring REPORT request, the server MUST
4642 return, in addition to the "master component", only the
4643 "overridden components" that impact a specified time range. An
4644 overridden component impacts a time range if its current start and
4645 end times overlap the time range, or if the original start and end
4650 Daboo, et al. Standards Track [Page 83]
4652 RFC 4791 CalDAV March 2007
4655 times -- the ones that would have been used if the instance were
4656 not overridden -- overlap the time range.
4658 The "start" attribute specifies the inclusive start of the time
4659 range, and the "end" attribute specifies the non-inclusive end of
4660 the time range. Both attributes are specified as date with UTC
4661 time value. The value of the "end" attribute MUST be greater than
4662 the value of the "start" attribute.
4664 The server MUST use the same logic as defined for CALDAV:time-
4665 range to determine if the current or original scheduled time of an
4666 "overridden" recurrence instance intersects the specified time
4669 Overridden components that have a RANGE parameter on their
4670 RECURRENCE-ID property may specify one or more instances in the
4671 recurrence set, and some of those instances may fall within the
4672 specified time range or may have originally fallen within the
4673 specified time range prior to being overridden. If that is the
4674 case, the overridden component MUST be included in the results, as
4675 it has a direct impact on the interpretation of instances within
4676 the specified time range.
4680 <!ELEMENT limit-recurrence-set EMPTY>
4682 <!ATTLIST limit-recurrence-set start CDATA #REQUIRED
4683 end CDATA #REQUIRED>
4684 start value: an iCalendar "date with UTC time"
4685 end value: an iCalendar "date with UTC time"
4687 9.6.7. CALDAV:limit-freebusy-set XML Element
4689 Name: limit-freebusy-set
4691 Namespace: urn:ietf:params:xml:ns:caldav
4693 Purpose: Specifies a time range to limit the set of FREEBUSY values
4694 returned by the server.
4696 Description: The CALDAV:limit-freebusy-set XML element specifies
4697 that for a given calendaring REPORT request, the server MUST only
4698 return the FREEBUSY property values of a VFREEBUSY component that
4699 intersects a specified time range.
4701 The "start" attribute specifies the inclusive start of the time
4702 range, and the "end" attribute specifies the non-inclusive end of
4706 Daboo, et al. Standards Track [Page 84]
4708 RFC 4791 CalDAV March 2007
4711 the time range. Both attributes are specified as "date with UTC
4712 time" value. The value of the "end" attribute MUST be greater
4713 than the value of the "start" attribute.
4715 The server MUST use the same logic as defined for CALDAV:time-
4716 range to determine if a FREEBUSY property value intersects the
4717 specified time range.
4721 <!ELEMENT limit-freebusy-set EMPTY>
4723 <!ATTLIST limit-freebusy-set start CDATA #REQUIRED
4724 end CDATA #REQUIRED>
4725 start value: an iCalendar "date with UTC time"
4726 end value: an iCalendar "date with UTC time"
4728 9.7. CALDAV:filter XML Element
4732 Namespace: urn:ietf:params:xml:ns:caldav
4734 Purpose: Specifies a filter to limit the set of calendar components
4735 returned by the server.
4737 Description: The CALDAV:filter XML element specifies the search
4738 filter used to limit the calendar components returned by a
4739 calendaring REPORT request.
4743 <!ELEMENT filter (comp-filter)>
4745 9.7.1. CALDAV:comp-filter XML Element
4749 Namespace: urn:ietf:params:xml:ns:caldav
4751 Purpose: Specifies search criteria on calendar components.
4753 Description: The CALDAV:comp-filter XML element specifies a query
4754 targeted at the calendar object (i.e., VCALENDAR) or at a specific
4755 calendar component type (e.g., VEVENT). The scope of the
4756 CALDAV:comp-filter XML element is the calendar object when used as
4757 a child of the CALDAV:filter XML element. The scope of the
4758 CALDAV:comp-filter XML element is the enclosing calendar component
4762 Daboo, et al. Standards Track [Page 85]
4764 RFC 4791 CalDAV March 2007
4767 when used as a child of another CALDAV:comp-filter XML element. A
4768 CALDAV:comp-filter is said to match if:
4770 * The CALDAV:comp-filter XML element is empty and the calendar
4771 object or calendar component type specified by the "name"
4772 attribute exists in the current scope;
4776 * The CALDAV:comp-filter XML element contains a CALDAV:is-not-
4777 defined XML element and the calendar object or calendar
4778 component type specified by the "name" attribute does not exist
4779 in the current scope;
4783 * The CALDAV:comp-filter XML element contains a CALDAV:time-range
4784 XML element and at least one recurrence instance in the
4785 targeted calendar component is scheduled to overlap the
4786 specified time range, and all specified CALDAV:prop-filter and
4787 CALDAV:comp-filter child XML elements also match the targeted
4792 * The CALDAV:comp-filter XML element only contains CALDAV:prop-
4793 filter and CALDAV:comp-filter child XML elements that all match
4794 the targeted calendar component.
4798 <!ELEMENT comp-filter (is-not-defined | (time-range?,
4799 prop-filter*, comp-filter*))>
4801 <!ATTLIST comp-filter name CDATA #REQUIRED>
4802 name value: a calendar object or calendar component
4805 9.7.2. CALDAV:prop-filter XML Element
4809 Namespace: urn:ietf:params:xml:ns:caldav
4811 Purpose: Specifies search criteria on calendar properties.
4813 Description: The CALDAV:prop-filter XML element specifies a query
4814 targeted at a specific calendar property (e.g., CATEGORIES) in the
4818 Daboo, et al. Standards Track [Page 86]
4820 RFC 4791 CalDAV March 2007
4823 scope of the enclosing calendar component. A calendar property is
4824 said to match a CALDAV:prop-filter if:
4826 * The CALDAV:prop-filter XML element is empty and a property of
4827 the type specified by the "name" attribute exists in the
4828 enclosing calendar component;
4832 * The CALDAV:prop-filter XML element contains a CALDAV:is-not-
4833 defined XML element and no property of the type specified by
4834 the "name" attribute exists in the enclosing calendar
4839 * The CALDAV:prop-filter XML element contains a CALDAV:time-range
4840 XML element and the property value overlaps the specified time
4841 range, and all specified CALDAV:param-filter child XML elements
4842 also match the targeted property;
4846 * The CALDAV:prop-filter XML element contains a CALDAV:text-match
4847 XML element and the property value matches it, and all
4848 specified CALDAV:param-filter child XML elements also match the
4853 <!ELEMENT prop-filter (is-not-defined |
4854 ((time-range | text-match)?,
4857 <!ATTLIST prop-filter name CDATA #REQUIRED>
4858 name value: a calendar property name (e.g., ATTENDEE)
4860 9.7.3. CALDAV:param-filter XML Element
4864 Namespace: urn:ietf:params:xml:ns:caldav
4866 Purpose: Limits the search to specific parameter values.
4868 Description: The CALDAV:param-filter XML element specifies a query
4869 targeted at a specific calendar property parameter (e.g.,
4870 PARTSTAT) in the scope of the calendar property on which it is
4874 Daboo, et al. Standards Track [Page 87]
4876 RFC 4791 CalDAV March 2007
4879 defined. A calendar property parameter is said to match a CALDAV:
4882 * The CALDAV:param-filter XML element is empty and a parameter of
4883 the type specified by the "name" attribute exists on the
4884 calendar property being examined;
4888 * The CALDAV:param-filter XML element contains a CALDAV:is-not-
4889 defined XML element and no parameter of the type specified by
4890 the "name" attribute exists on the calendar property being
4895 <!ELEMENT param-filter (is-not-defined | text-match?)>
4897 <!ATTLIST param-filter name CDATA #REQUIRED>
4898 name value: a property parameter name (e.g., PARTSTAT)
4900 9.7.4. CALDAV:is-not-defined XML Element
4902 Name: is-not-defined
4904 Namespace: urn:ietf:params:xml:ns:caldav
4906 Purpose: Specifies that a match should occur if the enclosing
4907 component, property, or parameter does not exist.
4909 Description: The CALDAV:is-not-defined XML element specifies that a
4910 match occurs if the enclosing component, property, or parameter
4911 value specified in a calendaring REPORT request does not exist in
4912 the calendar data being tested.
4916 <!ELEMENT is-not-defined EMPTY>
4918 9.7.5. CALDAV:text-match XML Element
4922 Namespace: urn:ietf:params:xml:ns:caldav
4924 Purpose: Specifies a substring match on a property or parameter
4930 Daboo, et al. Standards Track [Page 88]
4932 RFC 4791 CalDAV March 2007
4935 Description: The CALDAV:text-match XML element specifies text used
4936 for a substring match against the property or parameter value
4937 specified in a calendaring REPORT request.
4939 The "collation" attribute is used to select the collation that the
4940 server MUST use for character string matching. In the absence of
4941 this attribute, the server MUST use the "i;ascii-casemap"
4944 The "negate-condition" attribute is used to indicate that this
4945 test returns a match if the text matches when the attribute value
4946 is set to "no", or return a match if the text does not match, if
4947 the attribute value is set to "yes". For example, this can be
4948 used to match components with a STATUS property not set to
4953 <!ELEMENT text-match (#PCDATA)>
4954 PCDATA value: string
4956 <!ATTLIST text-match collation CDATA "i;ascii-casemap"
4957 negate-condition (yes | no) "no">
4959 9.8. CALDAV:timezone XML Element
4963 Namespace: urn:ietf:params:xml:ns:caldav
4965 Purpose: Specifies the time zone component to use when determining
4966 the results of a report.
4968 Description: The CALDAV:timezone XML element specifies that for a
4969 given calendaring REPORT request, the server MUST rely on the
4970 specified VTIMEZONE component instead of the CALDAV:calendar-
4971 timezone property of the calendar collection, in which the
4972 calendar object resource is contained to resolve "date" values and
4973 "date with local time" values (i.e., floating time) to "date with
4974 UTC time" values. The server will require this information to
4975 determine if a calendar component scheduled with "date" values or
4976 "date with local time" values intersects a CALDAV:time-range
4977 specified in a CALDAV:calendar-query REPORT.
4979 Note: The iCalendar data embedded within the CALDAV:timezone XML
4980 element MUST follow the standard XML character data encoding
4981 rules, including use of <, >, & etc. entity encoding or
4982 the use of a <![CDATA[ ... ]]> construct. In the later case, the
4986 Daboo, et al. Standards Track [Page 89]
4988 RFC 4791 CalDAV March 2007
4991 iCalendar data cannot contain the character sequence "]]>", which
4992 is the end delimiter for the CDATA section.
4996 <!ELEMENT timezone (#PCDATA)>
4997 PCDATA value: an iCalendar object with exactly one VTIMEZONE
4999 9.9. CALDAV:time-range XML Element
5003 Namespace: urn:ietf:params:xml:ns:caldav
5005 Purpose: Specifies a time range to limit the set of calendar
5006 components returned by the server.
5008 Description: The CALDAV:time-range XML element specifies that for a
5009 given calendaring REPORT request, the server MUST only return the
5010 calendar object resources that, depending on the context, have a
5011 component or property whose value intersects a specified time
5014 The "start" attribute specifies the inclusive start of the time
5015 range, and the "end" attribute specifies the non-inclusive end of
5016 the time range. Both attributes MUST be specified as "date with
5017 UTC time" value. Time ranges open at one end can be specified by
5018 including only one attribute; however, at least one attribute MUST
5019 always be present in the CALDAV:time-range element. If either the
5020 "start" or "end" attribute is not specified in the CALDAV:time-
5021 range XML element, assume "-infinity" and "+infinity" as their
5022 value, respectively. If both "start" and "end" are present, the
5023 value of the "end" attribute MUST be greater than the value of the
5026 Time range tests MUST consider every recurrence instance when
5027 testing the time range condition; if any one instance matches,
5028 then the test returns true. Testing recurrence instances requires
5029 the server to infer an effective value for DTSTART, DTEND,
5030 DURATION, and DUE properties for an instance based on the
5031 recurrence patterns and any overrides.
5033 A VEVENT component overlaps a given time range if the condition
5034 for the corresponding component state specified in the table below
5035 is satisfied. Note that, as specified in [RFC2445], the DTSTART
5036 property is REQUIRED in the VEVENT component. The conditions
5037 depend on the presence of the DTEND and DURATION properties in the
5038 VEVENT component. Furthermore, the value of the DTEND property
5042 Daboo, et al. Standards Track [Page 90]
5044 RFC 4791 CalDAV March 2007
5047 MUST be later in time than the value of the DTSTART property. The
5048 duration of a VEVENT component with no DTEND and DURATION
5049 properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0
5050 seconds when the DTSTART is a DATE-TIME value.
5052 +---------------------------------------------------------------+
5053 | VEVENT has the DTEND property? |
5054 | +-----------------------------------------------------------+
5055 | | VEVENT has the DURATION property? |
5056 | | +-------------------------------------------------------+
5057 | | | DURATION property value is greater than 0 seconds? |
5058 | | | +---------------------------------------------------+
5059 | | | | DTSTART property is a DATE-TIME value? |
5060 | | | | +-----------------------------------------------+
5061 | | | | | Condition to evaluate |
5062 +---+---+---+---+-----------------------------------------------+
5063 | Y | N | N | * | (start < DTEND AND end > DTSTART) |
5064 +---+---+---+---+-----------------------------------------------+
5065 | N | Y | Y | * | (start < DTSTART+DURATION AND end > DTSTART) |
5066 | | +---+---+-----------------------------------------------+
5067 | | | N | * | (start <= DTSTART AND end > DTSTART) |
5068 +---+---+---+---+-----------------------------------------------+
5069 | N | N | N | Y | (start <= DTSTART AND end > DTSTART) |
5070 +---+---+---+---+-----------------------------------------------+
5071 | N | N | N | N | (start < DTSTART+P1D AND end > DTSTART) |
5072 +---+---+---+---+-----------------------------------------------+
5074 A VTODO component is said to overlap a given time range if the
5075 condition for the corresponding component state specified in the
5076 table below is satisfied. The conditions depend on the presence
5077 of the DTSTART, DURATION, DUE, COMPLETED, and CREATED properties
5078 in the VTODO component. Note that, as specified in [RFC2445], the
5079 DUE value MUST be a DATE-TIME value equal to or after the DTSTART
5098 Daboo, et al. Standards Track [Page 91]
5100 RFC 4791 CalDAV March 2007
5103 +-------------------------------------------------------------------+
5104 | VTODO has the DTSTART property? |
5105 | +---------------------------------------------------------------+
5106 | | VTODO has the DURATION property? |
5107 | | +-----------------------------------------------------------+
5108 | | | VTODO has the DUE property? |
5109 | | | +-------------------------------------------------------+
5110 | | | | VTODO has the COMPLETED property? |
5111 | | | | +---------------------------------------------------+
5112 | | | | | VTODO has the CREATED property? |
5113 | | | | | +-----------------------------------------------+
5114 | | | | | | Condition to evaluate |
5115 +---+---+---+---+---+-----------------------------------------------+
5116 | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND |
5117 | | | | | | ((end > DTSTART) OR |
5118 | | | | | | (end >= DTSTART+DURATION)) |
5119 +---+---+---+---+---+-----------------------------------------------+
5120 | Y | N | Y | * | * | ((start < DUE) OR (start <= DTSTART)) |
5122 | | | | | | ((end > DTSTART) OR (end >= DUE)) |
5123 +---+---+---+---+---+-----------------------------------------------+
5124 | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) |
5125 +---+---+---+---+---+-----------------------------------------------+
5126 | N | N | Y | * | * | (start < DUE) AND (end >= DUE) |
5127 +---+---+---+---+---+-----------------------------------------------+
5128 | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))|
5130 | | | | | | ((end >= CREATED) OR (end >= COMPLETED))|
5131 +---+---+---+---+---+-----------------------------------------------+
5132 | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) |
5133 +---+---+---+---+---+-----------------------------------------------+
5134 | N | N | N | N | Y | (end > CREATED) |
5135 +---+---+---+---+---+-----------------------------------------------+
5136 | N | N | N | N | N | TRUE |
5137 +---+---+---+---+---+-----------------------------------------------+
5139 A VJOURNAL component overlaps a given time range if the condition
5140 for the corresponding component state specified in the table below
5141 is satisfied. The conditions depend on the presence of the
5142 DTSTART property in the VJOURNAL component and on whether the
5143 DTSTART is a DATE-TIME or DATE value. The effective "duration" of
5144 a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE
5145 value, and 0 seconds when the DTSTART is a DATE-TIME value.
5154 Daboo, et al. Standards Track [Page 92]
5156 RFC 4791 CalDAV March 2007
5159 +----------------------------------------------------+
5160 | VJOURNAL has the DTSTART property? |
5161 | +------------------------------------------------+
5162 | | DTSTART property is a DATE-TIME value? |
5163 | | +--------------------------------------------+
5164 | | | Condition to evaluate |
5165 +---+---+--------------------------------------------+
5166 | Y | Y | (start <= DTSTART) AND (end > DTSTART) |
5167 +---+---+--------------------------------------------+
5168 | Y | N | (start < DTSTART+P1D) AND (end > DTSTART) |
5169 +---+---+--------------------------------------------+
5171 +---+---+--------------------------------------------+
5173 A VFREEBUSY component overlaps a given time range if the condition
5174 for the corresponding component state specified in the table below
5175 is satisfied. The conditions depend on the presence in the
5176 VFREEBUSY component of the DTSTART and DTEND properties, and any
5177 FREEBUSY properties in the absence of DTSTART and DTEND. Any
5178 DURATION property is ignored, as it has a special meaning when
5179 used in a VFREEBUSY component.
5181 When only FREEBUSY properties are used, each period in each
5182 FREEBUSY property is compared against the time range, irrespective
5183 of the type of free busy information (free, busy, busy-tentative,
5184 busy-unavailable) represented by the property.
5187 +------------------------------------------------------+
5188 | VFREEBUSY has both the DTSTART and DTEND properties? |
5189 | +--------------------------------------------------+
5190 | | VFREEBUSY has the FREEBUSY property? |
5191 | | +----------------------------------------------+
5192 | | | Condition to evaluate |
5193 +---+---+----------------------------------------------+
5194 | Y | * | (start <= DTEND) AND (end > DTSTART) |
5195 +---+---+----------------------------------------------+
5196 | N | Y | (start < freebusy-period-end) AND |
5197 | | | (end > freebusy-period-start) |
5198 +---+---+----------------------------------------------+
5200 +---+---+----------------------------------------------+
5202 A VALARM component is said to overlap a given time range if the
5203 following condition holds:
5205 (start <= trigger-time) AND (end > trigger-time)
5210 Daboo, et al. Standards Track [Page 93]
5212 RFC 4791 CalDAV March 2007
5215 A VALARM component can be defined such that it triggers repeatedly.
5216 Such a VALARM component is said to overlap a given time range if at
5217 least one of its triggers overlaps the time range.
5219 The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP,
5220 DTSTART, DUE, and LAST-MODIFIED overlap a given time range if the
5221 following condition holds:
5223 (start <= date-time) AND (end > date-time)
5225 Note that if DTEND is not present in a VEVENT, but DURATION is, then
5226 the test should instead operate on the 'effective' DTEND, i.e.,
5227 DTSTART+DURATION. Similarly, if DUE is not present in a VTODO, but
5228 DTSTART and DURATION are, then the test should instead operate on the
5229 'effective' DUE, i.e., DTSTART+DURATION.
5231 The semantic of CALDAV:time-range is not defined for any other
5232 calendar components and properties.
5236 <!ELEMENT time-range EMPTY>
5238 <!ATTLIST time-range start CDATA #IMPLIED
5240 start value: an iCalendar "date with UTC time"
5241 end value: an iCalendar "date with UTC time"
5243 9.10. CALDAV:calendar-multiget XML Element
5245 Name: calendar-multiget
5247 Namespace: urn:ietf:params:xml:ns:caldav
5249 Purpose: CalDAV report used to retrieve specific calendar object
5252 Description: See Section 7.9.
5256 <!ELEMENT calendar-multiget ((DAV:allprop |
5258 DAV:prop)?, DAV:href+)>
5266 Daboo, et al. Standards Track [Page 94]
5268 RFC 4791 CalDAV March 2007
5271 9.11. CALDAV:free-busy-query XML Element
5273 Name: free-busy-query
5275 Namespace: urn:ietf:params:xml:ns:caldav
5277 Purpose: CalDAV report used to generate a VFREEBUSY to determine
5278 busy time over a specific time range.
5280 Description: See Section 7.10.
5284 <!ELEMENT free-busy-query (time-range)>
5286 10. Internationalization Considerations
5288 CalDAV allows internationalized strings to be stored and retrieved
5289 for the description of calendar collections (see Section 5.2.1).
5291 The CALDAV:calendar-query REPORT (Section 7.8) includes a text
5292 searching option controlled by the CALDAV:text-match element, and
5293 details of character handling are covered in the description of that
5294 element (see Section 9.7.5).
5296 11. Security Considerations
5298 HTTP protocol transactions are sent in the clear over the network
5299 unless protection from snooping is negotiated. This can be
5300 accomplished by use of TLS, as defined in [RFC2818]. In particular,
5301 HTTP Basic authentication MUST NOT be used unless TLS is in effect.
5303 Servers MUST take adequate precautions to ensure that malicious
5304 clients cannot consume excessive server resources (CPU, memory, disk,
5305 etc.) through carefully crafted reports. For example, a client could
5306 upload an event with a recurrence rule that specifies a recurring
5307 event occurring every second for the next 100 years, which would
5308 result in approximately 3 x 10^9 instances! A report that asks for
5309 recurrences to be expanded over that range would likely constitute a
5310 denial-of-service attack on the server.
5312 When creating new resources (including calendar collections), clients
5313 MUST ensure that the resource name (the last path segment of the
5314 resource URI) assigned to the new resource does not expose any data
5315 from within the iCalendar resource itself or information about the
5316 nature of a calendar collection. This is required to ensure that the
5317 presence of a specific iCalendar component or nature of components in
5318 a collection cannot be inferred based on the name of a resource.
5322 Daboo, et al. Standards Track [Page 95]
5324 RFC 4791 CalDAV March 2007
5327 When rolling up free-busy information, more information about a
5328 user's events is exposed if busy periods overlap or are adjacent
5329 (this tells the client requesting the free-busy information that the
5330 calendar owner has at least two events, rather than knowing only that
5331 the calendar owner has one or more events during the busy period).
5332 Thus, a conservative approach to calendar data privacy would have
5333 servers always coalesce such busy periods when they are the same
5336 Procedure alarms are a known security risk for either clients or
5337 servers to handle, particularly when the alarm was created by another
5338 agent. Clients and servers are not required to execute such
5341 Security considerations described in iCalendar [RFC2445] and iTIP
5342 [RFC2446] are also applicable to CalDAV.
5344 Beyond these, CalDAV does not raise any security considerations that
5345 are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253],
5348 12. IANA Considerations
5350 This document uses one new URN to identify a new XML namespace. The
5351 URN conforms to a registry mechanism described in [RFC3688].
5353 12.1. Namespace Registration
5355 Registration request for the CalDAV namespace:
5357 URI: urn:ietf:params:xml:ns:caldav
5359 Registrant Contact: See the "Authors' Addresses" section of this
5362 XML: None. Namespace URIs do not represent an XML specification.
5364 13. Acknowledgements
5366 The authors would like to thank the following individuals for
5367 contributing their ideas and support for writing this specification:
5368 Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Andre
5369 Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey
5370 Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov,
5371 Dan Mosedale, Brian Moseley, Francois Perrault, Kervin L. Pierre,
5372 Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari
5373 Urpalainen, Simon Vaillancourt, and Jim Whitehead.
5378 Daboo, et al. Standards Track [Page 96]
5380 RFC 4791 CalDAV March 2007
5383 The authors would also like to thank the Calendaring and Scheduling
5384 Consortium for advice with this specification, and for organizing
5385 interoperability testing events to help refine it.
5389 14.1. Normative References
5391 [RFC2119] Bradner, S., "Key words for use in RFCs to
5392 Indicate Requirement Levels", BCP 14,
5393 RFC 2119, March 1997.
5395 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol
5396 Version 1.0", RFC 2246, January 1999.
5398 [RFC2445] Dawson, F. and Stenerson, D., "Internet
5399 Calendaring and Scheduling Core Object
5400 Specification (iCalendar)", RFC 2445,
5403 [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and
5404 R. Hopson, "iCalendar Transport-Independent
5405 Interoperability Protocol (iTIP) Scheduling
5406 Events, BusyTime, To-dos and Journal
5407 Entries", RFC 2446, November 1998.
5409 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter,
5410 S., and D. Jensen, "HTTP Extensions for
5411 Distributed Authoring -- WEBDAV", RFC 2518,
5414 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk,
5415 H., Masinter, L., Leach, P., and T. Berners-
5416 Lee, "Hypertext Transfer Protocol --
5417 HTTP/1.1", RFC 2616, June 1999.
5419 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
5422 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler,
5423 C., and J. Whitehead, "Versioning Extensions
5424 to WebDAV (Web Distributed Authoring and
5425 Versioning)", RFC 3253, March 2002.
5427 [RFC3688] Mealling, M., "The IETF XML Registry",
5428 BCP 81, RFC 3688, January 2004.
5434 Daboo, et al. Standards Track [Page 97]
5436 RFC 4791 CalDAV March 2007
5439 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
5440 Whitehead, "Web Distributed Authoring and
5441 Versioning (WebDAV) Access Control Protocol",
5444 [RFC4346] Dierks, T. and E. Rescorla, "The Transport
5445 Layer Security (TLS) Protocol Version 1.1",
5446 RFC 4346, April 2006.
5448 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen,
5449 "Internet Application Protocol Collation
5450 Registry", RFC 4790, March 2007.
5452 [W3C.REC-xml-20060816] Paoli, J., Maler, E., Yergeau, F., Sperberg-
5453 McQueen, C., and T. Bray, "Extensible Markup
5454 Language (XML) 1.0 (Fourth Edition)", World
5455 Wide Web Consortium Recommendation REC-xml-
5456 20060816, August 2006,
5457 <http://www.w3.org/TR/2006/REC-xml-20060816>.
5459 14.2. Informative References
5461 [RFC2426] Dawson, F. and T. Howes, "vCard MIME
5462 Directory Profile", RFC 2426, September 1998.
5464 [RFC2739] Small, T., Hennessy, D., and F. Dawson,
5465 "Calendar Attributes for vCard and LDAP",
5466 RFC 2739, January 2000.
5468 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size
5469 Properties for Distributed Authoring and
5470 Versioning (DAV) Collections", RFC 4331,
5473 [RFC4511] Sermersheim, J., "Lightweight Directory
5474 Access Protocol (LDAP): The Protocol",
5475 RFC 4511, June 2006.
5477 [rfc2518bis] Dusseault, L., "HTTP Extensions for
5478 Distributed Authoring - WebDAV", Work
5479 in Progress, December 2006.
5490 Daboo, et al. Standards Track [Page 98]
5492 RFC 4791 CalDAV March 2007
5495 Appendix A. CalDAV Method Privilege Table (Normative)
5497 The following table extends the WebDAV Method Privilege Table
5498 specified in Appendix B of [RFC3744].
5500 +------------+------------------------------------------------------+
5501 | METHOD | PRIVILEGES |
5502 +------------+------------------------------------------------------+
5503 | MKCALENDAR | DAV:bind |
5504 | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced |
5506 +------------+------------------------------------------------------+
5508 Appendix B. Calendar Collections Used in the Examples
5510 This appendix shows the calendar object resources contained in the
5511 calendar collection queried in the examples throughout this document.
5513 The content of the calendar collection is being shown as if it were
5514 returned by a CALDAV:calendar-query REPORT request designed to return
5515 all the calendar data in the collection:
5519 REPORT /bernard/work/ HTTP/1.1
5520 Host: cal.example.com
5522 Content-Type: application/xml; charset="utf-8"
5523 Content-Length: xxxx
5525 <?xml version="1.0" encoding="utf-8" ?>
5526 <C:calendar-query xmlns:D="DAV:"
5527 xmlns:C="urn:ietf:params:xml:ns:caldav">
5533 <C:comp-filter name="VCALENDAR"/>
5539 HTTP/1.1 207 Multi-Status
5540 Content-Type: application/xml; charset="utf-8"
5541 Content-Length: xxxx
5546 Daboo, et al. Standards Track [Page 99]
5548 RFC 4791 CalDAV March 2007
5551 <?xml version="1.0" encoding="utf-8" ?>
5552 <D:multistatus xmlns:D="DAV:"
5553 xmlns:C="urn:ietf:params:xml:ns:caldav">
5556 <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
5559 <D:getetag>"fffff-abcd1"</D:getetag>
5560 <C:calendar-data>BEGIN:VCALENDAR
5562 PRODID:-//Example Corp.//CalDAV Client//EN
5564 LAST-MODIFIED:20040110T032845Z
5567 DTSTART:20000404T020000
5568 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
5574 DTSTART:20001026T020000
5575 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
5582 DTSTAMP:20060206T001102Z
5583 DTSTART;TZID=US/Eastern:20060102T100000
5586 Description:Go Steelers!
5587 UID:74855313FA803DA593CD579A@example.com
5592 <D:status>HTTP/1.1 200 OK</D:status>
5597 <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
5602 Daboo, et al. Standards Track [Page 100]
5604 RFC 4791 CalDAV March 2007
5608 <D:getetag>"fffff-abcd2"</D:getetag>
5609 <C:calendar-data>BEGIN:VCALENDAR
5611 PRODID:-//Example Corp.//CalDAV Client//EN
5613 LAST-MODIFIED:20040110T032845Z
5616 DTSTART:20000404T020000
5617 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
5623 DTSTART:20001026T020000
5624 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
5631 DTSTAMP:20060206T001121Z
5632 DTSTART;TZID=US/Eastern:20060102T120000
5634 RRULE:FREQ=DAILY;COUNT=5
5636 UID:00959BC664CA650E933C892C@example.com
5639 DTSTAMP:20060206T001121Z
5640 DTSTART;TZID=US/Eastern:20060104T140000
5642 RECURRENCE-ID;TZID=US/Eastern:20060104T120000
5643 SUMMARY:Event #2 bis
5644 UID:00959BC664CA650E933C892C@example.com
5649 <D:status>HTTP/1.1 200 OK</D:status>
5654 <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
5658 Daboo, et al. Standards Track [Page 101]
5660 RFC 4791 CalDAV March 2007
5665 <D:getetag>"fffff-abcd3"</D:getetag>
5666 <C:calendar-data>BEGIN:VCALENDAR
5668 PRODID:-//Example Corp.//CalDAV Client//EN
5670 LAST-MODIFIED:20040110T032845Z
5673 DTSTART:20000404T020000
5674 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
5680 DTSTART:20001026T020000
5681 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
5688 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
5689 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
5690 DTSTAMP:20060206T001220Z
5691 DTSTART;TZID=US/Eastern:20060104T100000
5693 LAST-MODIFIED:20060206T001330Z
5694 ORGANIZER:mailto:cyrus@example.com
5698 UID:DC6C50A017428C5216A2F1CD@example.com
5703 <D:status>HTTP/1.1 200 OK</D:status>
5708 <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
5714 Daboo, et al. Standards Track [Page 102]
5716 RFC 4791 CalDAV March 2007
5719 <D:getetag>"fffff-abcd4"</D:getetag>
5720 <C:calendar-data>BEGIN:VCALENDAR
5722 PRODID:-//Example Corp.//CalDAV Client//EN
5724 DTSTAMP:20060205T235335Z
5725 DUE;VALUE=DATE:20060104
5728 UID:DDDEEB7915FA61233B861457@example.com
5731 TRIGGER;RELATED=START:-PT10M
5737 <D:status>HTTP/1.1 200 OK</D:status>
5742 <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
5745 <D:getetag>"fffff-abcd5"</D:getetag>
5746 <C:calendar-data>BEGIN:VCALENDAR
5748 PRODID:-//Example Corp.//CalDAV Client//EN
5750 DTSTAMP:20060205T235300Z
5751 DUE;VALUE=DATE:20060106
5752 LAST-MODIFIED:20060205T235308Z
5756 UID:E10BA47467C5C69BB74E8720@example.com
5759 TRIGGER;RELATED=START:-PT10M
5765 <D:status>HTTP/1.1 200 OK</D:status>
5770 Daboo, et al. Standards Track [Page 103]
5772 RFC 4791 CalDAV March 2007
5778 <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
5781 <D:getetag>"fffff-abcd6"</D:getetag>
5782 <C:calendar-data>BEGIN:VCALENDAR
5784 PRODID:-//Example Corp.//CalDAV Client//EN
5786 COMPLETED:20051223T122322Z
5787 DTSTAMP:20060205T235400Z
5788 DUE;VALUE=DATE:20051225
5789 LAST-MODIFIED:20060205T235308Z
5793 UID:E10BA47467C5C69BB74E8722@example.com
5798 <D:status>HTTP/1.1 200 OK</D:status>
5803 <D:href>http://cal.example.com/bernard/work/abcd7.ics</D:href>
5806 <D:getetag>"fffff-abcd7"</D:getetag>
5807 <C:calendar-data>BEGIN:VCALENDAR
5809 PRODID:-//Example Corp.//CalDAV Client//EN
5811 DTSTAMP:20060205T235600Z
5812 DUE;VALUE=DATE:20060101
5813 LAST-MODIFIED:20060205T235308Z
5817 UID:E10BA47467C5C69BB74E8725@example.com
5822 <D:status>HTTP/1.1 200 OK</D:status>
5826 Daboo, et al. Standards Track [Page 104]
5828 RFC 4791 CalDAV March 2007
5835 <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
5838 <D:getetag>"fffff-abcd8"</D:getetag>
5839 <C:calendar-data>BEGIN:VCALENDAR
5841 PRODID:-//Example Corp.//CalDAV Client//EN
5843 ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
5844 UID:76ef34-54a3d2@example.com
5845 DTSTAMP:20050530T123421Z
5846 DTSTART:20060101T000000Z
5847 DTEND:20060108T000000Z
5848 FREEBUSY:20050531T230000Z/20050601T010000Z
5849 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
5850 FREEBUSY:20060103T100000Z/20060103T120000Z
5851 FREEBUSY:20060104T100000Z/20060104T120000Z
5852 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
5853 FREEBUSY:20060106T100000Z/20060106T120000Z
5858 <D:status>HTTP/1.1 200 OK</D:status>
5882 Daboo, et al. Standards Track [Page 105]
5884 RFC 4791 CalDAV March 2007
5895 EMail: cyrus@daboo.name
5896 URI: http://www.apple.com/
5899 Bernard Desruisseaux
5901 600 Blvd. de Maisonneuve West
5903 Montreal, QC H3A 3J2
5906 EMail: bernard.desruisseaux@oracle.com
5907 URI: http://www.oracle.com/
5916 EMail: ldusseault@commerce.net
5917 URI: http://commerce.net/
5938 Daboo, et al. Standards Track [Page 106]
5940 RFC 4791 CalDAV March 2007
5943 Full Copyright Statement
5945 Copyright (C) The IETF Trust (2007).
5947 This document is subject to the rights, licenses and restrictions
5948 contained in BCP 78, and except as set forth therein, the authors
5949 retain all their rights.
5951 This document and the information contained herein are provided on an
5952 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5953 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5954 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5955 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5956 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5957 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5959 Intellectual Property
5961 The IETF takes no position regarding the validity or scope of any
5962 Intellectual Property Rights or other rights that might be claimed to
5963 pertain to the implementation or use of the technology described in
5964 this document or the extent to which any license under such rights
5965 might or might not be available; nor does it represent that it has
5966 made any independent effort to identify any such rights. Information
5967 on the procedures with respect to rights in RFC documents can be
5968 found in BCP 78 and BCP 79.
5970 Copies of IPR disclosures made to the IETF Secretariat and any
5971 assurances of licenses to be made available, or the result of an
5972 attempt made to obtain a general license or permission for the use of
5973 such proprietary rights by implementers or users of this
5974 specification can be obtained from the IETF on-line IPR repository at
5975 http://www.ietf.org/ipr.
5977 The IETF invites any interested party to bring to its attention any
5978 copyrights, patents or patent applications, or other proprietary
5979 rights that may cover technology that may be required to implement
5980 this standard. Please address the information to the IETF at
5985 Funding for the RFC Editor function is currently provided by the
5994 Daboo, et al. Standards Track [Page 107]
projects / friendica-addons.git / blob