idnits 2.17.1 draft-dusseault-caldav-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5145. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2006) is 6435 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-webdav-rfc2518bis' is defined on line 4329, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-newman-i18n-comparator-13 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2445 (Obsoleted by RFC 5545) ** Obsolete normative reference: RFC 2446 (Obsoleted by RFC 5546) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-18) exists of draft-ietf-webdav-rfc2518bis-15 -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple Computer 4 Expires: March 17, 2007 B. Desruisseaux 5 Oracle 6 L. Dusseault 7 OSAF 8 September 13, 2006 10 Calendaring Extensions to WebDAV (CalDAV) 11 draft-dusseault-caldav-15 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 17, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document specifies a set of methods, headers, message bodies, 45 properties, and reports that define calendar access extensions to the 46 WebDAV protocol. The new protocol elements are intended to make 47 WebDAV-based calendaring and scheduling an interoperable standard 48 that supports calendar access, calendar management, calendar sharing, 49 and calendar publishing. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5 55 1.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5 56 1.3. Method Preconditions and Postconditions . . . . . . . . . 6 57 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6 58 3. Calendaring Data Model . . . . . . . . . . . . . . . . . . . 7 59 3.1. Calendar Server . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Recurrence and the Data Model . . . . . . . . . . . . . . 8 61 4. Calendar Resources . . . . . . . . . . . . . . . . . . . . . 9 62 4.1. Calendar Object Resources . . . . . . . . . . . . . . . . 9 63 4.2. Calendar Collection . . . . . . . . . . . . . . . . . . . 10 64 5. Calendar Access Feature . . . . . . . . . . . . . . . . . . . 11 65 5.1. Calendar Access Support . . . . . . . . . . . . . . . . . 11 66 5.1.1. Example: Using OPTIONS for the Discovery of 67 Calendar Access Support . . . . . . . . . . . . . . . 12 68 5.2. Calendar Collection Properties . . . . . . . . . . . . . 12 69 5.2.1. CALDAV:calendar-description Property . . . . . . . . 12 70 5.2.2. CALDAV:calendar-timezone Property . . . . . . . . . . 13 71 5.2.3. CALDAV:supported-calendar-component-set Property . . 14 72 5.2.4. CALDAV:supported-calendar-data Property . . . . . . . 15 73 5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 16 74 5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 17 75 5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 18 76 5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 18 77 5.2.9. CALDAV:max-attendees-per-instance Property . . . . . 19 78 5.2.10. Additional Precondition for PROPPATCH . . . . . . . . 20 79 5.3. Creating Resources . . . . . . . . . . . . . . . . . . . 20 80 5.3.1. MKCALENDAR Method . . . . . . . . . . . . . . . . . . 20 81 5.3.1.1. Status Codes . . . . . . . . . . . . . . . . . . 22 82 5.3.1.2. Example: Successful MKCALENDAR request . . . . . 23 83 5.3.2. Creating Calendar Object Resources . . . . . . . . . 25 84 5.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 26 85 5.3.3. Non-standard components, properties and parameters . 28 86 5.3.4. Calendar Object Resource Entity Tag . . . . . . . . . 28 87 6. Calendaring Access Control . . . . . . . . . . . . . . . . . 29 88 6.1. Calendaring Privilege . . . . . . . . . . . . . . . . . . 29 89 6.1.1. CALDAV:read-free-busy Privilege . . . . . . . . . . . 29 90 6.2. Additional Principal Property . . . . . . . . . . . . . . 30 91 6.2.1. CALDAV:calendar-home-set Property . . . . . . . . . . 30 92 7. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . 31 93 7.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 31 94 7.2. Ordinary collections . . . . . . . . . . . . . . . . . . 31 95 7.3. Date and floating time . . . . . . . . . . . . . . . . . 32 96 7.4. Time range filtering . . . . . . . . . . . . . . . . . . 32 97 7.5. Searching Text: Collations . . . . . . . . . . . . . . . 33 98 7.5.1. CALDAV:supported-collation-set Property . . . . . . . 34 99 7.6. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 34 100 7.7. Non-standard components, properties and parameters . . . 35 101 7.8. CALDAV:calendar-query Report . . . . . . . . . . . . . . 35 102 7.8.1. Example: Partial retrieval of events by time range . 38 103 7.8.2. Example: Partial retrieval of recurring events . . . 42 104 7.8.3. Example: Expanded retrieval of recurring events . . . 45 105 7.8.4. Example: Partial retrieval of stored free busy 106 components . . . . . . . . . . . . . . . . . . . . . 47 107 7.8.5. Example: Retrieval of to-dos by alarm time range . . 49 108 7.8.6. Example: Retrieval of event by UID . . . . . . . . . 51 109 7.8.7. Example: Retrieval of events by PARTSTAT . . . . . . 53 110 7.8.8. Example: Retrieval of events only . . . . . . . . . . 55 111 7.8.9. Example: Retrieval of all pending to-dos . . . . . . 59 112 7.8.10. Example: Attempt to query unsupported property . . . 62 113 7.9. CALDAV:calendar-multiget Report . . . . . . . . . . . . . 63 114 7.9.1. Example: Successful CALDAV:calendar-multiget Report . 64 115 7.10. CALDAV:free-busy-query Report . . . . . . . . . . . . . . 66 116 7.10.1. Example: Successful CALDAV:free-busy-query Report . . 68 117 8. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 68 118 8.1. Client-to-client Interoperability . . . . . . . . . . . . 69 119 8.2. Synchronization Operations . . . . . . . . . . . . . . . 69 120 8.2.1. Use of Reports . . . . . . . . . . . . . . . . . . . 69 121 8.2.1.1. Restrict the Time Range . . . . . . . . . . . . . 69 122 8.2.1.2. Synchronize by Time Range . . . . . . . . . . . . 69 123 8.2.1.3. Synchronization Process . . . . . . . . . . . . . 70 124 8.2.2. Restrict the Properties Returned . . . . . . . . . . 72 125 8.3. Use of Locking . . . . . . . . . . . . . . . . . . . . . 72 126 8.4. Finding calendars . . . . . . . . . . . . . . . . . . . . 72 127 8.5. Storing and Using Attachments . . . . . . . . . . . . . . 74 128 8.5.1. Inline attachments . . . . . . . . . . . . . . . . . 74 129 8.5.2. External attachments . . . . . . . . . . . . . . . . 75 130 8.6. Storing and Using Alarms . . . . . . . . . . . . . . . . 76 131 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 77 132 9.1. CALDAV:calendar XML Element . . . . . . . . . . . . . . . 77 133 9.2. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . 77 134 9.3. CALDAV:mkcalendar-response XML Element . . . . . . . . . 77 135 9.4. CALDAV:supported-collation XML Element . . . . . . . . . 78 136 9.5. CALDAV:calendar-query XML Element . . . . . . . . . . . . 78 137 9.6. CALDAV:calendar-data XML Element . . . . . . . . . . . . 79 138 9.6.1. CALDAV:comp XML Element . . . . . . . . . . . . . . . 80 139 9.6.2. CALDAV:allcomp XML Element . . . . . . . . . . . . . 80 140 9.6.3. CALDAV:allprop XML Element . . . . . . . . . . . . . 81 141 9.6.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 81 142 9.6.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 82 143 9.6.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 83 144 9.6.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 84 145 9.7. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 84 146 9.7.1. CALDAV:comp-filter XML Element . . . . . . . . . . . 85 147 9.7.2. CALDAV:prop-filter XML Element . . . . . . . . . . . 85 148 9.7.3. CALDAV:param-filter XML Element . . . . . . . . . . . 86 149 9.7.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 87 150 9.7.5. CALDAV:text-match XML Element . . . . . . . . . . . . 87 151 9.8. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 88 152 9.9. CALDAV:time-range XML Element . . . . . . . . . . . . . . 88 153 9.10. CALDAV:calendar-multiget XML Element . . . . . . . . . . 93 154 9.11. CALDAV:free-busy-query XML Element . . . . . . . . . . . 94 155 10. Internationalization Considerations . . . . . . . . . . . . . 94 156 11. Security Considerations . . . . . . . . . . . . . . . . . . . 94 157 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 95 158 12.1. Namespace Registration . . . . . . . . . . . . . . . . . 95 159 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 160 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 161 14.1. Normative References . . . . . . . . . . . . . . . . . . 96 162 14.2. Informative References . . . . . . . . . . . . . . . . . 97 163 Appendix A. CalDAV Method Privilege Table (Normative) . . . . . 97 164 Appendix B. Calendar collections used in the examples . . . . . 98 165 Appendix C. Changes (to be removed prior to publication as an 166 RFC) . . . . . . . . . . . . . . . . . . . . . . . . 104 167 C.1. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 104 168 C.2. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 105 169 C.3. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 105 170 C.4. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 106 171 C.5. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 106 172 C.6. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 107 173 C.7. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 108 174 C.8. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 109 175 C.9. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 110 176 C.10. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 111 177 C.11. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 111 178 C.12. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 112 179 C.13. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 113 180 C.14. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 113 181 C.15. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 113 182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 183 Intellectual Property and Copyright Statements . . . . . . . . . 115 185 1. Introduction 187 The concept of using HTTP [RFC2616] and WebDAV [RFC2518] as a basis 188 for a calendar access protocol is by no means a new concept: it was 189 discussed in the IETF CALSCH working group as early as 1997 or 1998. 190 Several companies have implemented calendar access protocols using 191 HTTP to upload and download iCalendar [RFC2445] objects, and using 192 WebDAV to get listings of resources. However, those implementations 193 do not interoperate because there are many small and big decisions to 194 be made in how to model calendaring data as WebDAV resources, as well 195 as how to implement required features that aren't already part of 196 WebDAV. This document proposes a way to model calendar data in 197 WebDAV, with additional features to make an interoperable calendar 198 access protocol. 200 1.1. Notational Conventions 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 The term "protected" is used in the Conformance field of property 207 definitions as defined in Section 1.4.2 of [RFC3253]. 209 When XML element types in the namespaces "DAV:" and 210 "urn:ietf:params:xml:ns:caldav" are referenced in this document 211 outside of the context of an XML fragment, the string "DAV:" and 212 "CALDAV:" will be prefixed to the element type names respectively. 214 1.2. XML Namespaces and Processing 216 Definitions of XML elements in this document use XML element type 217 declarations (as found in XML Document Type Declarations), described 218 in Section 3.2 of [W3C.REC-xml-20060816]. 220 The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML 221 elements defined in this specification, its revisions, and related 222 CalDAV specifications. XML elements defined by individual 223 implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav" 224 namespace, and instead should use a namespace that they control. 226 The XML declarations used in this document do not include namespace 227 information. Thus, implementers must not use these declarations as 228 the only way to create valid CalDAV properties or to validate CalDAV 229 XML element type. Some of the declarations refer to XML elements 230 defined by WebDAV [RFC2518] which use the "DAV:" namespace. Wherever 231 such XML elements appear, they are explicitly prefixed with "DAV:" to 232 avoid confusion. 234 Also note that some CalDAV XML element names are identical to WebDAV 235 XML element names, though their namespace differs. Care must be 236 taken not to confuse the two sets of names. 238 Processing of XML by CalDAV clients and servers MUST follow the rules 239 described in [RFC2518], in particular Section 14, and Appendices 3 240 and 4 of that specification. 242 1.3. Method Preconditions and Postconditions 244 A "precondition" of a method describes the state of the server that 245 must be true for that method to be performed. A "postcondition" of a 246 method describes the state of the server that must be true after that 247 method has been completed. If a method precondition or postcondition 248 for a request is not satisfied, the response status of the request 249 MUST be either 403 (Forbidden) if the request should not be repeated 250 because it will always fail, or 409 (Conflict) if it is expected that 251 the user might be able to resolve the conflict and resubmit the 252 request. 254 In order to allow better client handling of 403 and 409 responses, a 255 distinct XML element type is associated with each method precondition 256 and postcondition of a request. When a particular precondition is 257 not satisfied or a particular postcondition cannot be achieved, the 258 appropriate XML element MUST be returned as the child of a top-level 259 DAV:error element in the response body, unless otherwise negotiated 260 by the request. 262 2. Requirements Overview 264 This section lists what functionality is required of a CalDAV server. 265 To advertise support for CalDAV, a server: 267 o MUST support iCalendar [RFC2445] as a media type for calendar 268 object resource format; 270 o MUST support WebDAV Class 1 [RFC2518] (note that [I-D.ietf-webdav- 271 rfc2518bis] describes clarifications to [RFC2518] that aid 272 interoperability); 274 o MUST support WebDAV ACL [RFC3744] with the additional privilege 275 defined in Section 6.1 of this document; 277 o MUST support transport over TLS [RFC2246] as defined in [RFC2818] 278 (note that [RFC2246] has been obsoleted by [RFC4346]); 280 o MUST support ETags [RFC2616] with additional requirements 281 specified in Section 5.3.4 of this document; 283 o MUST support all calendaring REPORTs defined in Section 7 of this 284 document; and 286 o MUST advertise support on all calendar collections and calendar 287 object resources for the calendaring REPORTs in the DAV:supported- 288 report-set property as defined in Versioning Extensions to WebDAV 289 [RFC3253]. 291 In addition, a server: 293 o SHOULD support the MKCALENDAR method defined in Section 5.3.1 of 294 this document. 296 3. Calendaring Data Model 298 One of the features which has made WebDAV a successful protocol is 299 its firm data model. This makes it a useful framework for other 300 applications such as calendaring. This specification follows the 301 same pattern by developing all features based on a well-described 302 data model. 304 As a brief overview, a CalDAV calendar is modeled as a WebDAV 305 collection with a defined structure; each calendar collection 306 contains a number of resources representing calendar objects as its 307 direct child resource. Each resource representing a calendar object 308 (event or to-do, or journal entry, or other calendar components) is 309 called a "calendar object resource". Each calendar object resource 310 and each calendar collection can be individually locked and have 311 individual WebDAV properties. Requirements derived from this model 312 are provided in Section 4.1 and Section 4.2. 314 3.1. Calendar Server 316 A CalDAV server is a calendaring-aware engine combined with a WebDAV 317 repository. A WebDAV repository is a set of WebDAV collections, 318 containing other WebDAV resources, within a unified URL namespace. 319 For example, the repository "http://www.example.com/webdav/" may 320 contain WebDAV collections and resources, all of which have URLs 321 beginning with "http://www.example.com/webdav/". Note that the root 322 URL "http://www.example.com/" may not itself be a WebDAV repository 323 (for example, if the WebDAV support is implemented through a servlet 324 or other Web server extension). 326 A WebDAV repository MAY include calendar data in some parts of its 327 URL namespace, and non-calendaring data in other parts. 329 A WebDAV repository can advertise itself as a CalDAV server if it 330 supports the functionality defined in this specification at any point 331 within the root of the repository. That might mean that calendaring 332 data is spread throughout the repository and mixed with non-calendar 333 data in nearby collections (e.g., calendar data may be found in 334 /home/lisa/calendars/ as well as in /home/bernard/calendars/, and 335 non-calendar data in /home/lisa/contacts/). Or, it might mean that 336 calendar data can be found only in certain sections of the repository 337 (e.g., /calendar/). Calendaring features are only required in the 338 repository sections that are or contain calendar object resources. 339 So a repository confining calendar data to the /calendar/ collection 340 would only need to support the CalDAV required features within that 341 collection. 343 The CalDAV server or repository is the canonical location for 344 calendar data and state information. Clients may submit requests to 345 change data or download data. Clients may store calendar objects 346 offline and attempt to synchronize at a later time. However, clients 347 MUST be prepared for calendar data on the server to change between 348 the time of last synchronization and when attempting an update, as 349 calendar collections may be shared and accessible via multiple 350 clients. Entity tags and other features make this possible. 352 3.2. Recurrence and the Data Model 354 Recurrence is an important part of the data model because it governs 355 how many resources are expected to exist. This specification models 356 a recurring calendar component and its recurrence exceptions as a 357 single resource. In this model, recurrence rules, recurrence dates, 358 exception rules, and exception dates are all part of the data in a 359 single calendar object resource. This model avoids problems of 360 limiting how many recurrence instances to store in the repository, 361 how to keep recurrence instances in sync with the recurring calendar 362 component, and how to link recurrence exceptions with the recurring 363 calendar component. It also results in less data to synchronize 364 between client and server, and makes it easier to make changes to all 365 recurrence instances or to a recurrence rule. It makes it easier to 366 create a recurring calendar component, and easier to delete all 367 recurrence instances. 369 Clients are not forced to retrieve information about all recurrence 370 instances of a recurring component. The CALDAV:calendar-query and 371 CALDAV:calendar-multiget REPORTs defined in this document allow 372 clients to retrieve only recurrence instances that overlap a given 373 time range. 375 4. Calendar Resources 377 4.1. Calendar Object Resources 379 Calendar object resources contained in calendar collections MUST NOT 380 contain more than one type of calendar component (e.g., VEVENT, 381 VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE 382 components which MUST be specified for each unique TZID parameter 383 value specified in the iCalendar object. For instance, a calendar 384 object resource can contain two VEVENT components and one VTIMEZONE 385 component, but it cannot contain one VEVENT component and one VTODO 386 component. Instead the VEVENT and VTODO components would have to be 387 stored in separate calendar object resources in the same collection. 389 Calendar object resources contained in calendar collections MUST NOT 390 specify the iCalendar METHOD property. 392 The UID property value of the calendar components contained in a 393 calendar object resource MUST be unique in the scope of the calendar 394 collection in which they are stored. 396 Calendar components in a calendar collection that have different UID 397 property values MUST be stored in separate calendar object resources. 399 Calendar components with the same UID property value, in a given 400 calendar collection, MUST be contained in the same calendar object 401 resource. This ensures that all components in a recurrence "set" are 402 contained in the same calendar object resource. It is possible for a 403 calendar object resource to just contain components that represent 404 "overridden" instances (ones which modify the behavior of a regular 405 instance, and thus include a RECURRENCE-ID property), without also 406 including the "master" recurring component (the one that defines the 407 recurrence "set" and does not contain any "RECURRENCE-ID" property). 409 For example, given the following iCalendar object: 411 BEGIN:VCALENDAR 412 PRODID:-//Example Corp.//CalDAV Client//EN 413 VERSION:2.0 414 BEGIN:VEVENT 415 UID:1@example.com 416 SUMMARY:One-off Meeting 417 DTSTAMP:20041210T183904Z 418 DTSTART:20041207T120000Z 419 DTEND:20041207T130000Z 420 END:VEVENT 421 BEGIN:VEVENT 422 UID:2@example.com 423 SUMMARY:Weekly Meeting 424 DTSTAMP:20041210T183838Z 425 DTSTART:20041206T120000Z 426 DTEND:20041206T130000Z 427 RRULE:FREQ=WEEKLY 428 END:VEVENT 429 BEGIN:VEVENT 430 UID:2@example.com 431 SUMMARY:Weekly Meeting 432 RECURRENCE-ID:20041213T120000Z 433 DTSTAMP:20041210T183838Z 434 DTSTART:20041213T130000Z 435 DTEND:20041213T140000Z 436 END:VEVENT 437 END:VCALENDAR 439 The VEVENT component with the UID value "1@example.com", would be 440 stored in its own calendar object resource. The two VEVENT 441 components with the UID value "2@example.com", which represent a 442 recurring event where one recurrence instance has been overridden, 443 would be stored in the same calendar object resource. 445 4.2. Calendar Collection 447 A calendar collection contains calendar object resources that 448 represent calendar components within a calendar. A calendar 449 collection is manifested to clients as a WebDAV resource collection 450 identified by a URL. A calendar collection MUST report the DAV: 451 collection and CALDAV:calendar XML elements in the value of the DAV: 452 resourcetype property. The element type declaration for CALDAV: 453 calendar is: 455 457 A calendar collection can be created through provisioning (e.g., 458 automatically created when a user's account is provisioned), or it 459 can be created with the MKCALENDAR method (see Section 5.3.1). This 460 method can be useful for a user to create additional calendars (e.g., 461 soccer schedule) or for users to share a calendar (e.g., team events 462 or conference room). Note however that this document doesn't define 463 what extra calendar collections are for. Users must rely on non- 464 standard cues to find out what a calendar collection is for, or use 465 the CALDAV:calendar-description property defined in Section 5.2.1 to 466 provide such a cue. 468 The following restrictions are applied to the resources within a 469 calendar collection: 471 a. Calendar collections MUST only contain calendar object resources 472 and collections that are not calendar collections. i.e., the only 473 "top-level" non-collection resources allowed in a calendar 474 collection are calendar object resources. This ensures that 475 calendar clients do not have to deal with non-calendar data in a 476 calendar collection, though they do have to distinguish between 477 calendar object resources and collections when using standard 478 WebDAV techniques to examine the contents of a collection. 480 b. Collections contained in calendar collections MUST NOT contain 481 calendar collections at any depth. i.e., "nesting" of calendar 482 collections within other calendar collections at any depth is not 483 allowed. This specification does not define how collections 484 contained in a calendar collection are used or how they relate to 485 any calendar object resources contained in the calendar 486 collection. 488 Multiple calendar collections MAY be children of the same collection. 490 5. Calendar Access Feature 492 5.1. Calendar Access Support 494 A server supporting the features described in this document MUST 495 include "calendar-access" as a field in the DAV response header from 496 an OPTIONS request on any resource that supports any calendar 497 properties, reports, method, or privilege. A value of "calendar- 498 access" in the DAV response header MUST indicate that the server 499 supports all MUST level requirements specified in this document. 501 5.1.1. Example: Using OPTIONS for the Discovery of Calendar Access 502 Support 504 >> Request << 506 OPTIONS /home/bernard/calendars/ HTTP/1.1 507 Host: cal.example.com 509 >> Response << 511 HTTP/1.1 200 OK 512 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 513 Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL 514 DAV: 1, 2, 3, access-control, calendar-access 515 Date: Fri, 11 Nov 2005 09:32:12 GMT 516 Content-Length: 0 518 In this example, the OPTIONS method returns the value "calendar- 519 access" in the DAV response header to indicate that the collection 520 "/home/bernard/calendars/" supports the properties, reports, methods, 521 or privileges defined in this specification. 523 5.2. Calendar Collection Properties 525 This section defines properties that MAY be defined on calendar 526 collections. 528 5.2.1. CALDAV:calendar-description Property 530 Name: calendar-description 532 Namespace: urn:ietf:params:xml:ns:caldav 534 Purpose: Provides a human-readable description of the calendar 535 collection. 537 Conformance: This property MAY be defined on any calendar collection. 538 If defined, it MAY be protected and SHOULD NOT be returned by a 539 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 540 [RFC2518]). An xml:lang attribute indicating the human language 541 of the description SHOULD be set for this property by clients or 542 through server provisioning. Servers MUST return any xml:lang 543 attribute if set for the property. 545 Description: If present, the property contains a description of the 546 calendar collection that is suitable for presentation to a user. 547 If not present, the client should assume no description for the 548 calendar collection. 550 Definition: 552 553 PCDATA value: string 555 Example: 557 Calendrier de Mathilde Desruisseaux 561 5.2.2. CALDAV:calendar-timezone Property 563 Name: calendar-timezone 565 Namespace: urn:ietf:params:xml:ns:caldav 567 Purpose: Specifies a time zone on a calendar collection. 569 Conformance: This property SHOULD be defined on all calendar 570 collections. If defined, it SHOULD NOT be returned by a PROPFIND 571 DAV:allprop request (as defined in Section 12.14.1 of [RFC2518]). 573 Description: The CALDAV:calendar-timezone property is used to specify 574 the time zone the server should rely on to resolve "date" values 575 and "date with local time" values (i.e., floating time) to "date 576 with UTC time" values. The server will require this information 577 to determine if a calendar component scheduled with "date" values 578 or "date with local time" values overlaps a CALDAV:time-range 579 specified in a CALDAV:calendar-query REPORT. The server will also 580 require this information to compute the proper FREEBUSY time 581 period as "date with UTC time" in the VFREEBUSY component returned 582 in a response to a CALDAV:free-busy-query REPORT request that 583 takes into account calendar components scheduled with "date" 584 values or "date with local time" values. In the absence of this 585 property the server MAY rely on the time zone of their choice. 587 Note: The iCalendar data embedded within the CALDAV:calendar-timezone 588 XML element MUST follow the standard XML character data encoding 589 rules, including use of <, >, & etc entity encoding or 590 the use of a construct. In the later case the 591 iCalendar data cannot contain the character sequence "]]>" which 592 is the end delimiter for the CDATA section. 594 Definition: 596 597 PCDATA value: an iCalendar object with exactly one VTIMEZONE 598 component. 600 Example: 602 BEGIN:VCALENDAR 604 PRODID:-//Example Corp.//CalDAV Client//EN 605 VERSION:2.0 606 BEGIN:VTIMEZONE 607 TZID:US-Eastern 608 LAST-MODIFIED:19870101T000000Z 609 BEGIN:STANDARD 610 DTSTART:19671029T020000 611 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 612 TZOFFSETFROM:-0400 613 TZOFFSETTO:-0500 614 TZNAME:Eastern Standard Time (US & Canada) 615 END:STANDARD 616 BEGIN:DAYLIGHT 617 DTSTART:19870405T020000 618 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 619 TZOFFSETFROM:-0500 620 TZOFFSETTO:-0400 621 TZNAME:Eastern Daylight Time (US & Canada) 622 END:DAYLIGHT 623 END:VTIMEZONE 624 END:VCALENDAR 625 627 5.2.3. CALDAV:supported-calendar-component-set Property 629 Name: supported-calendar-component-set 631 Namespace: urn:ietf:params:xml:ns:caldav 633 Purpose: Specifies the calendar component types (e.g., VEVENT, VTODO, 634 etc.) that calendar object resources can contain in the calendar 635 collection. 637 Conformance: This property MAY be defined on any calendar collection. 638 If defined, it MUST be protected and SHOULD NOT be returned by a 639 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 640 [RFC2518]). 642 Description: The CALDAV:supported-calendar-component-set property is 643 used to specify restrictions on the calendar component types that 644 calendar object resources may contain in a calendar collection. 645 Any attempt by the client to store calendar object resources with 646 component types not listed in this property, if it exists, MUST 647 result in an error, with the CALDAV:supported-calendar-component 648 precondition (Section 5.3.2.1) being violated. Since this 649 property is protected it cannot be changed by clients using a 650 PROPPATCH request. However, clients can initialize the value of 651 this property when creating a new calendar collection with 652 MKCALENDAR. The empty-element tag MUST 653 only be specified if support for calendar object resources that 654 only contain VTIMEZONE components is provided or desired. Support 655 for VTIMEZONE components in calendar object resources that contain 656 VEVENT or VTODO components is always assumed. In the absence of 657 this property the server MUST accept all component types, and the 658 client can assume that. 660 Definition: 662 664 Example: 666 668 669 670 672 5.2.4. CALDAV:supported-calendar-data Property 674 Name: supported-calendar-data 676 Namespace: urn:ietf:params:xml:ns:caldav 678 Purpose: Specifies what media types are allowed for calendar object 679 resources in a calendar collection. 681 Conformance: This property MAY be defined on any calendar collection. 682 If defined, it MUST be protected and SHOULD NOT be returned by a 683 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 684 [RFC2518]). 686 Description: The CALDAV:supported-calendar-data property is used to 687 specify the media type supported for the calendar object resources 688 contained in a given calendar collection (e.g., iCalendar version 689 2.0). Any attempt by the client to store calendar object 690 resources with a media type not listed in this property MUST 691 result in an error, with the CALDAV:supported-calendar-data 692 precondition (Section 5.3.2.1) being violated. In the absence of 693 this property the server MUST only accept data with the media type 694 "text/calendar" and iCalendar version 2.0, and clients can assume 695 that. 697 Definition: 699 701 Example: 703 705 706 708 5.2.5. CALDAV:max-resource-size Property 710 Name: max-resource-size 712 Namespace: urn:ietf:params:xml:ns:caldav 714 Purpose: Provides a numeric value indicating the maximum size of 715 resource in octets that the server is willing to accept when a 716 calendar object resource is stored in a calendar collection. 718 Conformance: This property MAY be defined on any calendar collection. 719 If defined, it MUST be protected and SHOULD NOT be returned by a 720 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 721 [RFC2518]). 723 Description: The CALDAV:max-resource-size is used to specify a 724 numeric value that represents the maximum size in octets that the 725 server is willing to accept when a calendar object resource is 726 stored in a calendar collection. Any attempt to store a calendar 727 object resource exceeding this size MUST result in an error, with 728 the CALDAV:max-resource-size precondition (Section 5.3.2.1) being 729 violated. In the absence of this property the client can assume 730 that the server will allow storing a resource of any reasonable 731 size. 733 Definition: 735 736 PCDATA value: a numeric value (positive integer) 738 Example: 740 102400 743 5.2.6. CALDAV:min-date-time Property 745 Name: min-date-time 747 Namespace: urn:ietf:params:xml:ns:caldav 749 Purpose: Provides a date-time value indicating the earliest date and 750 time (in UTC) that the server is willing to accept for any date or 751 time value in a calendar object resource stored in a calendar 752 collection. 754 Conformance: This property MAY be defined on any calendar collection. 755 If defined, it MUST be protected and SHOULD NOT be returned by a 756 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 757 [RFC2518]). 759 Description: The CALDAV:min-date-time is used to specify an iCalendar 760 DATE-TIME value in UTC that indicates the earliest inclusive date 761 that the server is willing to accept for any explicit date or time 762 value in a calendar object resource stored in a calendar 763 collection. Any attempt to store a calendar object resource using 764 a date or time value earlier than this value MUST result in an 765 error, with the CALDAV:min-date-time precondition 766 (Section 5.3.2.1) being violated. Note that servers MUST accept 767 recurring components that specify instances beyond this limit, 768 provided none of those instances have been overridden. In that 769 case the server MAY simply ignore those instances outside of the 770 acceptable range when processing reports on the calendar object 771 resource. In the absence of this property the client can assume 772 any valid iCalendar date may be used at least up to the CALDAV: 773 max-date-time value if that is defined. 775 Definition: 777 778 PCDATA value: an iCalendar format DATE-TIME value in UTC 780 Example: 782 19000101T000000Z 785 5.2.7. CALDAV:max-date-time Property 787 Name: max-date-time 789 Namespace: urn:ietf:params:xml:ns:caldav 791 Purpose: Provides a date-time value indicating the latest date and 792 time (in UTC) that the server is willing to accept for any date or 793 time value in a calendar object resource stored in a calendar 794 collection. 796 Conformance: This property MAY be defined on any calendar collection. 797 If defined, it MUST be protected and SHOULD NOT be returned by a 798 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 799 [RFC2518]). 801 Description: The CALDAV:max-date-time is used to specify an iCalendar 802 DATE-TIME value in UTC that indicates the inclusive latest date 803 that the server is willing to accept for any date or time value in 804 a calendar object resource stored in a calendar collection. Any 805 attempt to store a calendar object resource using a date or time 806 value later than this value MUST result in an error, with the 807 CALDAV:max-date-time precondition (Section 5.3.2.1) being 808 violated. Note that servers MUST accept recurring components that 809 specify instances beyond this limit, provided none of those 810 instances have been overridden. In that case the server MAY 811 simply ignore those instances outside of the acceptable range when 812 processing reports on the calendar object resource. In the 813 absence of this property the client can assume any valid iCalendar 814 date may be used at least down to the CALDAV:min-date-time value 815 if that is defined. 817 Definition: 819 820 PCDATA value: an iCalendar format DATE-TIME value in UTC 822 Example: 824 20491231T235959Z 827 5.2.8. CALDAV:max-instances Property 828 Name: max-instances 830 Namespace: urn:ietf:params:xml:ns:caldav 832 Purpose: Provides a numeric value indicating the maximum number of 833 recurrence instances that a calendar object resource stored in a 834 calendar collection can generate. 836 Conformance: This property MAY be defined on any calendar collection. 837 If defined, it MUST be protected and SHOULD NOT be returned by a 838 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 839 [RFC2518]). 841 Description: The CALDAV:max-instances is used to specify a numeric 842 value that indicates the maximum number of recurrence instances 843 that a calendar object resource stored in a calendar collection 844 can generate. Any attempt to store a calendar object resource 845 with a recurrence pattern that generates more instances than this 846 value MUST result in an error, with the CALDAV:max-instances 847 precondition (Section 5.3.2.1) being violated. In the absence of 848 this property the client can assume that the server has no limits 849 on the number of recurrence instances it can handle or expand. 851 Definition: 853 854 PCDATA value: a numeric value (integer greater than zero) 856 Example: 858 100 861 5.2.9. CALDAV:max-attendees-per-instance Property 863 Name: max-attendees-per-instance 865 Namespace: urn:ietf:params:xml:ns:caldav 867 Purpose: Provides a numeric value indicating the maximum number of 868 ATTENDEE properties in any instance of a calendar object resource 869 stored in a calendar collection. 871 Conformance: This property MAY be defined on any calendar collection. 872 If defined, it MUST be protected and SHOULD NOT be returned by a 873 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 874 [RFC2518]). 876 Description: The CALDAV:max-attendees-per-instance is used to specify 877 a numeric value that indicates the maximum number of iCalendar 878 ATTENDEE properties on any one instance of a calendar object 879 resource stored in a calendar collection. Any attempt to store a 880 calendar object resource with more ATTENDEE properties per 881 instance than this value MUST result in an error, with the CALDAV: 882 max-attendees-per-instance precondition (Section 5.3.2.1) being 883 violated. In the absence of this property the client can assume 884 that the server can handle any number of ATTENDEE properties in a 885 calendar component. 887 Definition: 889 890 PCDATA value: a numeric value (integer greater than zero) 892 Example: 894 25 898 5.2.10. Additional Precondition for PROPPATCH 900 This specification requires an additional Precondition for the 901 PROPPATCH method. The precondition is: 903 (CALDAV:valid-calendar-data): The time zone specified in CALDAV: 904 calendar-timezone property MUST be a valid iCalendar object 905 containing a single valid VTIMEZONE component. 907 5.3. Creating Resources 909 The creation of calendar collections and calendar object resources 910 may be initiated by either a CalDAV client or by the CalDAV server. 911 For example, a server might come pre-configured with a user's 912 calendar collection, or the CalDAV client might request the server to 913 create a new calendar collection for a given user. Servers might 914 populate events as calendar objects inside a calendar collection, or 915 clients might request the server to create events. Either way, both 916 client and server MUST comply with the requirements in this document, 917 and MUST understand objects appearing in calendar collections or 918 according to the data model defined here. 920 5.3.1. MKCALENDAR Method 922 An HTTP request using the MKCALENDAR method creates a new calendar 923 collection resource. A server MAY restrict calendar collection 924 creation to particular collections. 926 Support for MKCALENDAR on the server is only RECOMMENDED and not 927 REQUIRED because some calendar stores only support one calendar per 928 user (or principal) and those are typically pre-created for each 929 account. However, servers and clients are strongly encouraged to 930 support MKCALENDAR whenever possible to allow users to create 931 multiple calendar collections to better help organize their data. 933 Clients SHOULD use the DAV:displayname property for a human-readable 934 name of the calendar. Clients can either specify the value of the 935 DAV:displayname property in the request body of the MKCALENDAR 936 request, or alternatively issue a PROPPATCH request to change the 937 DAV:displayname property to the appropriate value immediately after 938 issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: 939 displayname property to be the same as any other calendar collection 940 at the same URI "level". When displaying calendar collections to 941 users, clients SHOULD check the DAV:displayname property and use that 942 value as the name of the calendar. In the event that the DAV: 943 displayname property is empty, the client MAY use the last part of 944 the calendar collection URI as the name, however that path segment 945 may be "opaque" and not represent any meaningful human-readable text. 947 If a MKCALENDAR request fails, the server state preceding the request 948 MUST be restored. 950 Marshalling: 952 If a request body is included, it MUST be a CALDAV:mkcalendar XML 953 element. Instruction processing MUST occur in the order 954 instructions are received (i.e., from top to bottom). 955 Instructions MUST either all be executed or none executed. Thus 956 if any error occurs during processing, all executed instructions 957 MUST be undone and a proper error result returned. Instruction 958 processing details can be found in the definition of the DAV:set 959 instruction in Section 12.13.2 of [RFC2518]. 961 963 If a response body for a successful request is included, it MUST 964 be a CALDAV:mkcalendar-response XML element. 966 968 The response MUST include a Cache-Control:no-cache header. 970 Preconditions: 972 (DAV:resource-must-be-null): A resource MUST NOT exist at the 973 Request-URI; 975 (CALDAV:calendar-collection-location-ok): The Request-URI MUST 976 identify a location where a calendar collection can be created; 978 (CALDAV:valid-calendar-data): The time zone specified in the 979 CALDAV:calendar-timezone property MUST be a valid iCalendar object 980 containing a single valid VTIMEZONE component; 982 (DAV:needs-privilege): The DAV:bind privilege MUST be granted to 983 the current user on the parent collection of the Request-URI. 985 Postconditions: 987 (CALDAV:initialize-calendar-collection): A new calendar collection 988 exists at the Request-URI. The DAV:resourcetype of the calendar 989 collection MUST contain both DAV:collection and CALDAV:calendar 990 XML elements. 992 5.3.1.1. Status Codes 994 The following are examples of response codes one would expect to get 995 in a response to a MKCALENDAR request. Note that this list is by no 996 means exhaustive. 998 201 (Created) - The calendar collection resource was created in 999 its entirety; 1001 207 (Multi-Status) - The calendar collection resource was not 1002 created since one or more DAV:set instructions specified in the 1003 request body could not be processed successfully. The following 1004 are examples of response codes one would expect to be used in a 1005 207 (Multi-Status) response in this situation: 1007 403 (Forbidden) - The client, for reasons the server chooses 1008 not to specify, cannot alter one of the properties; 1010 409 (Conflict) - The client has provided a value whose 1011 semantics are not appropriate for the property. This includes 1012 trying to set read-only properties; 1014 424 (Failed Dependency) - The DAV:set instruction on the 1015 specified resource would have succeeded if it were not for the 1016 failure of another DAV:set instruction specified in the request 1017 body; 1018 423 (Locked) - The specified resource is locked and the client 1019 either is not a lock owner or the lock type requires a lock 1020 token to be submitted and the client did not submit it; and 1022 507 (Insufficient Storage) - The server did not have sufficient 1023 space to record the property; 1025 403 (Forbidden) - This indicates at least one of two conditions: 1026 1) the server does not allow the creation of calendar collections 1027 at the given location in its namespace, or 2) the parent 1028 collection of the Request-URI exists but cannot accept members; 1030 409 (Conflict) - A collection cannot be made at the Request-URI 1031 until one or more intermediate collections have been created; 1033 415 (Unsupported Media Type) - The server does not support the 1034 request type of the body; and 1036 507 (Insufficient Storage) - The resource does not have sufficient 1037 space to record the state of the resource after the execution of 1038 this method. 1040 5.3.1.2. Example: Successful MKCALENDAR request 1042 This example creates a calendar collection called /home/lisa/ 1043 calendars/events/ on the server cal.example.com with specific values 1044 for the properties DAV:displayname, CALDAV:calendar-description, 1045 CALDAV:supported-calendar-component-set, and CALDAV:calendar- 1046 timezone. 1048 >> Request << 1050 MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1 1051 Host: cal.example.com 1052 Content-Type: application/xml; charset="utf-8" 1053 Content-Length: xxxx 1055 1056 1058 1059 1060 Lisa's Events 1061 Calendar restricted to events. 1063 1064 1065 1066 1089 1090 1091 1092 >> Response << 1094 HTTP/1.1 201 Created 1095 Cache-Control: no-cache 1096 Date: Fri, 11 Nov 2005 09:32:12 GMT 1097 Content-Length: 0 1099 5.3.2. Creating Calendar Object Resources 1101 Clients populate calendar collections with calendar object resources. 1102 The URL for each calendar object resource is entirely arbitrary, and 1103 does not need to bear a specific relationship to the calendar object 1104 resource's iCalendar properties or other metadata. New calendar 1105 object resources MUST be created with a PUT request targeted at an 1106 unmapped URI. A PUT request targeted at a mapped URI updates an 1107 existing calendar object resource. 1109 When servers create new resources, it's not hard for the server to 1110 choose an unmapped URI. It's slightly tougher for clients, because a 1111 client might not want to examine all resources in the collection, and 1112 might not want to lock the entire collection to ensure that a new 1113 resource isn't created with a name collision. However, there is an 1114 HTTP feature to mitigate this. If the client intends to create a new 1115 non-collection resource, such as a new VEVENT, the client SHOULD use 1116 the HTTP request header "If-None-Match: *" on the PUT request. The 1117 Request-URI on the PUT request MUST include the target collection, 1118 where the resource is to be created, plus the name of the resource in 1119 the last path segment. The "If-None-Match: *" request header ensures 1120 that the client will not inadvertently overwrite an existing 1121 resource, if the last path segment turned out to already be used. 1123 >> Request << 1125 PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1 1126 If-None-Match: * 1127 Host: cal.example.com 1128 Content-Type: text/calendar 1129 Content-Length: xxxx 1131 BEGIN:VCALENDAR 1132 VERSION:2.0 1133 PRODID:-//Example Corp.//CalDAV Client//EN 1134 BEGIN:VEVENT 1135 UID:20010712T182145Z-123401@example.com 1136 DTSTAMP:20060712T182145Z 1137 DTSTART:20060714T170000Z 1138 DTEND:20060715T040000Z 1139 SUMMARY:Bastille Day Party 1140 END:VEVENT 1141 END:VCALENDAR 1143 >> Response << 1145 HTTP/1.1 201 Created 1146 Content-Length: 0 1147 Date: Fri, 11 Nov 2005 09:32:12 GMT 1148 ETag: "123456789-000-111" 1150 The request to change an existing event is the same, but with a 1151 specific ETag in the "If-Match" header, rather than the "If-None- 1152 Match" header. 1154 As indicated in Section 3.10 of [RFC2445], the URL of calendar object 1155 resources containing (an arbitrary set of) calendaring and scheduling 1156 information may be suffixed by ".ics", and the URL of calendar object 1157 resources containing free or busy time information may be suffixed by 1158 ".ifb". 1160 5.3.2.1. Additional Preconditions for PUT, COPY and MOVE 1162 This specification creates additional Preconditions for PUT, COPY and 1163 MOVE methods. These preconditions apply: 1165 When a PUT operation of a calendar object resource into a calendar 1166 collection occurs. 1168 When a COPY or MOVE operation of a calendar object resource into a 1169 calendar collection occurs. 1171 The new preconditions are: 1173 (CALDAV:supported-calendar-data): The resource submitted in the 1174 PUT request, or targeted by a COPY or MOVE request MUST be a 1175 supported media type (i.e., iCalendar) for calendar object 1176 resources; 1178 (CALDAV:valid-calendar-data): The resource submitted in the PUT 1179 request, or targeted by a COPY or MOVE request MUST be valid data 1180 for the media type being specified (i.e., MUST contain valid 1181 iCalendar data); 1183 (CALDAV:valid-calendar-object-resource): The resource submitted in 1184 the PUT request, or targeted by a COPY or MOVE request MUST obey 1185 all restrictions specified in Section 4.1 (e.g., calendar object 1186 resources MUST NOT contain more than one type of calendar 1187 component, calendar object resources MUST NOT specify the 1188 iCalendar METHOD property, etc.); 1190 (CALDAV:supported-calendar-component): The resource submitted in 1191 the PUT request, or targeted by a COPY or MOVE request MUST 1192 contain a type of calendar component that is supported in the 1193 targeted calendar collection; 1195 (CALDAV:no-uid-conflict): The resource submitted in the PUT 1196 request, or targeted by a COPY or MOVE request MUST NOT specify an 1197 iCalendar UID property value already in use in the targeted 1198 calendar collection or overwrite an existing calendar object 1199 resource with one that has a different UID property value. 1200 Servers SHOULD report the URL of the resource that is already 1201 making use of the same UID property value in the DAV:href element; 1203 1205 (CALDAV:calendar-collection-location-ok): In a COPY or MOVE 1206 request, when the Request-URI is a calendar collection, the 1207 Destination-URI MUST identify a location where a calendar 1208 collection can be created; 1210 (CALDAV:max-resource-size): The resource submitted in the PUT 1211 request, or targeted by a COPY or MOVE request MUST have an octet 1212 size less than or equal to the value of the CALDAV:max-resource- 1213 size property value (Section 5.2.5) on the calendar collection 1214 where the resource will be stored; 1216 (CALDAV:min-date-time): The resource submitted in the PUT request, 1217 or targeted by a COPY or MOVE request MUST have all of its 1218 iCalendar date or time property values (for each recurring 1219 instance) greater than or equal to the value of the CALDAV:min- 1220 date-time property value (Section 5.2.6) on the calendar 1221 collection where the resource will be stored; 1223 (CALDAV:max-date-time): The resource submitted in the PUT request, 1224 or targeted by a COPY or MOVE request MUST have all of its 1225 iCalendar date or time property values (for each recurring 1226 instance) less than the value of the CALDAV:max-date-time property 1227 value (Section 5.2.7) on the calendar collection where the 1228 resource will be stored; 1230 (CALDAV:max-instances): The resource submitted in the PUT request, 1231 or targeted by a COPY or MOVE request MUST generate a number of 1232 recurring instances less than or equal to the value of the CALDAV: 1233 max-instances property value (Section 5.2.8) on the calendar 1234 collection where the resource will be stored; 1236 (CALDAV:max-attendees-per-instance): The resource submitted in the 1237 PUT request, or targeted by a COPY or MOVE request MUST have a 1238 number of ATTENDEE properties on any one instance less than or 1239 equal to the value of the CALDAV:max-attendees-per-instance 1240 property value (Section 5.2.9) on the calendar collection where 1241 the resource will be stored; 1243 5.3.3. Non-standard components, properties and parameters 1245 iCalendar provides a "standard mechanism for doing non-standard 1246 things". This extension support allows implementers to make use of 1247 non-standard components, properties and parameters whose names are 1248 prefixed with the text "X-". 1250 Servers MUST support the use of non-standard components, properties 1251 and parameters in calendar object resources stored via the PUT 1252 method. 1254 Servers may need to enforce rules for their own "private" components, 1255 properties or parameters, so servers MAY reject any attempt by the 1256 client to change those or use values for those outside of any 1257 restrictions the server may have. Servers SHOULD ensure that any 1258 "private" components, properties or parameters it uses follow the 1259 convention of including a vendor id in the "X-" name as described in 1260 Section 4.2 of [RFC2445], e.g., "X-ABC-Private". 1262 5.3.4. Calendar Object Resource Entity Tag 1264 The DAV:getetag property MUST be defined and set to a strong entity 1265 tag on all calendar object resources. 1267 A response to a GET request targeted at a calendar object resource 1268 MUST contain an ETag response header field indicating the current 1269 value of the strong entity tag of the calendar object resource. 1271 Servers SHOULD return a strong entity tag (ETag header) in a PUT 1272 response when the stored calendar object resource is equivalent by 1273 octet equality to the calendar object resource submitted in the body 1274 of the PUT request. This allows clients to reliably use the returned 1275 strong entity tag for data synchronization purposes. For instance, 1276 the client can do a PROPFIND request on the stored calendar object 1277 resource and have the DAV:getetag property returned, and compare that 1278 value with the strong entity tag it received on the PUT response, and 1279 know that if they are equal, then the calendar object resource on the 1280 server has not been changed. 1282 In the case where the data stored by a server as a result of a PUT 1283 request is not equivalent by octet equality to the submitted calendar 1284 object resource, the behavior of the ETag response header is not 1285 specified here, with the exception that a strong entity tag MUST NOT 1286 be returned in the response. As a result, clients may need to 1287 retrieve the modified calendar object resource (and ETag) as a basis 1288 for further changes, rather than use the calendar object resource it 1289 had sent with the PUT request. 1291 6. Calendaring Access Control 1293 6.1. Calendaring Privilege 1295 CalDAV servers MUST support and adhere to the requirements of WebDAV 1296 ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set 1297 of privileges that can be applied to WebDAV collections and ordinary 1298 resources. CalDAV servers MUST also support the calendaring 1299 privilege defined in this section. 1301 6.1.1. CALDAV:read-free-busy Privilege 1303 Calendar users often wish to allow other users to see their busy time 1304 information, without viewing the other details of the calendar 1305 components (e.g., location, summary, attendees). This allows a 1306 significant amount of privacy while still allowing other users to 1307 schedule meetings at times when the user is likely to be free. 1309 The CALDAV:read-free-busy privilege controls which calendar 1310 collections, regular collections and calendar object resources are 1311 examined when a CALDAV:free-busy-query REPORT request is processed 1312 (see Section 7.10). This privilege can be granted on calendar 1313 collections, regular collections or calendar object resources. 1315 Servers MUST support this privilege on all calendar collections, 1316 regular collections and calendar object resources. 1318 1320 The CALDAV:read-free-busy privilege MUST be aggregated in the DAV: 1321 read privilege. Servers MUST allow the CALDAV:read-free-busy to be 1322 granted without the DAV:read privilege being granted. 1324 Clients should note that when only the CALDAV:read-free-busy 1325 privilege has been granted on a resource, this does not imply access 1326 to GET, HEAD, OPTIONS and PROPFIND on the resource -- those 1327 operations are governed by the DAV:read privilege. 1329 6.2. Additional Principal Property 1331 This section defines an additional property for WebDAV principal 1332 resources as defined in [RFC3744]. 1334 6.2.1. CALDAV:calendar-home-set Property 1336 Name: calendar-home-set 1338 Namespace: urn:ietf:params:xml:ns:caldav 1340 Purpose: Identifies the URL of any WebDAV collections that contain 1341 calendar collections owned by the associated principal resource. 1343 Conformance: This property SHOULD be defined on a principal resource. 1344 If defined, it MAY be protected and SHOULD NOT be returned by a 1345 PROPFIND DAV:allprop request (as defined in Section 12.14.1 of 1346 [RFC2518]). 1348 Description: The CALDAV:calendar-home-set property is meant to allow 1349 users to easily find the calendar collections owned by the 1350 principal. Typically, users will group all the calendar 1351 collections that they own under a common collection. This 1352 property specifies the URL of collections that either are calendar 1353 collections or ordinary collections that have child or descendant 1354 calendar collections owned by the principal. 1356 Definition: 1358 1360 Example: 1362 1364 http://cal.example.com/home/bernard/calendars/ 1365 1367 7. Calendaring Reports 1369 This section defines the REPORTs that CalDAV servers MUST support on 1370 calendar collections and calendar object resources. 1372 CalDAV servers MUST advertise support for these REPORTs on all 1373 calendar collections and calendar object resources with the DAV: 1374 supported-report-set property defined in Section 3.1.5 of [RFC3253]. 1375 CalDAV servers MAY also advertise support for these REPORTs on 1376 ordinary collections. 1378 Some of these REPORTs allow calendar data (from possibly multiple 1379 resources) to be returned. 1381 7.1. REPORT Method 1383 The REPORT method (defined in Section 3.6 of [RFC3253]) provides an 1384 extensible mechanism for obtaining information about one or more 1385 resources. Unlike the PROPFIND method, which returns the value of 1386 one or more named properties, the REPORT method can involve more 1387 complex processing. REPORT is valuable in cases where the server has 1388 access to all of the information needed to perform the complex 1389 request (such as a query), and where it would require multiple 1390 requests for the client to retrieve the information needed to perform 1391 the same request. 1393 CalDAV servers MUST support the DAV:expand-property REPORT defined in 1394 Section 3.8 of [RFC3253]. 1396 7.2. Ordinary collections 1398 Servers MAY support the REPORTs defined in this document on ordinary 1399 collections (collections that are not calendar collections) in 1400 addition to calendar collections or calendar object resources. In 1401 computing responses to the REPORTs on ordinary collections, servers 1402 MUST only consider calendar object resources contained in calendar 1403 collections that are targeted by the REPORT based on the value of the 1404 Depth request header. 1406 7.3. Date and floating time 1408 iCalendar provides a way to specify DATE and DATE-TIME values that 1409 are not bound to any time zone in particular, hereafter called 1410 "floating date" and "floating time" respectively. These values are 1411 used to represent the same day, hour, minute and second value 1412 regardless of which time zone is being observed. For instance, the 1413 DATE value "20051111", represents November 11th, 2005 in no specific 1414 time zone, while the DATE-TIME value "20051111T111100" represents 1415 November 11th, 2005 at 11:11 AM in no specific time zone. 1417 CalDAV servers may need to convert "floating date" and "floating 1418 time" values in date with UTC time values in the processing of 1419 calendaring REPORT requests. 1421 For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the 1422 value of the CALDAV:timezone XML element, if specified as part of the 1423 request body, to perform the proper conversion of "floating date" and 1424 "floating time" values to date with UTC time values. If the CALDAV: 1425 timezone XML element is not specified in the request body, CalDAV 1426 servers MUST rely on the value of the CALDAV:calendar-timezone 1427 property, if defined, else the CalDAV servers MAY rely on the time 1428 zone of their choice. 1430 For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on 1431 the value of the CALDAV:calendar-timezone property, if defined, to 1432 compute the proper FREEBUSY time period value as date with UTC time, 1433 for calendar components scheduled with "floating date" or "floating 1434 time". If the CALDAV:calendar-timezone property is not defined, 1435 CalDAV servers MAY rely on the time zone of their choice. 1437 7.4. Time range filtering 1439 Some of the reports defined in this section can include a time range 1440 filter that is used to restrict the set of calendar object resources 1441 returned to just those that overlap the specified time range. The 1442 time range filter can be applied to a calendar component as a whole, 1443 or to specific calendar component properties with date or date-time 1444 value types. 1446 To determine whether a calendar object resource matches the time 1447 range filter element, the start and end times for the targeted 1448 component or property are determined and then compared to the 1449 requested time range. If there is an overlap with the requested time 1450 range, then the calendar object resource matches the filter element. 1451 The rules defined in [RFC2445] for determining the actual start and 1452 end times of calendar components MUST be used, and these are fully 1453 enumerated in Section 9.9 of this document. 1455 When such time range filtering is used, special consideration must be 1456 given to recurring calendar components such as VEVENT and VTODO 1457 components. The server MUST expand recurring components to determine 1458 whether any recurrence instances overlap the specified time range. 1459 If one or more recurrence instances overlap the time range, then the 1460 calendar object resource matches the filter element. 1462 7.5. Searching Text: Collations 1464 Some of the reports defined in this section do text matches of 1465 character strings provided by the client and compared to stored 1466 calendar data. Since iCalendar data is by default encoded in the 1467 UTF-8 charset and may include characters outside of the US-ASCII 1468 charset range in some property and parameter values, there is a need 1469 to ensure that text matching follows well-defined rules. 1471 To deal with this, this specification makes use of the IANA Collation 1472 Registry defined in [I-D.newman-i18n-comparator] to specify 1473 collations that may be used to carry out the text comparison 1474 operations with a well-defined rule. 1476 The comparisons used in CalDAV are all "substring" matches as per 1477 [I-D.newman-i18n-comparator] Section 4.2. Collations supported by 1478 the server MUST support "substring" match operations. 1480 CalDAV servers are REQUIRED to support the "i;ascii-casemap" and 1481 "i;octet" collations as described in [I-D.newman-i18n-comparator], 1482 and MAY support other collations. 1484 Servers MUST advertise the set of collations that they support via 1485 the CALDAV:supported-collation-set property defined on any resource 1486 that supports reports that use collations. 1488 Clients MUST only use collations from the list advertised by the 1489 server. 1491 In the absence of a collation explicitly specified by the client, or 1492 if the client specifies the "default" collation identifier (as 1493 defined in [I-D.newman-i18n-comparator] Section 3.1), the server MUST 1494 default to using "i;ascii-casemap" as the collation. 1496 Wildcards (as defined in [I-D.newman-i18n-comparator] Section 3.2) 1497 MUST NOT be used in the collation identifier. 1499 If the client chooses a collation not supported by the server, the 1500 server MUST respond with a CALDAV:supported-collation precondition 1501 error response. 1503 7.5.1. CALDAV:supported-collation-set Property 1505 Name: supported-collation-set 1507 Namespace: urn:ietf:params:xml:ns:caldav 1509 Purpose: Identifies the set of collations supported by the server for 1510 text matching operations. 1512 Conformance: This property MUST be defined on any resource that 1513 supports a REPORT that does text matching. If defined, it MUST be 1514 protected and SHOULD NOT be returned by a PROPFIND DAV:allprop 1515 request (as defined in Section 12.14.1 of [RFC2518]). 1517 Description: The CALDAV:supported-collation-set property contains 1518 zero or more CALDAV:supported-collation elements which specify the 1519 collection identifiers of the collations supported by the server. 1521 Definition: 1523 1524 1526 Example: 1528 1530 i;ascii-casemap 1531 i;octet 1532 1534 7.6. Partial Retrieval 1536 Some calendaring REPORTs defined in this document allow partial 1537 retrieval of calendar object resources. A CalDAV client can specify 1538 what information to return in the body of a calendaring REPORT 1539 request. 1541 A CalDAV client can request particular WebDAV property values, all 1542 WebDAV property values, or a list of the names of the resource's 1543 WebDAV properties. A CalDAV client can also request calendar data to 1544 be returned and whether all calendar components and properties should 1545 be returned or only particular ones. See CALDAV:calendar-data in 1546 Section 9.6. 1548 By default, the returned calendar data will include the component 1549 that defines the recurrence set, referred to as the "master 1550 component", as well as the components that define exceptions to the 1551 recurrence set, referred to as the "overridden components". 1553 A CalDAV client only interested in the recurrence instances that 1554 overlap a specified time range can request to receive only the 1555 "master component" along with the "overridden components" that impact 1556 the specified time range and thus limit the data returned by the 1557 server. See CALDAV:limit-recurrence-set in Section 9.6.6. An 1558 overridden component impacts a time range if its current start and 1559 end times overlap the time range, or if the original start and end 1560 times - the ones that would have been used if the instance were not 1561 overridden - overlap the time range. 1563 A CalDAV client with no support for recurrence properties (i.e., 1564 EXDATE, EXRULE, RDATE and RRULE) and possibly VTIMEZONE components, 1565 or a client not willing to perform recurrence expansion because of 1566 limited processing capability can request to receive only the 1567 recurrence instances that overlap a specified time range as separate 1568 calendar components that each define exactly one recurrence instance. 1569 See CALDAV:expand in Section 9.6.5. 1571 Finally, in the case of VFREEBUSY components, a CalDAV client can 1572 request to receive only the FREEBUSY property values that overlap a 1573 specified time range. See CALDAV:limit-freebusy-set in 1574 Section 9.6.7. 1576 7.7. Non-standard components, properties and parameters 1578 Servers MUST support the use of non-standard component, property or 1579 parameter names in the CALDAV:calendar-data XML element in 1580 calendaring REPORT requests to allow clients to request that non- 1581 standard components, properties and parameters be returned in the 1582 calendar data provided in the response. 1584 Servers MAY support the use of non-standard component, property or 1585 parameter names in the CALDAV:comp-filter, CALDAV:prop-filter and 1586 CALDAV:param-filter XML elements specified in the CALDAV:filter XML 1587 element of calendaring REPORT requests. 1589 Servers MUST fail with the CALDAV:supported-filter precondition if a 1590 calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop- 1591 filter or CALDAV:param-filter XML element that makes reference to a 1592 non-standard component, property or parameter name which the server 1593 does not support queries on. 1595 7.8. CALDAV:calendar-query Report 1597 The CALDAV:calendar-query REPORT performs a search for all calendar 1598 object resources that match a specified filter. The response of this 1599 REPORT will contain all the WebDAV properties and calendar object 1600 resource data specified in the request. In the case of the CALDAV: 1601 calendar-data XML element, one can explicitly specify the calendar 1602 components and properties that should be returned in the calendar 1603 object resource data that matches the filter. 1605 The format of this REPORT is modeled on the PROPFIND method. The 1606 request and response bodies of the CALDAV:calendar-query REPORT use 1607 XML elements that are also used by PROPFIND. In particular the 1608 request can include XML elements to request WebDAV properties to be 1609 returned. When that occurs the response should follow the same 1610 behavior as PROPFIND with respect to the DAV:multistatus response 1611 elements used to return specific property results. For instance, a 1612 request to retrieve the value of a property which does not exist is 1613 an error and MUST be noted with a response XML element which contains 1614 a 404 (Not Found) status value. 1616 Support for the CALDAV:calendar-query REPORT is REQUIRED. 1618 Marshalling: 1620 The request body MUST be a CALDAV:calendar-query XML element as 1621 defined in Section 9.5. 1623 The request MAY include a Depth header. If no Depth header is 1624 included, Depth:0 is assumed. 1626 The response body for a successful request MUST be a DAV: 1627 multistatus XML element (i.e., the response uses the same format 1628 as the response for PROPFIND). In the case where there are no 1629 response elements, the returned DAV:multistatus XML element is 1630 empty. 1632 The response body for a successful CALDAV:calendar-query REPORT 1633 request MUST contain a DAV:response element for each iCalendar 1634 object that matched the search filter. Calendar data is being 1635 returned in the CALDAV:calendar-data XML element inside the DAV: 1636 propstat XML element. 1638 Preconditions: 1640 (CALDAV:supported-calendar-data): The attributes "content-type" 1641 and "version" of the CALDAV:calendar-data XML element (see 1642 Section 9.6) specify a media type supported by the server for 1643 calendar object resources. 1645 (CALDAV:valid-filter): The CALDAV:filter XML element (see 1646 Section 9.7) specified in the REPORT request MUST be valid. For 1647 instance, a CALDAV:filter cannot nest a 1648 element in a element, or a CALDAV:filter 1649 cannot nest a element in a 1650 element. 1652 (CALDAV:supported-filter): The CALDAV:comp-filter (see 1653 Section 9.7.1), CALDAV:prop-filter (see Section 9.7.2) and CALDAV: 1654 param-filter (see Section 9.7.3) XML elements used in the CALDAV: 1655 filter XML element (see Section 9.7) in the REPORT request only 1656 make reference to components, properties and parameters for which 1657 queries are supported by the server. i.e., if the CALDAV:filter 1658 element attempts to reference an unsupported component, property 1659 or parameter, this precondition is violated. Servers SHOULD 1660 report the CALDAV:comp-filter, CALDAV:prop-filter or CALDAV:param- 1661 filter for which it does not provide support. 1663 1667 (CALDAV:valid-calendar-data): The time zone specified in the 1668 REPORT request MUST be a valid iCalendar object containing a 1669 single valid VTIMEZONE component. 1671 (CALDAV:min-date-time): Any XML element specifying a range of time 1672 MUST have its start or end date or time values greater than or 1673 equal to the value of the CALDAV:min-date-time property value 1674 (Section 5.2.6) on the calendar collections being targeted by the 1675 REPORT; 1677 (CALDAV:max-date-time): Any XML element specifying a range of time 1678 MUST have its start or end date or time values less than or equal 1679 to the value of the CALDAV:max-date-time property value 1680 (Section 5.2.7) on the calendar collections being targeted by the 1681 REPORT; 1683 (CALDAV:supported-collation): Any XML attribute specifying a 1684 collation MUST specify a collation supported by the server as 1685 described in Section 7.5. 1687 Postconditions: 1689 (DAV:number-of-matches-within-limits): The number of matching 1690 calendar object resources must fall within server-specific, 1691 predefined limits. For example, this condition might be triggered 1692 if a search specification would cause the return of an extremely 1693 large number of responses. 1695 7.8.1. Example: Partial retrieval of events by time range 1697 In this example, the client requests the server to return specific 1698 components and properties of the VEVENT components that overlap the 1699 time range from January 4th, 2006 at 00:00:00 AM UTC to January 5th, 1700 2006 at 00:00:00 AM UTC. In addition the DAV:getetag property is 1701 also requested and returned as part of the response. Note that the 1702 first calendar object returned is a recurring event whose first 1703 instance lies outside of the requested time range, but whose third 1704 instance does overlap the time range. Note that due to the CALDAV: 1705 calendar-data element restrictions, the DTSTAMP property in VEVENT 1706 components has not been returned, and the only property returned in 1707 the VCALENDAR object is VERSION. 1709 See Appendix B for the calendar data being targeted by this example. 1711 >> Request << 1713 REPORT /bernard/work/ HTTP/1.1 1714 Host: cal.example.com 1715 Depth: 1 1716 Content-Type: application/xml; charset="utf-8" 1717 Content-Length: xxxx 1719 1720 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1748 1749 1750 1751 1753 >> Response << 1755 HTTP/1.1 207 Multi-Status 1756 Date: Fri, 11 Nov 2005 09:32:12 GMT 1757 Content-Type: application/xml; charset="utf-8" 1758 Content-Length: xxxx 1759 1760 1762 1763 http://cal.example.com/bernard/work/abcd2.ics 1764 1765 1766 "fffff-abcd2" 1767 BEGIN:VCALENDAR 1768 VERSION:2.0 1769 BEGIN:VTIMEZONE 1770 LAST-MODIFIED:20040110T032845Z 1771 TZID:US/Eastern 1772 BEGIN:DAYLIGHT 1773 DTSTART:20000404T020000 1774 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1775 TZNAME:EDT 1776 TZOFFSETFROM:-0500 1777 TZOFFSETTO:-0400 1778 END:DAYLIGHT 1779 BEGIN:STANDARD 1780 DTSTART:20001026T020000 1781 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1782 TZNAME:EST 1783 TZOFFSETFROM:-0400 1784 TZOFFSETTO:-0500 1785 END:STANDARD 1786 END:VTIMEZONE 1787 BEGIN:VEVENT 1788 DTSTART;TZID=US/Eastern:20060102T120000 1789 DURATION:PT1H 1790 RRULE:FREQ=DAILY;COUNT=5 1791 SUMMARY:Event #2 1792 UID:00959BC664CA650E933C892C@example.com 1793 END:VEVENT 1794 BEGIN:VEVENT 1795 DTSTART;TZID=US/Eastern:20060104T140000 1796 DURATION:PT1H 1797 RECURRENCE-ID;TZID=US/Eastern:20060104T120000 1798 SUMMARY:Event #2 bis 1799 UID:00959BC664CA650E933C892C@example.com 1800 END:VEVENT 1801 BEGIN:VEVENT 1802 DTSTART;TZID=US/Eastern:20060106T140000 1803 DURATION:PT1H 1804 RECURRENCE-ID;TZID=US/Eastern:20060106T120000 1805 SUMMARY:Event #2 bis bis 1806 UID:00959BC664CA650E933C892C@example.com 1807 END:VEVENT 1808 END:VCALENDAR 1809 1810 1811 HTTP/1.1 200 OK 1812 1813 1814 1815 http://cal.example.com/bernard/work/abcd3.ics 1816 1817 1818 "fffff-abcd3" 1819 BEGIN:VCALENDAR 1820 VERSION:2.0 1821 PRODID:-//Example Corp.//CalDAV Client//EN 1822 BEGIN:VTIMEZONE 1823 LAST-MODIFIED:20040110T032845Z 1824 TZID:US/Eastern 1825 BEGIN:DAYLIGHT 1826 DTSTART:20000404T020000 1827 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1828 TZNAME:EDT 1829 TZOFFSETFROM:-0500 1830 TZOFFSETTO:-0400 1831 END:DAYLIGHT 1832 BEGIN:STANDARD 1833 DTSTART:20001026T020000 1834 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1835 TZNAME:EST 1836 TZOFFSETFROM:-0400 1837 TZOFFSETTO:-0500 1838 END:STANDARD 1839 END:VTIMEZONE 1840 BEGIN:VEVENT 1841 DTSTART;TZID=US/Eastern:20060104T100000 1842 DURATION:PT1H 1843 SUMMARY:Event #3 1844 UID:DC6C50A017428C5216A2F1CD@example.com 1845 END:VEVENT 1846 END:VCALENDAR 1847 1848 1849 HTTP/1.1 200 OK 1850 1851 1852 1854 7.8.2. Example: Partial retrieval of recurring events 1856 In this example, the client requests the server to return VEVENT 1857 components that overlap the time range from January 3rd, 2006 at 00: 1858 00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC. Use of the 1859 CALDAV:limit-recurrence-set element causes the server to only return 1860 overridden recurrence components that overlap the time range 1861 specified in that element, or that affect other instances that 1862 overlap the time range (e.g., in the case of a "THISANDFUTURE" 1863 behavior). In this example the first overridden component in the 1864 matching resource is returned but the second one is not. 1866 See Appendix B for the calendar data being targeted by this example. 1868 >> Request << 1870 REPORT /bernard/work/ HTTP/1.1 1871 Host: cal.example.com 1872 Depth: 1 1873 Content-Type: application/xml; charset="utf-8" 1874 Content-Length: xxxx 1876 1877 1879 1880 1881 1883 1884 1885 1886 1887 1888 1890 1891 1892 1893 1895 >> Response << 1897 HTTP/1.1 207 Multi-Status 1898 Date: Fri, 11 Nov 2006 09:32:12 GMT 1899 Content-Type: application/xml; charset="utf-8" 1900 Content-Length: xxxx 1901 1902 1904 1905 http://cal.example.com/bernard/work/abcd2.ics 1906 1907 1908 "fffff-abcd2" 1909 BEGIN:VCALENDAR 1910 VERSION:2.0 1911 PRODID:-//Example Corp.//CalDAV Client//EN 1912 BEGIN:VTIMEZONE 1913 LAST-MODIFIED:20040110T032845Z 1914 TZID:US/Eastern 1915 BEGIN:DAYLIGHT 1916 DTSTART:20000404T020000 1917 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1918 TZNAME:EDT 1919 TZOFFSETFROM:-0500 1920 TZOFFSETTO:-0400 1921 END:DAYLIGHT 1922 BEGIN:STANDARD 1923 DTSTART:20001026T020000 1924 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1925 TZNAME:EST 1926 TZOFFSETFROM:-0400 1927 TZOFFSETTO:-0500 1928 END:STANDARD 1929 END:VTIMEZONE 1930 BEGIN:VEVENT 1931 DTSTAMP:20060206T001121Z 1932 DTSTART;TZID=US/Eastern:20060102T120000 1933 DURATION:PT1H 1934 RRULE:FREQ=DAILY;COUNT=5 1935 SUMMARY:Event #2 1936 UID:00959BC664CA650E933C892C@example.com 1937 END:VEVENT 1938 BEGIN:VEVENT 1939 DTSTAMP:20060206T001121Z 1940 DTSTART;TZID=US/Eastern:20060104T140000 1941 DURATION:PT1H 1942 RECURRENCE-ID;TZID=US/Eastern:20060104T120000 1943 SUMMARY:Event #2 bis 1944 UID:00959BC664CA650E933C892C@example.com 1945 END:VEVENT 1946 END:VCALENDAR 1947 1948 1949 HTTP/1.1 200 OK 1950 1951 1952 1953 http://cal.example.com/bernard/work/abcd3.ics 1954 1955 1956 "fffff-abcd3" 1957 BEGIN:VCALENDAR 1958 VERSION:2.0 1959 PRODID:-//Example Corp.//CalDAV Client//EN 1960 BEGIN:VTIMEZONE 1961 LAST-MODIFIED:20040110T032845Z 1962 TZID:US/Eastern 1963 BEGIN:DAYLIGHT 1964 DTSTART:20000404T020000 1965 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 1966 TZNAME:EDT 1967 TZOFFSETFROM:-0500 1968 TZOFFSETTO:-0400 1969 END:DAYLIGHT 1970 BEGIN:STANDARD 1971 DTSTART:20001026T020000 1972 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 1973 TZNAME:EST 1974 TZOFFSETFROM:-0400 1975 TZOFFSETTO:-0500 1976 END:STANDARD 1977 END:VTIMEZONE 1978 BEGIN:VEVENT 1979 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 1980 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 1981 DTSTAMP:20060206T001220Z 1982 DTSTART;TZID=US/Eastern:20060104T100000 1983 DURATION:PT1H 1984 LAST-MODIFIED:20060206T001330Z 1985 ORGANIZER:mailto:cyrus@example.com 1986 SEQUENCE:1 1987 STATUS:TENTATIVE 1988 SUMMARY:Event #3 1989 UID:DC6C50A017428C5216A2F1CD@example.com 1990 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com 1991 END:VEVENT 1992 END:VCALENDAR 1993 1994 1995 HTTP/1.1 200 OK 1996 1998 1999 2001 7.8.3. Example: Expanded retrieval of recurring events 2003 In this example, the client requests the server to return VEVENT 2004 components that overlap the time range from January 2nd, 2006 at 00: 2005 00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC and to return 2006 recurring calendar components expanded into individual recurrence 2007 instance calendar components. Use of the CALDAV:expand element 2008 causes the server to only return overridden recurrence instances that 2009 overlap the time range specified in that element. 2011 See Appendix B for the calendar data being targeted by this example. 2013 >> Request << 2015 REPORT /bernard/work/ HTTP/1.1 2016 Host: cal.example.com 2017 Depth: 1 2018 Content-Type: application/xml; charset="utf-8" 2019 Content-Length: xxxx 2021 2022 2024 2025 2026 2028 2029 2030 2031 2032 2033 2035 2036 2037 2038 2040 >> Response << 2042 HTTP/1.1 207 Multi-Status 2043 Date: Fri, 11 Nov 2006 09:32:12 GMT 2044 Content-Type: application/xml; charset="utf-8" 2045 Content-Length: xxxx 2046 2047 2049 2050 http://cal.example.com/bernard/work/abcd2.ics 2051 2052 2053 "fffff-abcd2" 2054 BEGIN:VCALENDAR 2055 VERSION:2.0 2056 PRODID:-//Example Corp.//CalDAV Client//EN 2057 BEGIN:VEVENT 2058 DTSTAMP:20060206T001121Z 2059 DTSTART:20060103T170000 2060 DURATION:PT1H 2061 RECURRENCE-ID:20060103T170000 2062 SUMMARY:Event #2 2063 UID:00959BC664CA650E933C892C@example.com 2064 END:VEVENT 2065 BEGIN:VEVENT 2066 DTSTAMP:20060206T001121Z 2067 DTSTART:20060104T190000 2068 DURATION:PT1H 2069 RECURRENCE-ID:20060104T170000 2070 SUMMARY:Event #2 bis 2071 UID:00959BC664CA650E933C892C@example.com 2072 END:VEVENT 2073 END:VCALENDAR 2074 2075 2076 HTTP/1.1 200 OK 2077 2078 2079 2080 http://cal.example.com/bernard/work/abcd3.ics 2081 2082 2083 "fffff-abcd3" 2084 BEGIN:VCALENDAR 2085 VERSION:2.0 2086 PRODID:-//Example Corp.//CalDAV Client//EN 2087 BEGIN:VEVENT 2088 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 2089 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 2090 DTSTAMP:20060206T001220Z 2091 DTSTART:20060104T150000 2092 DURATION:PT1H 2093 LAST-MODIFIED:20060206T001330Z 2094 ORGANIZER:mailto:cyrus@example.com 2095 SEQUENCE:1 2096 STATUS:TENTATIVE 2097 SUMMARY:Event #3 2098 UID:DC6C50A017428C5216A2F1CD@example.com 2099 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com 2100 END:VEVENT 2101 END:VCALENDAR 2102 2103 2104 HTTP/1.1 200 OK 2105 2106 2107 2109 7.8.4. Example: Partial retrieval of stored free busy components 2111 In this example, the client requests the server to return the 2112 VFREEBUSY components that have free busy information that overlap the 2113 time range from January 2nd, 2006 at 00:00:00 AM UTC (inclusively) to 2114 January 3rd, 2006 at 00:00:00 AM UTC (exclusively). Use of the 2115 CALDAV:limit-freebusy-set element causes the server to only return 2116 the FREEBUSY property values that overlap the time range specified in 2117 that element. Note that this is not an example of discovering when 2118 the calendar owner is busy. 2120 See Appendix B for the calendar data being targeted by this example. 2122 >> Request << 2124 REPORT /bernard/work/ HTTP/1.1 2125 Host: cal.example.com 2126 Depth: 1 2127 Content-Type: application/xml; charset="utf-8" 2128 Content-Length: xxxx 2130 2131 2133 2134 2135 2137 2138 2139 2140 2141 2142 2144 2145 2146 2147 2148 >> Response << 2150 HTTP/1.1 207 Multi-Status 2151 Date: Fri, 11 Nov 2006 09:32:12 GMT 2152 Content-Type: application/xml; charset="utf-8" 2153 Content-Length: xxxx 2155 2156 2158 2159 http://cal.example.com/bernard/work/abcd8.ics 2160 2161 2162 "fffff-abcd8" 2163 BEGIN:VCALENDAR 2164 VERSION:2.0 2165 PRODID:-//Example Corp.//CalDAV Client//EN 2166 BEGIN:VFREEBUSY 2167 ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com 2168 UID:76ef34-54a3d2@example.com 2169 DTSTAMP:20050530T123421Z 2170 DTSTART:20060101T100000Z 2171 DTEND:20060108T100000Z 2172 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z 2173 END:VFREEBUSY 2174 END:VCALENDAR 2175 2176 2177 HTTP/1.1 200 OK 2178 2179 2180 2182 7.8.5. Example: Retrieval of to-dos by alarm time range 2184 In this example, the client requests the server to return the VTODO 2185 components that have an alarm trigger scheduled in the specified time 2186 range. 2188 See Appendix B for the calendar data being targeted by this example. 2190 >> Request << 2192 REPORT /bernard/work/ HTTP/1.1 2193 Host: cal.example.com 2194 Depth: 1 2195 Content-Type: application/xml; charset="utf-8" 2196 Content-Length: xxxx 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2210 2211 2212 2213 2214 2215 >> Response << 2217 HTTP/1.1 207 Multi-Status 2218 Date: Fri, 11 Nov 2006 09:32:12 GMT 2219 Content-Type: application/xml; charset="utf-8" 2220 Content-Length: xxxx 2222 2223 2225 2226 http://cal.example.com/bernard/work/abcd4.ics 2227 2228 2229 "fffff-abcd4" 2230 BEGIN:VCALENDAR 2231 VERSION:2.0 2232 PRODID:-//Example Corp.//CalDAV Client//EN 2233 BEGIN:VTODO 2234 DTSTAMP:20060205T235300Z 2235 DUE;TZID=US/Eastern:20060106T120000 2236 LAST-MODIFIED:20060205T235308Z 2237 SEQUENCE:1 2238 STATUS:NEEDS-ACTION 2239 SUMMARY:Task #2 2240 UID:E10BA47467C5C69BB74E8720@example.com 2241 BEGIN:VALARM 2242 ACTION:AUDIO 2243 TRIGGER;RELATED=START:-PT10M 2244 END:VALARM 2245 END:VTODO 2246 END:VCALENDAR 2247 2248 2249 HTTP/1.1 200 OK 2250 2251 2252 2254 7.8.6. Example: Retrieval of event by UID 2256 In this example, the client requests the server to return the VEVENT 2257 component that has the UID property set to 2258 "DC6C50A017428C5216A2F1CD@example.com". 2260 See Appendix B for the calendar data being targeted by this example. 2262 >> Request << 2264 REPORT /bernard/work/ HTTP/1.1 2265 Host: cal.example.com 2266 Depth: 1 2267 Content-Type: application/xml; charset="utf-8" 2268 Content-Length: xxxx 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 DC6C50A017428C5216A2F1CD@example.com 2282 2283 2284 2285 2286 2288 >> Response << 2290 HTTP/1.1 207 Multi-Status 2291 Date: Fri, 11 Nov 2006 09:32:12 GMT 2292 Content-Type: application/xml; charset="utf-8" 2293 Content-Length: xxxx 2295 2296 2298 2299 http://cal.example.com/bernard/work/abcd3.ics 2300 2301 2302 "fffff-abcd3" 2303 BEGIN:VCALENDAR 2304 VERSION:2.0 2305 PRODID:-//Example Corp.//CalDAV Client//EN 2306 BEGIN:VTIMEZONE 2307 LAST-MODIFIED:20040110T032845Z 2308 TZID:US/Eastern 2309 BEGIN:DAYLIGHT 2310 DTSTART:20000404T020000 2311 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2312 TZNAME:EDT 2313 TZOFFSETFROM:-0500 2314 TZOFFSETTO:-0400 2315 END:DAYLIGHT 2316 BEGIN:STANDARD 2317 DTSTART:20001026T020000 2318 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2319 TZNAME:EST 2320 TZOFFSETFROM:-0400 2321 TZOFFSETTO:-0500 2322 END:STANDARD 2323 END:VTIMEZONE 2324 BEGIN:VEVENT 2325 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 2326 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 2327 DTSTAMP:20060206T001220Z 2328 DTSTART;TZID=US/Eastern:20060104T100000 2329 DURATION:PT1H 2330 LAST-MODIFIED:20060206T001330Z 2331 ORGANIZER:mailto:cyrus@example.com 2332 SEQUENCE:1 2333 STATUS:TENTATIVE 2334 SUMMARY:Event #3 2335 UID:DC6C50A017428C5216A2F1CD@example.com 2336 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com 2337 END:VEVENT 2338 END:VCALENDAR 2339 2340 2341 HTTP/1.1 200 OK 2342 2343 2344 2346 7.8.7. Example: Retrieval of events by PARTSTAT 2348 In this example, the client requests the server to return the VEVENT 2349 components that have the ATTENDEE property with the value 2350 "mailto:lisa@example.com" and for which the PARTSTAT parameter is set 2351 to "NEEDS-ACTION". 2353 See Appendix B for the calendar data being targeted by this example. 2355 >> Request << 2357 REPORT /bernard/work/ HTTP/1.1 2358 Host: cal.example.com 2359 Depth: 1 2360 Content-Type: application/xml; charset="utf-8" 2361 Content-Length: xxxx 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 mailto:lisa@example.com 2375 2376 NEEDS-ACTION 2378 2379 2380 2381 2382 2383 2385 >> Response << 2387 HTTP/1.1 207 Multi-Status 2388 Date: Fri, 11 Nov 2006 09:32:12 GMT 2389 Content-Type: application/xml; charset="utf-8" 2390 Content-Length: xxxx 2392 2393 2395 2396 http://cal.example.com/bernard/work/abcd3.ics 2397 2398 2399 "fffff-abcd3" 2400 BEGIN:VCALENDAR 2401 VERSION:2.0 2402 PRODID:-//Example Corp.//CalDAV Client//EN 2403 BEGIN:VTIMEZONE 2404 LAST-MODIFIED:20040110T032845Z 2405 TZID:US/Eastern 2406 BEGIN:DAYLIGHT 2407 DTSTART:20000404T020000 2408 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2409 TZNAME:EDT 2410 TZOFFSETFROM:-0500 2411 TZOFFSETTO:-0400 2412 END:DAYLIGHT 2413 BEGIN:STANDARD 2414 DTSTART:20001026T020000 2415 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2416 TZNAME:EST 2417 TZOFFSETFROM:-0400 2418 TZOFFSETTO:-0500 2419 END:STANDARD 2420 END:VTIMEZONE 2421 BEGIN:VEVENT 2422 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 2423 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 2424 DTSTAMP:20060206T001220Z 2425 DTSTART;TZID=US/Eastern:20060104T100000 2426 DURATION:PT1H 2427 LAST-MODIFIED:20060206T001330Z 2428 ORGANIZER:mailto:cyrus@example.com 2429 SEQUENCE:1 2430 STATUS:TENTATIVE 2431 SUMMARY:Event #3 2432 UID:DC6C50A017428C5216A2F1CD@example.com 2433 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com 2434 END:VEVENT 2435 END:VCALENDAR 2436 2437 2438 HTTP/1.1 200 OK 2439 2440 2441 2443 7.8.8. Example: Retrieval of events only 2445 In this example, the client requests the server to return all VEVENT 2446 components. 2448 See Appendix B for the calendar data being targeted by this example. 2450 >> Request << 2452 REPORT /bernard/work/ HTTP/1.1 2453 Host: cal.example.com 2454 Depth: 1 2455 Content-Type: application/xml; charset="utf-8" 2456 Content-Length: xxxx 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2471 >> Response << 2473 HTTP/1.1 207 Multi-Status 2474 Date: Fri, 11 Nov 2006 09:32:12 GMT 2475 Content-Type: application/xml; charset="utf-8" 2476 Content-Length: xxxx 2478 2479 2481 2482 http://cal.example.com/bernard/work/abcd1.ics 2483 2484 2485 "fffff-abcd1" 2486 BEGIN:VCALENDAR 2487 VERSION:2.0 2488 PRODID:-//Example Corp.//CalDAV Client//EN 2489 BEGIN:VTIMEZONE 2490 LAST-MODIFIED:20040110T032845Z 2491 TZID:US/Eastern 2492 BEGIN:DAYLIGHT 2493 DTSTART:20000404T020000 2494 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2495 TZNAME:EDT 2496 TZOFFSETFROM:-0500 2497 TZOFFSETTO:-0400 2498 END:DAYLIGHT 2499 BEGIN:STANDARD 2500 DTSTART:20001026T020000 2501 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2502 TZNAME:EST 2503 TZOFFSETFROM:-0400 2504 TZOFFSETTO:-0500 2505 END:STANDARD 2506 END:VTIMEZONE 2507 BEGIN:VEVENT 2508 DTSTAMP:20060206T001102Z 2509 DTSTART;TZID=US/Eastern:20060102T100000 2510 DURATION:PT1H 2511 SUMMARY:Event #1 2512 Description:Go Steelers! 2513 UID:74855313FA803DA593CD579A@example.com 2514 END:VEVENT 2515 END:VCALENDAR 2516 2517 2518 HTTP/1.1 200 OK 2519 2520 2521 2522 http://cal.example.com/bernard/work/abcd2.ics 2523 2524 2525 "fffff-abcd2" 2526 BEGIN:VCALENDAR 2527 VERSION:2.0 2528 PRODID:-//Example Corp.//CalDAV Client//EN 2529 BEGIN:VTIMEZONE 2530 LAST-MODIFIED:20040110T032845Z 2531 TZID:US/Eastern 2532 BEGIN:DAYLIGHT 2533 DTSTART:20000404T020000 2534 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2535 TZNAME:EDT 2536 TZOFFSETFROM:-0500 2537 TZOFFSETTO:-0400 2538 END:DAYLIGHT 2539 BEGIN:STANDARD 2540 DTSTART:20001026T020000 2541 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2542 TZNAME:EST 2543 TZOFFSETFROM:-0400 2544 TZOFFSETTO:-0500 2545 END:STANDARD 2546 END:VTIMEZONE 2547 BEGIN:VEVENT 2548 DTSTAMP:20060206T001121Z 2549 DTSTART;TZID=US/Eastern:20060102T120000 2550 DURATION:PT1H 2551 RRULE:FREQ=DAILY;COUNT=5 2552 SUMMARY:Event #2 2553 UID:00959BC664CA650E933C892C@example.com 2554 END:VEVENT 2555 BEGIN:VEVENT 2556 DTSTAMP:20060206T001121Z 2557 DTSTART;TZID=US/Eastern:20060104T140000 2558 DURATION:PT1H 2559 RECURRENCE-ID;TZID=US/Eastern:20060104T120000 2560 SUMMARY:Event #2 bis 2561 UID:00959BC664CA650E933C892C@example.com 2562 END:VEVENT 2563 BEGIN:VEVENT 2564 DTSTAMP:20060206T001121Z 2565 DTSTART;TZID=US/Eastern:20060106T140000 2566 DURATION:PT1H 2567 RECURRENCE-ID;TZID=US/Eastern:20060106T120000 2568 SUMMARY:Event #2 bis bis 2569 UID:00959BC664CA650E933C892C@example.com 2570 END:VEVENT 2571 END:VCALENDAR 2572 2573 2574 HTTP/1.1 200 OK 2575 2576 2577 2578 http://cal.example.com/bernard/work/abcd3.ics 2579 2580 2581 "fffff-abcd3" 2582 BEGIN:VCALENDAR 2583 VERSION:2.0 2584 PRODID:-//Example Corp.//CalDAV Client//EN 2585 BEGIN:VTIMEZONE 2586 LAST-MODIFIED:20040110T032845Z 2587 TZID:US/Eastern 2588 BEGIN:DAYLIGHT 2589 DTSTART:20000404T020000 2590 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2591 TZNAME:EDT 2592 TZOFFSETFROM:-0500 2593 TZOFFSETTO:-0400 2594 END:DAYLIGHT 2595 BEGIN:STANDARD 2596 DTSTART:20001026T020000 2597 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2598 TZNAME:EST 2599 TZOFFSETFROM:-0400 2600 TZOFFSETTO:-0500 2601 END:STANDARD 2602 END:VTIMEZONE 2603 BEGIN:VEVENT 2604 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 2605 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 2606 DTSTAMP:20060206T001220Z 2607 DTSTART;TZID=US/Eastern:20060104T100000 2608 DURATION:PT1H 2609 LAST-MODIFIED:20060206T001330Z 2610 ORGANIZER:mailto:cyrus@example.com 2611 SEQUENCE:1 2612 STATUS:TENTATIVE 2613 SUMMARY:Event #3 2614 UID:DC6C50A017428C5216A2F1CD@example.com 2615 X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com 2616 END:VEVENT 2617 END:VCALENDAR 2618 2619 2620 HTTP/1.1 200 OK 2621 2622 2623 2625 7.8.9. Example: Retrieval of all pending to-dos 2627 In this example, the client requests the server to return all VTODO 2628 components that do not include a "COMPLETED" property and do not have 2629 a "STATUS" property value matching "CANCELLED". i.e., VTODOs that 2630 still need to be worked on. 2632 See Appendix B for the calendar data being targeted by this example. 2634 >> Request << 2636 REPORT /bernard/work/ HTTP/1.1 2637 Host: cal.example.com 2638 Depth: 1 2639 Content-Type: application/xml; charset="utf-8" 2640 Content-Length: xxxx 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 CANCELLED 2657 2658 2659 2660 2661 2663 >> Response << 2665 HTTP/1.1 207 Multi-Status 2666 Date: Fri, 11 Nov 2006 09:32:12 GMT 2667 Content-Type: application/xml; charset="utf-8" 2668 Content-Length: xxxx 2670 2671 2673 2674 http://cal.example.com/bernard/work/abcd4.ics 2675 2676 2677 "fffff-abcd4" 2678 BEGIN:VCALENDAR 2679 VERSION:2.0 2680 PRODID:-//Example Corp.//CalDAV Client//EN 2681 BEGIN:VTODO 2682 DTSTAMP:20060205T235335Z 2683 DUE;VALUE=DATE:20060104 2684 STATUS:NEEDS-ACTION 2685 SUMMARY:Task #1 2686 UID:DDDEEB7915FA61233B861457@example.com 2687 BEGIN:VALARM 2688 ACTION:AUDIO 2689 TRIGGER;RELATED=START:-PT10M 2690 END:VALARM 2691 END:VTODO 2692 END:VCALENDAR 2693 2694 2695 HTTP/1.1 200 OK 2696 2697 2699 2700 http://cal.example.com/bernard/work/abcd5.ics 2701 2702 2703 "fffff-abcd5" 2704 BEGIN:VCALENDAR 2705 VERSION:2.0 2706 PRODID:-//Example Corp.//CalDAV Client//EN 2707 BEGIN:VTODO 2708 DTSTAMP:20060205T235300Z 2709 DUE;VALUE=DATE:20060106 2710 LAST-MODIFIED:20060205T235308Z 2711 SEQUENCE:1 2712 STATUS:NEEDS-ACTION 2713 SUMMARY:Task #2 2714 UID:E10BA47467C5C69BB74E8720@example.com 2715 BEGIN:VALARM 2716 ACTION:AUDIO 2717 TRIGGER;RELATED=START:-PT10M 2718 END:VALARM 2719 END:VTODO 2720 END:VCALENDAR 2721 2722 2723 HTTP/1.1 200 OK 2724 2725 2726 2728 7.8.10. Example: Attempt to query unsupported property 2730 In this example, the client requests the server to return all VEVENT 2731 components that include an "X-ABC-GUID" property with a value 2732 matching "ABC". However, the server does not support querying that 2733 non-standard property and instead returns and error response. 2735 See Appendix B for the calendar data being targeted by this example. 2737 >> Request << 2739 REPORT /bernard/work/ HTTP/1.1 2740 Host: cal.example.com 2741 Depth: 1 2742 Content-Type: application/xml; charset="utf-8" 2743 Content-Length: xxxx 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 ABC 2756 2757 2758 2759 2760 2762 >> Response << 2764 HTTP/1.1 403 Forbidden 2765 Date: Fri, 11 Nov 2005 09:32:12 GMT 2766 Content-Type: application/xml; charset="utf-8" 2767 Content-Length: xxxx 2769 2770 2771 2772 2773 2774 2776 7.9. CALDAV:calendar-multiget Report 2778 The CALDAV:calendar-multiget REPORT is used to retrieve specific 2779 calendar object resources from within a collection, if the Request- 2780 URI is a collection, or to retrieve a specific calendar object 2781 resource, if the Request-URI is a calendar object resource. This 2782 REPORT is similar to the CALDAV:calendar-query REPORT (see 2783 Section 7.8), except that it takes a list of DAV:href elements 2784 instead of a CALDAV:filter element to determine which calendar object 2785 resources to return. 2787 Support for the calendar-multiget REPORT is REQUIRED. 2789 Marshalling: 2791 The request body MUST be a CALDAV:calendar-multiget XML element 2792 (see Section 9.10). If the Request-URI is a collection resource, 2793 then the DAV:href elements MUST refer to calendar object resources 2794 within that collection, and they MAY refer to calendar object 2795 resources at any depth within the collection. As a result the 2796 "Depth" header MUST be ignored by the server and SHOULD NOT be 2797 sent by the client. If the Request-URI refers to a non-collection 2798 resource, then there MUST be a single DAV:href element that is 2799 equivalent to the Request-URI. 2801 The response body for a successful request MUST be a DAV: 2802 multistatus XML element. 2804 The response body for a successful CALDAV:calendar-multiget REPORT 2805 request MUST contain a DAV:response element for each calendar 2806 object resource referenced by the provided set of DAV:href 2807 elements. Calendar data is being returned in the CALDAV:calendar- 2808 data element inside the DAV:prop element. 2810 In the case of an error accessing any of the provided DAV:href 2811 resources, the server MUST return the appropriate error status 2812 code in the DAV:status element of the corresponding DAV:response 2813 element. 2815 Preconditions: 2817 (CALDAV:supported-calendar-data): The attributes "content-type" 2818 and "version" of the CALDAV:calendar-data XML elements (see 2819 Section 9.6) specify a media type supported by the server for 2820 calendar object resources. 2822 (CALDAV:min-date-time): Any XML element specifying a range of time 2823 MUST have its start or end date or time values greater than or 2824 equal to the value of the CALDAV:min-date-time property value 2825 (Section 5.2.6) on the calendar collections being targeted by the 2826 REPORT; 2828 (CALDAV:max-date-time): Any XML element specifying a range of time 2829 MUST have its start or end date or time values less than or equal 2830 to the value of the CALDAV:max-date-time property value 2831 (Section 5.2.7) on the calendar collections being targeted by the 2832 REPORT; 2834 Postconditions: 2836 None. 2838 7.9.1. Example: Successful CALDAV:calendar-multiget Report 2840 In this example, the client requests the server to return specific 2841 properties of the VEVENT components referenced by specific URIs. In 2842 addition the DAV:getetag property is also requested and returned as 2843 part of the response. Note that in this example, the resource at 2844 http://cal.example.com/bernard/work/mtg1.ics does not exist, 2845 resulting in an error status response. 2847 See Appendix B for the calendar data being targeted by this example. 2849 >> Request << 2851 REPORT /bernard/work/ HTTP/1.1 2852 Host: cal.example.com 2853 Content-Type: application/xml; charset="utf-8" 2854 Content-Length: xxxx 2856 2857 2859 2860 2861 2862 2863 /bernard/work/abcd1.ics 2864 /bernard/work/mtg1.ics 2865 2867 >> Response << 2869 HTTP/1.1 207 Multi-Status 2870 Date: Fri, 11 Nov 2006 09:32:12 GMT 2871 Content-Type: application/xml; charset="utf-8" 2872 Content-Length: xxxx 2874 2875 2877 2878 http://cal.example.com/bernard/work/abcd1.ics 2879 2880 2881 "fffff-abcd1" 2882 BEGIN:VCALENDAR 2883 VERSION:2.0 2884 PRODID:-//Example Corp.//CalDAV Client//EN 2885 BEGIN:VTIMEZONE 2886 LAST-MODIFIED:20040110T032845Z 2887 TZID:US/Eastern 2888 BEGIN:DAYLIGHT 2889 DTSTART:20000404T020000 2890 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 2891 TZNAME:EDT 2892 TZOFFSETFROM:-0500 2893 TZOFFSETTO:-0400 2894 END:DAYLIGHT 2895 BEGIN:STANDARD 2896 DTSTART:20001026T020000 2897 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 2898 TZNAME:EST 2899 TZOFFSETFROM:-0400 2900 TZOFFSETTO:-0500 2901 END:STANDARD 2902 END:VTIMEZONE 2903 BEGIN:VEVENT 2904 DTSTAMP:20060206T001102Z 2905 DTSTART;TZID=US/Eastern:20060102T100000 2906 DURATION:PT1H 2907 SUMMARY:Event #1 2908 Description:Go Steelers! 2909 UID:74855313FA803DA593CD579A@example.com 2910 END:VEVENT 2911 END:VCALENDAR 2912 2913 2914 HTTP/1.1 200 OK 2915 2916 2917 2918 http://cal.example.com/bernard/work/mtg1.ics 2919 HTTP/1.1 404 Not Found 2921 2922 2924 7.10. CALDAV:free-busy-query Report 2926 The CALDAV:free-busy-query REPORT generates a VFREEBUSY component 2927 containing free busy information for all the calendar object 2928 resources targeted by the request and which have the CALDAV:read- 2929 free-busy or DAV:read privilege granted to the current user. 2931 Only VEVENT components without a TRANSP property or with the TRANSP 2932 property set to "OPAQUE", and VFREEBUSY components SHOULD be 2933 considered to generate the free busy time information. 2935 In the case of VEVENT components, the free or busy time type (FBTYPE) 2936 of the FREEBUSY properties in the returned VFREEBUSY component SHOULD 2937 be derived from the value of the TRANSP and STATUS properties as 2938 outlined in the table below: 2940 +---------------------------++------------------+ 2941 | VEVENT || VFREEBUSY | 2942 +-------------+-------------++------------------+ 2943 | TRANSP | STATUS || FBTYPE | 2944 +=============+=============++==================+ 2945 | | CONFIRMED || BUSY | 2946 | | (default) || | 2947 | OPAQUE +-------------++------------------+ 2948 | (default) | CANCELLED || FREE | 2949 | +-------------++------------------+ 2950 | | TENTATIVE || BUSY-TENTATIVE | 2951 | +-------------++------------------+ 2952 | | x-name || BUSY or | 2953 | | || x-name | 2954 +-------------+-------------++------------------+ 2955 | | CONFIRMED || | 2956 | TRANSPARENT | CANCELLED || FREE | 2957 | | TENTATIVE || | 2958 | | x-name || | 2959 +-------------+-------------++------------------+ 2961 Duplicate busy time periods with the same FBTYPE parameter value 2962 SHOULD NOT be specified in the returned VFREEBUSY component. Servers 2963 SHOULD coalesce consecutive or overlapping busy time period of the 2964 same type. Busy time periods with different FBTYPE parameter values 2965 MAY overlap. 2967 Support for the CALDAV:free-busy-query REPORT is REQUIRED. 2969 Marshalling: 2971 The request body MUST be a CALDAV:free-busy-query XML element (see 2972 Section 9.11, which MUST contain exactly one CALDAV:time-range XML 2973 element, as defined in Section 9.9. 2975 The request MAY include a Depth header. If no Depth header is 2976 included, Depth:0 is assumed. 2978 The response body for a successful request MUST be an iCalendar 2979 object that contains exactly one VFREEBUSY component that 2980 describes the busy time intervals for the calendar object 2981 resources containing VEVENT or VFREEBUSY components that satisfy 2982 the Depth value and for which the current user is at least granted 2983 the CALDAV:read-free-busy privilege. If no calendar object 2984 resources are found to satisfy these conditions a VFREEBUSY 2985 component with no FREEBUSY property MUST be returned. This REPORT 2986 only returns busy time information. Free time information can be 2987 inferred from the returned busy time information. 2989 If the current user is not granted the CALDAV:read-free-busy or 2990 DAV:read privileges on the Request-URI, the CALDAV:free-busy-query 2991 REPORT request MUST fail and return a 404 (Not Found) status 2992 value. This restriction will prevent users from discovering URLs 2993 of resources for which they are only granted the CALDAV:read-free- 2994 busy privilege. 2996 The CALDAV:free-busy-query REPORT request can only be run against 2997 a collection (either a regular collection or a calendar 2998 collection). An attempt to run the report on a calendar object 2999 resource MUST fail and return a 403 (Forbidden) status value. 3001 Preconditions: 3003 None. 3005 Postconditions: 3007 (DAV:number-of-matches-within-limits): The number of matching 3008 calendar object resources must fall within server-specific, 3009 predefined limits. For example, this postcondition might fail if 3010 the specified CALDAV:time-range would cause an extremely large 3011 number calendar object resources to be considered to compute the 3012 response. 3014 7.10.1. Example: Successful CALDAV:free-busy-query Report 3016 In this example, the client requests the server to return free busy 3017 information on the calendar collection /bernard/work/, between 9:00 3018 AM and 5:00 PM EST (2:00 PM and 10:00 PM UTC) on the 4th January 3019 2006. The server responds indicating two busy time intervals of one 3020 hour, one of which is tentative. 3022 See Appendix B for the calendar data being targeted by this example. 3024 >> Request << 3026 REPORT /bernard/work/ HTTP/1.1 3027 Host: cal.example.com 3028 Depth: 1 3029 Content-Type: application/xml; charset="utf-8" 3030 Content-Length: xxxx 3032 3033 3034 3036 3038 >> Response << 3040 HTTP/1.1 200 OK 3041 Date: Fri, 11 Nov 2006 09:32:12 GMT 3042 Content-Type: text/calendar 3043 Content-Length: xxxx 3045 BEGIN:VCALENDAR 3046 VERSION:2.0 3047 PRODID:-//Example Corp.//CalDAV Server//EN 3048 BEGIN:VFREEBUSY 3049 DTSTAMP:20050125T090000Z 3050 DTSTART:20060104T140000Z 3051 DTEND:20060105T220000Z 3052 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H 3053 FREEBUSY:20060104T190000Z/PT1H 3054 END:VFREEBUSY 3055 END:VCALENDAR 3057 8. Guidelines 3058 8.1. Client-to-client Interoperability 3060 There are a number of actions clients can take which will be legal 3061 (the server will not return errors) but which can degrade 3062 interoperability with other client implementations accessing the same 3063 data. For example, a recurrence rule could be replaced with a set of 3064 recurrence dates, a single recurring event could be replaced with a 3065 set of independent resources to represent each recurrence, or the 3066 start/end time values can be translated from the original time zone 3067 to another time zone. Although this advice amounts to iCalendar 3068 interoperability best practices and is not limited only to CalDAV 3069 usage, interoperability problems are likely to be more evident in 3070 CalDAV use cases. 3072 8.2. Synchronization Operations 3074 WebDAV already provides functionality required to synchronize a 3075 collection or set of collections, make changes offline, and a simple 3076 way to resolve conflicts when reconnected. ETags are the key to 3077 making this work, but these are not required of all WebDAV servers. 3078 Since offline functionality is more important to calendar 3079 applications than to some other WebDAV applications, CalDAV servers 3080 MUST support ETags as specified in Section 5.3.4. 3082 8.2.1. Use of Reports 3084 8.2.1.1. Restrict the Time Range 3086 The REPORTs provided in CalDAV can be used by clients to optimize 3087 their performance in terms of network bandwidth usage, and resource 3088 consumption on the local client machine. Both are certainly major 3089 considerations for mobile or handheld devices with limited capacity, 3090 but they are also relevant to desktop client applications in cases 3091 where the calendar collections contain large amounts of data. 3093 Typically clients present calendar data to users in views that span a 3094 finite time interval, so whenever possible clients should only 3095 retrieve calendar components from the server using CALDAV:calendar- 3096 query REPORT combined with a CALDAV:time-range element to limit the 3097 set of returned components to just those needed to populate the 3098 current view. 3100 8.2.1.2. Synchronize by Time Range 3102 Typically in a calendar, historical data (events, to-dos etc. that 3103 have completed prior to the current date) do not change, though they 3104 may be deleted. As a result, a client can speed up the 3105 synchronization process by only considering data for the present time 3106 and the future up to a reasonable limit (e.g., one week, one month). 3107 If the user then tries to examine a portion of the calendar outside 3108 of the range that has been synchronized, the client can perform 3109 another synchronization operation on the new time interval being 3110 examined. This "just-in-time" synchronization can minimize bandwidth 3111 for common user interaction behaviors. 3113 8.2.1.3. Synchronization Process 3115 If a client wants to support calendar data synchronization, as 3116 opposed to downloading calendar data each time it is needed, it needs 3117 to cache the calendar object resource's URI and ETag along with the 3118 actual calendar data. While the URI remains static for the lifetime 3119 of the calendar object resource, the ETag will change with each 3120 successive change to the calendar object resource. Thus to 3121 synchronize a local data cache with the server, the client can first 3122 fetch the URI/ETag pairs for the time interval being considered, and 3123 compare those results with the cached data. Any cached component 3124 whose ETag differs from that on the server needs to be refreshed. 3126 In order to properly detect the changes between the server and client 3127 data, the client will need to keep a record of which calendar object 3128 resources have been created, changed or deleted since the last 3129 synchronization operation so that it can reconcile those changes with 3130 the data on the server. 3132 Here's an example of how to do that: 3134 The client issues a CALDAV:calendar-query REPORT request for a 3135 specific time range, and asks for only the DAV:getetag property to be 3136 returned: 3138 REPORT /bernard/work/ HTTP/1.1 3139 Host: cal.example.com 3140 Depth: 1 3141 Content-Type: application/xml; charset="utf-8" 3142 Content-Length: xxxx 3144 3145 3147 3148 3149 3150 3151 3152 3153 3155 3156 3157 3158 3160 The client then uses the results to determine which calendar object 3161 resources have changed, been created or deleted on the server and how 3162 those relate to locally cached calendar object resources that may 3163 have changed, been created or deleted. If the client determines that 3164 there are calendar object resources on the server that need to be 3165 fetched, the client issues a CALDAV:calendar-multiget REPORT request 3166 to fetch their calendar data: 3168 REPORT /bernard/work/ HTTP/1.1 3169 Host: cal.example.com 3170 Content-Type: application/xml; charset="utf-8" 3171 Content-Length: xxxx 3173 3174 3176 3177 3178 3179 3180 /bernard/work/abcd1.ics 3181 /bernard/work/mtg1.ics 3182 3184 8.2.2. Restrict the Properties Returned 3186 Clients may not need all the calendar properties of a calendar object 3187 resource when presenting information to the user. Since some 3188 calendar property values can be large (e.g., ATTACH or ATTENDEE) 3189 clients can choose to restrict the calendar properties to be returned 3190 in a calendaring REPORT request to those it knows it will use. 3192 However, if a client needs to make a change to a calendar object 3193 resource, it can only change the entire calendar object resource via 3194 a PUT request. There is currently no way to incrementally make a 3195 change to a set of calendar properties of a calendar object resource. 3196 As a result the client will have to get the entire calendar object 3197 resource that is being changed. 3199 8.3. Use of Locking 3201 WebDAV locks can be used to prevent two clients modifying the same 3202 resource from either overwriting each others' changes (though that 3203 problem can also be solved by using ETags) or wasting time making 3204 changes that will conflict with another set of changes. In a multi- 3205 user calendar system, an interactive calendar client could lock an 3206 event while the user is editing the event, and unlock the event when 3207 the user finishes or cancels. Locks can also be used to prevent 3208 changes while data is being reorganized. For example, a calendar 3209 client might lock two calendar collections prior to moving a bunch of 3210 calendar resources from one to another. 3212 Clients are responsible for requesting a lock timeout period that is 3213 appropriate to the use case. When the user explicitly decides to 3214 reserve a resource and prevent other changes, a long timeout might be 3215 appropriate, but in cases when the client automatically decides to 3216 lock the resource the timeout should be short (and the client can 3217 always refresh the lock should it need to). A short lock timeout 3218 means that if the client is unable to remove the lock, the other 3219 calendar users aren't prevented from making changes. 3221 8.4. Finding calendars 3223 Much of the time a calendar client (or agent) will discover a new 3224 calendar's location by being provided directly with the URL. E.g., a 3225 user will type his or her own calendar location into client 3226 configuration information, or copy and paste a URL from email into 3227 the calendar application. The client need only confirm that the URL 3228 points to a resource which is a calendar collection. The client may 3229 also be able to browse WebDAV collections to find calendar 3230 collections. 3232 The choice of HTTP URLs means that calendar object resources are 3233 backward compatible with existing software, but does have the 3234 disadvantage that existing software does not usually know to look at 3235 the OPTIONS response to that URL to determine what can be done with 3236 it. This is somewhat of a barrier for WebDAV usage as well as with 3237 CalDAV usage. This specification does not offer a way through this 3238 other than making the information available in the OPTIONS response 3239 should this be requested. 3241 For calendar sharing and scheduling use cases, one might wish to find 3242 the calendar belonging to another user. If the other user has a 3243 calendar in the same repository, that calendar can be found by using 3244 the principal namespace required by WebDAV ACL support. For other 3245 cases, the authors have no universal solution but implementers can 3246 consider whether to use vCard [RFC2426] or LDAP [RFC4511] standards 3247 together with calendar attributes [RFC2739]. 3249 Because CalDAV requires servers to support WebDAV ACL [RFC3744] 3250 including principal namespaces, and with the addition of the CALDAV: 3251 calendar-home-set property, there are a couple options for CalDAV 3252 clients to find one's own calendar or another user's calendar. 3254 In this case, a DAV:principal-match REPORT is used to find a named 3255 property (the CALDAV:calendar-home-set) on the Principal-URL of the 3256 current user. Using this, a WebDAV client can learn "who am I" and 3257 "where are my calendars". The REPORT request body looks like this: 3259 3260 3261 3262 3263 3265 3266 3268 To find other users calendars, the DAV:principal-property-search 3269 REPORT can be used to filter on some properties and return others. 3270 To search for a calendar owned by a user named "Laurie", the REPORT 3271 request body would look like this: 3273 3274 3275 3276 3277 3278 3279 Laurie 3280 3281 3282 3284 3285 3286 3288 The server performs a case-sensitive or caseless search for a 3289 matching string subset of "Laurie" within the DAV:displayname 3290 property. Thus, the server might return "Laurie Dusseault", "Laurier 3291 Desruisseaux" or "Wilfrid Laurier" all as matching DAV:displayname 3292 values, and the calendars for each of these. 3294 8.5. Storing and Using Attachments 3296 CalDAV clients MAY create attachments in calendar components either 3297 as inline or external. This section contains some guidelines on 3298 creating and managing attachments. 3300 8.5.1. Inline attachments 3302 CalDAV clients MUST support inline attachments as specified in 3303 iCalendar [RFC2445]. CalDAV servers MUST support inline attachments, 3304 so clients can rely on being able to create attachments this way. On 3305 the other hand, inline attachments have some drawbacks: 3307 o Servers MAY impose limitations on the size of calendar object 3308 resources (i.e., refusing PUT requests of very large iCalendar 3309 objects). Servers that do that MUST use the CALDAV:max-resource- 3310 size property on a calendar collection to inform the client as to 3311 what the limitation is (see Section 5.2.5). 3313 o Servers MAY impose storage quota limitations on calendar 3314 collections (See [RFC4331]). 3316 o Any change to a calendar object resource containing an attachment 3317 requires the entire attachment to be re-uploaded. 3319 o Clients synchronizing a changed calendar object resource have to 3320 download the entire calendar object resource even if the 3321 attachment is unchanged. 3323 8.5.2. External attachments 3325 CalDAV clients SHOULD support downloading of external attachments 3326 referenced by arbitrary URI schemes, by either processing them 3327 directly, or by passing the attachment URI to a suitable "helper 3328 application" for processing, if such an application exists. CalDAV 3329 clients MUST support downloading of external attachments referenced 3330 by the "http" or "https" URI schemes. An external attachment could 3331 be: 3333 o In a collection in the calendar collection containing the calendar 3334 object resource; 3336 o Somewhere else in the same repository that hosts the calendar 3337 collection; or 3339 o On an HTTP or FTP server elsewhere. 3341 CalDAV servers MAY provide support for child collections in calendar 3342 collections. CalDAV servers MAY allow the MKCOL method to create 3343 child collections in calendar collections. Child collections of 3344 calendar collections MAY contain any type of resource except calendar 3345 collections which they MUST NOT contain. Some CalDAV servers won't 3346 allow child collections in calendar collections, and it may be 3347 possible on such a server to discover other locations where 3348 attachments can be stored. 3350 Clients are entirely responsible for maintaining reference 3351 consistency with calendar components that link to external 3352 attachments. A client deleting a calendar component with an external 3353 attachment might therefore also delete the attachment if that's 3354 appropriate, however appropriateness can be very hard to determine. 3355 A new component might easily reference some pre-existing Web resource 3356 which is intended to have independent existence from the calendar 3357 component (the "attachment" could be a major proposal to be discussed 3358 in a meeting, for instance). Best practices will probably emerge and 3359 should probably be documented but for now clients should be wary of 3360 engaging in aggressive "cleanup" of external attachments. A client 3361 could involve the user in making decisions about removing 3362 unreferenced documents, or a client could be conservative in only 3363 deleting attachments it had created. 3365 Also, clients are responsible for consistency of permissions when 3366 using external attachments. One reason for servers to support the 3367 storage of attachments within child collections of calendar 3368 collections is that ACL inheritance might make it easier to grant the 3369 same permissions to attachments that are granted on the calendar 3370 collection. Otherwise, it can be very difficult to keep permissions 3371 synchronized. With attachments stored on separate repositories, it 3372 can be impossible to keep permissions consistent -- the two 3373 repositories may not support the same permissions or have the same 3374 set of principals. Some systems have used tickets or other anonymous 3375 access control mechanisms to provide partially satisfactory solutions 3376 to these kinds of problems. 3378 8.6. Storing and Using Alarms 3380 Note that all CalDAV calendar collections (including those which the 3381 user might treat as public or group calendars) can contain alarm 3382 information on events and to-dos. Users can synchronize a calendar 3383 between multiple devices and decide to have alarms execute on a 3384 different device than the device that created the alarm. Not all 3385 alarm action types are completely interoperable (e.g., those which 3386 name a sound file to play). 3388 When the action is "AUDIO", and the client is configured to 3389 execute the alarm, the client SHOULD play the suggested sound if 3390 it's available or play another sound, but SHOULD NOT rewrite the 3391 alarm just to replace the suggested sound with a sound that's 3392 locally available. 3394 When the action is "DISPLAY", and the client is configured to 3395 execute the alarm, the client SHOULD execute a display alarm by 3396 displaying either according to the suggested description or some 3397 reasonable replacement, but SHOULD NOT rewrite the alarm for its 3398 own convenience. 3400 When the action is "EMAIL", and the client is incapable of sending 3401 email, it SHOULD ignore the alarm but MUST continue to synchronize 3402 the alarm itself. 3404 This specification makes no recommendations about executing alarms 3405 of type PROCEDURE except to note that clients are advised to take 3406 care to avoid creating security holes by executing these. 3408 Non-interoperable alarm information (e.g., should somebody define a 3409 color to be used in a display alarm) should be put in non-standard 3410 properties inside the VALARM component in order to keep the basic 3411 alarm usable on all devices. 3413 Clients that allow changes to calendar object resources MUST 3414 synchronize the alarm data that already exists in the resources. 3415 Clients MAY execute alarms that are downloaded in this fashion, 3416 possibly based on user preference. If a client is only doing read 3417 operations on a calendar and there is no risk of losing alarm 3418 information, then the client MAY discard alarm information. 3420 This specification makes no attempt to provide multi-user alarms on 3421 group calendars or to find out who an alarm is intended for. 3422 Addressing those issues might require extensions to iCalendar, for 3423 example to store alarms per-user or indicate which user a VALARM was 3424 intended for. In the meantime, clients might maximize 3425 interoperability by generally not uploading alarm information to 3426 public, group or resource calendars. 3428 9. XML Element Definitions 3430 9.1. CALDAV:calendar XML Element 3432 Name: calendar 3434 Namespace: urn:ietf:params:xml:ns:caldav 3436 Purpose: Specifies the resource type of a calendar collection. 3438 Description: See Section 4.2. 3440 Definition: 3442 3444 9.2. CALDAV:mkcalendar XML Element 3446 Name: mkcalendar 3448 Namespace: urn:ietf:params:xml:ns:caldav 3450 Purpose: Specifies a request that includes the WebDAV property values 3451 to be set for a calendar collection resource when it is created. 3453 Description: See Section 5.3.1. 3455 Definition: 3457 3459 9.3. CALDAV:mkcalendar-response XML Element 3460 Name: mkcalendar-response 3462 Namespace: urn:ietf:params:xml:ns:caldav 3464 Purpose: Specifies a response body for a successful MKCALENDAR 3465 request. 3467 Description: See Section 5.3.1. 3469 Definition: 3471 3473 9.4. CALDAV:supported-collation XML Element 3475 Name: supported-collation 3477 Namespace: urn:ietf:params:xml:ns:caldav 3479 Purpose: Identifies a single collation via its collation identifier 3480 as defined by [I-D.newman-i18n-comparator]. 3482 Description: The CALDAV:supported-collation contains the text of a 3483 collation identifier as described in Section 7.5.1. 3485 Definition: 3487 3488 PCDATA value: collation identifier 3490 9.5. CALDAV:calendar-query XML Element 3492 Name: calendar-query 3494 Namespace: urn:ietf:params:xml:ns:caldav 3496 Purpose: Defines a REPORT for querying calendar object resources. 3498 Description: See Section 7.8. 3500 Definition: 3502 3506 9.6. CALDAV:calendar-data XML Element 3508 Name: calendar-data 3510 Namespace: urn:ietf:params:xml:ns:caldav 3512 Purpose: Used to (1) specify a supported media type for calendar 3513 object resources when nested in the CALDAV:supported-calendar-data 3514 property; (2) specify which parts of a calendar object resource 3515 should be returned by a given calendaring REPORT; and (3) specify 3516 the content of a calendar object resource in a response to a 3517 calendaring REPORT. 3519 Description: When nested in the CALDAV:supported-calendar-data 3520 property, the CALDAV:calendar-data XML element specifies a media 3521 type supported by the CalDAV server for calendar object resources. 3523 When used in a calendaring REPORT request, the CALDAV:calendar- 3524 data XML element specifies which parts of calendar object 3525 resources need to be returned in the response. If the CALDAV: 3526 calendar-data XML element doesn't contain any CALDAV:comp element, 3527 calendar object resources will be returned in their entirety. 3529 Finally, when used in a calendaring REPORT response, the CALDAV: 3530 calendar-data XML element specifies the content of a calendar 3531 object resource. Given that XML parsers normalize the two- 3532 character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal 3533 10) to a single LF character (US-ASCII decimal 10), the CR 3534 character (US-ASCII decimal 13) MAY be omitted in calendar object 3535 resources specified in the CALDAV:calendar-data XML element. 3536 Furthermore, calendar object resources specified in the CALDAV: 3537 calendar-data XML element MAY be invalid per their media type 3538 specification if the CALDAV:calendar-data XML element part of the 3539 calendaring REPORT request did not specify required properties 3540 (e.g., UID, DTSTAMP, etc.) or specified a CALDAV:prop XML element 3541 with the "novalue" attribute set to "yes". 3543 Note: The CALDAV:calendar-data XML element is specified in requests 3544 and responses inside the DAV:prop XML element as if it were a 3545 WebDAV property. However, the CALDAV:calendar-data XML element is 3546 not a WebDAV property and as such it is not returned in PROPFIND 3547 responses nor used in PROPPATCH requests. 3549 Note: The iCalendar data embedded within the CALDAV:calendar-data XML 3550 element MUST follow the standard XML character data encoding 3551 rules, including use of <, >, & etc entity encoding or 3552 the use of a construct. In the later case the 3553 iCalendar data cannot contain the character sequence "]]>" which 3554 is the end delimiter for the CDATA section. 3556 Definition: 3558 3562 PCDATA value: iCalendar object 3564 3565 version CDATA "2.0"> 3566 content-type value: a MIME media type 3567 version value: a version string 3569 9.6.1. CALDAV:comp XML Element 3571 Name: comp 3573 Namespace: urn:ietf:params:xml:ns:caldav 3575 Purpose: Defines which component types to return. 3577 Description: The name value is a calendar component name (e.g., 3578 "VEVENT"). 3580 Definition: 3582 3584 3585 name value: a calendar component name 3587 Note: The CALDAV:prop and CALDAV:allprop elements have the same name 3588 as the DAV:prop and DAV:allprop elements defined in [RFC2518]. 3589 However, the CALDAV:prop and CALDAV:allprop element are defined in 3590 the "urn:ietf:params:xml:ns:caldav" namespace instead of the 3591 "DAV:" namespace. 3593 9.6.2. CALDAV:allcomp XML Element 3595 Name: allcomp 3597 Namespace: urn:ietf:params:xml:ns:caldav 3598 Purpose: Specifies that all components shall be returned. 3600 Description: The CALDAV:allcomp XML element can be used when the 3601 client wants all types of components returned by a calendaring 3602 REPORT request. 3604 Definition: 3606 3608 9.6.3. CALDAV:allprop XML Element 3610 Name: allprop 3612 Namespace: urn:ietf:params:xml:ns:caldav 3614 Purpose: Specifies that all properties shall be returned. 3616 Description: The CALDAV:allprop XML element can be used when the 3617 client wants all properties of components returned by a 3618 calendaring REPORT request. 3620 Definition: 3622 3624 Note: The CALDAV:allprop element has the same name as the DAV:allprop 3625 element defined in [RFC2518]. However, the CALDAV:allprop element 3626 is defined in the "urn:ietf:params:xml:ns:caldav" namespace 3627 instead of the "DAV:" namespace. 3629 9.6.4. CALDAV:prop XML Element 3631 Name: prop 3633 Namespace: urn:ietf:params:xml:ns:caldav 3635 Purpose: Defines which properties to return in the response. 3637 Description: The "name" attribute specifies the name of the calendar 3638 property to return (e.g., "ATTENDEE"). The "novalue" attribute 3639 can be used by clients to request that the actual value of the 3640 property not be returned (if the "novalue" attribute is set to 3641 "yes"). In that case the server will return just the iCalendar 3642 property name and any iCalendar parameters and a trailing ":" 3643 without the subsequent value data. 3645 Definition: 3647 3649 3651 name value: a calendar property name 3652 novalue value: "yes" or "no" 3654 Note: The CALDAV:prop element has the same name as the DAV:prop 3655 element defined in [RFC2518]. However, the CALDAV:prop element is 3656 defined in the "urn:ietf:params:xml:ns:caldav" namespace instead 3657 of the "DAV:" namespace. 3659 9.6.5. CALDAV:expand XML Element 3661 Name: expand 3663 Namespace: urn:ietf:params:xml:ns:caldav 3665 Purpose: Forces the server to expand recurring components into 3666 individual recurrence instances. 3668 Description: The CALDAV:expand XML element specifies that for a given 3669 calendaring REPORT request the server MUST expand the recurrence 3670 set into calendar components that define exactly one recurrence 3671 instance and MUST return only those whose scheduled time intersect 3672 a specified time range. The "start" attribute specifies the 3673 inclusive start of the time range, and the "end" attribute 3674 specifies the non-inclusive end of the time range. Both 3675 attributes are specified as date with UTC time value. The value 3676 of the "end" attribute MUST be greater than the value of the 3677 "start" attribute. The server MUST use the same logic as defined 3678 for CALDAV:time-range to determine if a recurrence instance 3679 intersects the specified time range. Recurring components, other 3680 than the initial instance, MUST include a RECURRENCE-ID property 3681 indicating which instance they refer to. The returned calendar 3682 components MUST NOT use recurrence properties (i.e., EXDATE, 3683 EXRULE, RDATE and RRULE) and MUST NOT have reference to or include 3684 VTIMEZONE components. Date and local time with reference to time 3685 zone information MUST be converted into date with UTC time. 3687 Definition: 3689 3691 3693 start value: an iCalendar "date with UTC time" 3694 end value: an iCalendar "date with UTC time" 3696 9.6.6. CALDAV:limit-recurrence-set XML Element 3698 Name: limit-recurrence-set 3700 Namespace: urn:ietf:params:xml:ns:caldav 3702 Purpose: Specifies a time range to limit the set of "overridden 3703 components" returned by the server. 3705 Description: The CALDAV:limit-recurrence-set XML element specifies 3706 that for a given calendaring REPORT request the server MUST 3707 return, in addition to the "master component", only the 3708 "overridden components" that impact a specified time range. An 3709 overridden component impacts a time range if its current start and 3710 end times overlap the time range, or if the original start and end 3711 times - the ones that would have been used if the instance were 3712 not overridden - overlap the time range. The "start" attribute 3713 specifies the inclusive start of the time range, and the "end" 3714 attribute specifies the non-inclusive end of the time range. Both 3715 attributes are specified as date with UTC time value. The value 3716 of the "end" attribute MUST be greater than the value of the 3717 "start" attribute. The server MUST use the same logic as defined 3718 for CALDAV:time-range to determine if the current or original 3719 scheduled time of an "overridden" recurrence instance intersect 3720 the specified time range. Overridden components that have a RANGE 3721 parameter on their RECURRENCE-ID property may specify one or more 3722 instances in the recurrence set, and some of those instances may 3723 fall within the specified time range, or may have originally 3724 fallen within the specified time range prior to being overridden. 3725 If that is the case, the overridden component MUST be included in 3726 the results as it has a direct impact on the interpretation of 3727 instances within the specified time range. 3729 Definition: 3731 3733 3735 start value: an iCalendar "date with UTC time" 3736 end value: an iCalendar "date with UTC time" 3738 9.6.7. CALDAV:limit-freebusy-set XML Element 3740 Name: limit-freebusy-set 3742 Namespace: urn:ietf:params:xml:ns:caldav 3744 Purpose: Specifies a time range to limit the set of FREEBUSY values 3745 returned by the server. 3747 Description: The CALDAV:limit-freebusy-set XML element specifies that 3748 for a given calendaring REPORT request the server MUST only return 3749 the FREEBUSY property values of a VFREEBUSY component that 3750 intersect a specified time range. The "start" attribute specifies 3751 the inclusive start of the time range, and the "end" attribute 3752 specifies the non-inclusive end of the time range. Both 3753 attributes are specified as "date with UTC time" value. The value 3754 of the "end" attribute MUST be greater than the value of the 3755 "start" attribute. The server MUST use the same logic as defined 3756 for CALDAV:time-range to determine if a FREEBUSY property value 3757 intersect the specified time range. 3759 Definition: 3761 3763 3765 start value: an iCalendar "date with UTC time" 3766 end value: an iCalendar "date with UTC time" 3768 9.7. CALDAV:filter XML Element 3770 Name: filter 3772 Namespace: urn:ietf:params:xml:ns:caldav 3774 Purpose: Specifies a filter to limit the set of calendar components 3775 returned by the server. 3777 Description: The CALDAV:filter XML element specifies the search 3778 filter used to limit the calendar components returned by a 3779 calendaring REPORT request. 3781 Definition: 3783 3785 9.7.1. CALDAV:comp-filter XML Element 3787 Name: comp-filter 3789 Namespace: urn:ietf:params:xml:ns:caldav 3791 Purpose: Specifies search criteria on calendar components. 3793 Description: The CALDAV:comp-filter XML element specifies the queried 3794 calendar component type (e.g., "VEVENT"). A calendar object 3795 resource is said to match a CALDAV:comp-filter if: 3797 * A component of the type specified by the "name" attribute 3798 exists, and the CALDAV:comp-filter is empty, or it contains at 3799 least one recurrence instance scheduled to overlap a given time 3800 range if a CALDAV:time-range XML element is specified, and that 3801 any CALDAV:prop-filter and CALDAV:comp-filter child elements 3802 also match. 3804 or: 3806 * A component of the type specified by the "name" attribute does 3807 not exist, and the CALDAV:is-not-defined element is specified. 3809 Definition: 3811 3814 3815 name value: a calendar component name (e.g., "VEVENT") 3817 9.7.2. CALDAV:prop-filter XML Element 3819 Name: prop-filter 3821 Namespace: urn:ietf:params:xml:ns:caldav 3823 Purpose: Specifies search criteria on calendar properties. 3825 Description: The CALDAV:prop-filter XML element specifies a search 3826 criteria on a specific calendar property (e.g., CATEGORIES) in the 3827 scope of a given CALDAV:comp-filter. A calendar component is said 3828 to match a CALDAV:prop-filter if: 3830 * A property of the type specified by the "name" attribute 3831 exists, and the CALDAV:prop-filter is empty, or it matches the 3832 CALDAV:time-range XML element or CALDAV:text-match conditions 3833 if specified, and that any CALDAV:param-filter child elements 3834 also match. 3836 or: 3838 * A property of the type specified by the "name" attribute does 3839 not exist, and the CALDAV:is-not-defined element is specified. 3841 Definition: 3843 3847 3848 name value: a calendar property name (e.g., "ATTENDEE") 3850 9.7.3. CALDAV:param-filter XML Element 3852 Name: param-filter 3854 Namespace: urn:ietf:params:xml:ns:caldav 3856 Purpose: Limits the search to specific parameter values. 3858 Description: The CALDAV:param-filter XML element specifies a search 3859 criteria on a specific calendar property parameter (e.g., 3860 PARTSTAT) in the scope of a given CALDAV:prop-filter. A calendar 3861 property is said to match a CALDAV:param-filter if: 3863 * A parameter of the type specified by the "name" attribute 3864 exists, and the CALDAV:param-filter is empty, or it matches the 3865 CALDAV:text-match conditions if specified. 3867 or: 3869 * A parameter of the type specified by the "name" attribute does 3870 not exist, and the CALDAV:is-not-defined element is specified. 3872 Definition: 3874 3876 3877 name value: a property parameter name (e.g., "PARTSTAT") 3879 9.7.4. CALDAV:is-not-defined XML Element 3881 Name: is-not-defined 3883 Namespace: urn:ietf:params:xml:ns:caldav 3885 Purpose: Specifies that a match should occur if the enclosing 3886 component, property or parameter does not exist. 3888 Description: The CALDAV:is-not-defined XML element specifies that a 3889 match occurs if the enclosing component, property or parameter 3890 value specified in a calendaring REPORT request does not exist in 3891 the calendar data being tested. 3893 Definition: 3895 3897 9.7.5. CALDAV:text-match XML Element 3899 Name: text-match 3901 Namespace: urn:ietf:params:xml:ns:caldav 3903 Purpose: Specifies a substring match on a property or parameter 3904 value. 3906 Description: The CALDAV:text-match XML element specifies text used 3907 for a substring match against the property or parameter value 3908 specified in a calendaring REPORT request. 3910 The "collation" attribute is used to select the collation that the 3911 server MUST use for character string matching. In the absence of 3912 this attribute the server MUST use the "i;ascii-casemap" 3913 collation. 3915 The "negate-condition" attribute is used to indicate that this 3916 test returns a match if the text matches, when the attribute value 3917 is set to "no", or return a match if the text does not match, if 3918 the attribute value is set to "yes". For example, this can be 3919 used to match components with a STATUS property not set to 3920 CANCELLED. 3922 Definition: 3924 3925 PCDATA value: string 3927 3930 9.8. CALDAV:timezone XML Element 3932 Name: timezone 3934 Namespace: urn:ietf:params:xml:ns:caldav 3936 Purpose: Specifies the time zone component to use when determining 3937 the results of a report. 3939 Description: The CALDAV:timezone XML element specifies that for a 3940 given calendaring REPORT request the server MUST rely on the 3941 specified VTIMEZONE component instead of the CALDAV:calendar- 3942 timezone property of the calendar collection in which the calendar 3943 object resource is contained to resolve "date" values and "date 3944 with local time" values (i.e., floating time) to "date with UTC 3945 time" values. The server will require this information to 3946 determine if a calendar component scheduled with "date" values or 3947 "date with local time" values intersect a CALDAV:time-range 3948 specified in a CALDAV:calendar-query REPORT. 3950 Note: The iCalendar data embedded within the CALDAV:timezone XML 3951 element MUST follow the standard XML character data encoding 3952 rules, including use of <, >, & etc entity encoding or 3953 the use of a construct. In the later case the 3954 iCalendar data cannot contain the character sequence "]]>" which 3955 is the end delimiter for the CDATA section. 3957 Definition: 3959 3960 PCDATA value: an iCalendar object with exactly one VTIMEZONE 3962 9.9. CALDAV:time-range XML Element 3964 Name: time-range 3966 Namespace: urn:ietf:params:xml:ns:caldav 3968 Purpose: Specifies a time range to limit the set of calendar 3969 components returned by the server. 3971 Description: The CALDAV:time-range XML element specifies that for a 3972 given calendaring REPORT request the server MUST only return the 3973 calendar object resources that, depending on the context, have a 3974 component or property whose value intersect a specified time 3975 range. The "start" attribute specifies the inclusive start of the 3976 time range, and the "end" attribute specifies the non-inclusive 3977 end of the time range. Both attributes MUST be specified as "date 3978 with UTC time" value. Time ranges open at one end can be 3979 specified by including only one attribute, however at least one 3980 attribute MUST always be present in the CALDAV:time-range element. 3981 If either the "start" or "end" attribute is not specified in the 3982 CALDAV:time-range XML element, assume "-infinity" and "+infinity" 3983 as their value respectively. If both "start" and "end" are 3984 present, the value of the "end" attribute MUST be greater than the 3985 value of the "start" attribute. 3987 Time range tests MUST consider every recurrence instance when 3988 testing the time range condition - if any one instance matches, 3989 then the test returns true. Testing recurrence instances requires 3990 the server to infer an effective value for DTSTART, DTEND, 3991 DURATION and DUE properties for an instance based on the 3992 recurrence patterns and any overrides. 3994 A VEVENT component overlaps a given time range if the condition 3995 for the corresponding component state specified in the table below 3996 is satisfied. Note that as specified in [RFC2445] the DTSTART 3997 property is REQUIRED in the VEVENT component. The conditions 3998 depend on the presence of the DTEND and DURATION properties in the 3999 VEVENT component. Furthermore, the value of the DTEND property 4000 MUST be later in time than the value of the DTSTART property. The 4001 duration of a VEVENT component with no DTEND and DURATION 4002 properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0 4003 seconds when the DTSTART is a DATE-TIME value. 4005 +---------------------------------------------------------------+ 4006 | VEVENT has the DTEND property? | 4007 | +-----------------------------------------------------------+ 4008 | | VEVENT has the DURATION property? | 4009 | | +-------------------------------------------------------+ 4010 | | | DURATION property value is greater than 0 seconds? | 4011 | | | +---------------------------------------------------+ 4012 | | | | DTSTART property is a DATE-TIME value | 4013 | | | | +-----------------------------------------------+ 4014 | | | | | Condition to evaluate | 4015 +---+---+---+---+-----------------------------------------------+ 4016 | Y | N | N | * | (start < DTEND AND end > DTSTART) | 4017 +---+---+---+---+-----------------------------------------------+ 4018 | N | Y | Y | * | (start < DTSTART+DURATION AND end > DTSTART) | 4019 | | +---+---+-----------------------------------------------+ 4020 | | | N | * | (start <= DTSTART AND end > DTSTART) | 4021 +---+---+---+---+-----------------------------------------------+ 4022 | N | N | N | Y | (start <= DTSTART AND end > DTSTART) | 4023 +---+---+---+---+-----------------------------------------------+ 4024 | N | N | N | N | (start < DTSTART+P1D AND end > DTSTART) | 4025 +---+---+---+---+-----------------------------------------------+ 4027 A VTODO component is said to overlap a given time range if the 4028 condition for the corresponding component state specified in the 4029 table below is satisfied. The conditions depend on the presence 4030 of the DTSTART, DURATION, DUE, COMPLETED and CREATED properties in 4031 the VTODO component. Note that as specified in [RFC2445] the DUE 4032 value MUST be a DATE-TIME value equal to or after the DTSTART 4033 value, if specified. 4035 +-------------------------------------------------------------------+ 4036 | VTODO has the DTSTART property? | 4037 | +---------------------------------------------------------------+ 4038 | | VTODO has the DURATION property? | 4039 | | +-----------------------------------------------------------+ 4040 | | | VTODO has the DUE property? | 4041 | | | +-------------------------------------------------------+ 4042 | | | | VTODO has the COMPLETED property? | 4043 | | | | +---------------------------------------------------+ 4044 | | | | | VTODO has the CREATED property? | 4045 | | | | | +-----------------------------------------------+ 4046 | | | | | | Condition to evaluate | 4047 +---+---+---+---+---+-----------------------------------------------+ 4048 | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND | 4049 | | | | | | ((end > DTSTART) OR | 4050 | | | | | | (end >= DTSTART+DURATION)) | 4051 +---+---+---+---+---+-----------------------------------------------+ 4052 | Y | N | Y | * | * | ((start < DUE) OR (start <= DTSTART)) | 4053 | | | | | | AND | 4054 | | | | | | ((end > DTSTART) OR (end >= DUE)) | 4055 +---+---+---+---+---+-----------------------------------------------+ 4056 | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) | 4057 +---+---+---+---+---+-----------------------------------------------+ 4058 | N | N | Y | * | * | (start < DUE) AND (end >= DUE) | 4059 +---+---+---+---+---+-----------------------------------------------+ 4060 | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))| 4061 | | | | | | AND | 4062 | | | | | | ((end >= CREATED) OR (end >= COMPLETED))| 4063 +---+---+---+---+---+-----------------------------------------------+ 4064 | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) | 4065 +---+---+---+---+---+-----------------------------------------------+ 4066 | N | N | N | N | Y | (end > CREATED) | 4067 +---+---+---+---+---+-----------------------------------------------+ 4068 | N | N | N | N | N | TRUE | 4069 +---+---+---+---+---+-----------------------------------------------+ 4071 A VJOURNAL component overlaps a given time range if the condition 4072 for the corresponding component state specified in the table below 4073 is satisfied. The conditions depend on the presence of the 4074 DTSTART property in the VJOURNAL component and on whether the 4075 DTSTART is a DATE-TIME or DATE value. The effective "duration" of 4076 a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE 4077 value, and 0 seconds when the DTSTART is a DATE-TIME value. 4079 +----------------------------------------------------+ 4080 | VJOURNAL has the DTSTART property? | 4081 | +------------------------------------------------+ 4082 | | DTSTART property is a DATE-TIME value | 4083 | | +--------------------------------------------+ 4084 | | | Condition to evaluate | 4085 +---+---+--------------------------------------------+ 4086 | Y | Y | (start <= DTSTART) AND (end > DTSTART) | 4087 +---+---+--------------------------------------------+ 4088 | Y | N | (start < DTSTART+P1D) AND (end > DTSTART) | 4089 +---+---+--------------------------------------------+ 4090 | N | * | FALSE | 4091 +---+---+--------------------------------------------+ 4093 A VFREEBUSY component overlaps a given time range if the condition 4094 for the corresponding component state specified in the table below 4095 is satisfied. The conditions depend on the presence in the 4096 VFREEBUSY component of the DTSTART and DTEND properties and any 4097 FREEBUSY properties in the absence of DTSTART and DTEND. Any 4098 DURATION property is ignored as it has a special meaning when used 4099 in a VFREEBUSY component. 4101 When only FREEBUSY properties are used, each period in each 4102 FREEBUSY property is compared against the time range, irrespective 4103 of the type of free busy information (free, busy, busy-tentative, 4104 busy-unavailable) represented by the property. 4106 +------------------------------------------------------+ 4107 | VFREEBUSY has both the DTSTART and DTEND properties? | 4108 | +--------------------------------------------------+ 4109 | | VFREEBUSY has the FREEBUSY property? | 4110 | | +----------------------------------------------+ 4111 | | | Condition to evaluate | 4112 +---+---+----------------------------------------------+ 4113 | Y | * | (start <= DTEND) AND (end > DTSTART) | 4114 +---+---+----------------------------------------------+ 4115 | N | Y | (start < freebusy-period-end) AND | 4116 | | | (end > freebusy-period-start) | 4117 +---+---+----------------------------------------------+ 4118 | N | N | FALSE | 4119 +---+---+----------------------------------------------+ 4120 A VALARM component is said to overlap a given time range if the 4121 following condition holds: 4123 (start <= trigger-time) AND (end > trigger-time) 4125 A VALARM component can be defined such that it triggers 4126 repeatedly. Such a VALARM component is said to overlap a given 4127 time range if at least one of its triggers overlaps the time 4128 range. 4130 The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP, 4131 DTSTART, DUE and LAST-MODIFIED overlap a given time range if the 4132 following condition holds: 4134 (start <= date-time) AND (end > date-time) 4136 Note that if DTEND is not present in a VEVENT, but DURATION is, 4137 then the test should instead operate on the 'effective' DTEND, 4138 i.e. DTSTART+DURATION. Similarly, if DUE is not present in a 4139 VTODO, but DTSTART and DURATION are, then the test should instead 4140 operate on the 'effective' DUE, i.e. DTSTART+DURATION. 4142 The semantic of CALDAV:time-range is not defined for any other 4143 calendar properties. 4145 Definition: 4147 4149 4151 start value: an iCalendar "date with UTC time" 4152 end value: an iCalendar "date with UTC time" 4154 9.10. CALDAV:calendar-multiget XML Element 4156 Name: calendar-multiget 4158 Namespace: urn:ietf:params:xml:ns:caldav 4160 Purpose: CalDAV REPORT used to retrieve specific calendar object 4161 resources. 4163 Description: See Section 7.9. 4165 Definition: 4167 4171 9.11. CALDAV:free-busy-query XML Element 4173 Name: free-busy-query 4175 Namespace: urn:ietf:params:xml:ns:caldav 4177 Purpose: CalDAV REPORT used to generate a VFREEBUSY to determine busy 4178 time over a specific time range. 4180 Description: See Section 7.10. 4182 Definition: 4184 4186 10. Internationalization Considerations 4188 CalDAV allows internationalized strings to be stored and retrieved 4189 for the description of calendar collections (see Section 5.2.1). 4191 The CALDAV:calendar-query report (Section 7.8) includes a text 4192 searching option controlled by the CALDAV:text-match element and 4193 details of character handling are covered in the description of that 4194 element (see Section 9.7.5). 4196 11. Security Considerations 4198 HTTP protocol transactions are sent in the clear over the network 4199 unless protection from snooping is negotiated. This can be 4200 accomplished by use of TLS as defined in [RFC2818]. In particular, 4201 HTTP Basic authentication MUST NOT be used unless TLS is in effect. 4203 Servers MUST take adequate precautions to ensure malicious clients 4204 cannot consume excessive server resources (CPU, memory, disk, etc.) 4205 through carefully crafted reports. For example, a client could 4206 upload an event with a recurrence rule that specifies a recurring 4207 event occurring every second for the next 100 years which would 4208 result in approximately 3 x 10^9 instances! A REPORT that asks for 4209 recurrences to be expanded over that range would likely constitute a 4210 denial-of-service attack on the server. 4212 When creating new resources (including calendar collections), clients 4213 MUST ensure that the resource name (the last path segment of the 4214 resource URI) assigned to the new resource does not expose any data 4215 from within the iCalendar resource itself and information about the 4216 nature of a calendar collection. This is required to ensure that the 4217 presence of a specific iCalendar component or nature of components in 4218 a collection cannot be inferred based on the name of a resource. 4220 When rolling up free-busy information, more information about a 4221 user's events is exposed if busy periods overlap or are adjacent 4222 (this tells the client requesting the free-busy information that the 4223 calendar owner has at least two events, rather than knowing only that 4224 the calendar owner has one or more events during the busy period). 4225 Thus, a conservative approach to calendar data privacy would have 4226 servers always coalesce such busy periods when they are the same 4227 type. 4229 Procedure alarms are a known security risk for either clients or 4230 servers to handle, particularly when the alarm was created by another 4231 agent. Clients and servers are not required to execute such 4232 procedure alarms. 4234 Security considerations described in iCalendar [RFC2445] and iTIP 4235 [RFC2446] are also applicable to CalDAV. 4237 Beyond these, CalDAV does not raise any security considerations that 4238 are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253], 4239 [RFC3744], as discussed in those documents. 4241 12. IANA Consideration 4243 This document uses one new URN to identify a new XML namespace. The 4244 URN conforms to a registry mechanism described in [RFC3688]. 4246 12.1. Namespace Registration 4248 Registration request for the CalDAV namespace: 4250 URI: urn:ietf:params:xml:ns:caldav 4252 Registrant Contact: See the "Author's Address" section of this 4253 document. 4255 XML: None. Namespace URIs do not represent an XML specification. 4257 13. Acknowledgements 4259 The authors would like to thank the following individuals for 4260 contributing their ideas and support for writing this specification: 4261 Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Mike Douglass, 4262 Ted Hardie, Sam Hartman, Helge Hess, Jeff McCullough, Alexey 4263 Melnikov, Dan Mosedale, Brian Moseley, Kervin L. Pierre, Julian F. 4264 Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon 4265 Vaillancourt, Jim Whitehead. 4267 The authors would also like to thank the Calendaring and Scheduling 4268 Consortium for advice with this specification, and for organizing 4269 interoperability testing events to help refine it. 4271 14. References 4273 14.1. Normative References 4275 [I-D.newman-i18n-comparator] 4276 Newman, C., "Internet Application Protocol Collation 4277 Registry", draft-newman-i18n-comparator-13 (work in 4278 progress), August 2006. 4280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4281 Requirement Levels", BCP 14, RFC 2119, March 1997. 4283 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 4284 RFC 2246, January 1999. 4286 [RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and 4287 Scheduling Core Object Specification (iCalendar)", 4288 RFC 2445, November 1998. 4290 [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, 4291 "iCalendar Transport-Independent Interoperability Protocol 4292 (iTIP) Scheduling Events, BusyTime, To-dos and Journal 4293 Entries", RFC 2446, November 1998. 4295 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 4296 Jensen, "HTTP Extensions for Distributed Authoring -- 4297 WEBDAV", RFC 2518, February 1999. 4299 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 4300 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 4301 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 4303 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 4305 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. 4306 Whitehead, "Versioning Extensions to WebDAV (Web 4307 Distributed Authoring and Versioning)", RFC 3253, 4308 March 2002. 4310 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4311 January 2004. 4313 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web 4314 Distributed Authoring and Versioning (WebDAV) Access 4315 Control Protocol", RFC 3744, May 2004. 4317 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 4318 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 4320 [W3C.REC-xml-20060816] 4321 Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., 4322 and E. Maler, "Extensible Markup Language (XML) 1.0 4323 (Fourth Edition)", World Wide Web Consortium 4324 Recommendation REC-xml-20060816, August 2006, 4325 . 4327 14.2. Informative References 4329 [I-D.ietf-webdav-rfc2518bis] 4330 Dusseault, L., "HTTP Extensions for Distributed Authoring 4331 - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in 4332 progress), May 2006. 4334 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 4335 RFC 2426, September 1998. 4337 [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar 4338 Attributes for vCard and LDAP", RFC 2739, January 2000. 4340 [RFC4331] Korver, B. and L. Dusseault, "Quota and Size Properties 4341 for Distributed Authoring and Versioning (DAV) 4342 Collections", RFC 4331, February 2006. 4344 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 4345 (LDAP): The Protocol", RFC 4511, June 2006. 4347 Appendix A. CalDAV Method Privilege Table (Normative) 4349 The following table extends the WebDAV Method Privilege Table 4350 specified in Appendix B of [RFC3744]. 4352 +------------+------------------------------------------------------+ 4353 | METHOD | PRIVILEGES | 4354 +------------+------------------------------------------------------+ 4355 | MKCALENDAR | DAV:bind | 4356 | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced | 4357 | | resources) | 4358 +------------+------------------------------------------------------+ 4360 Appendix B. Calendar collections used in the examples 4362 This appendix shows the calendar object resources contained in the 4363 calendar collection queried in the examples throughout this document. 4365 The content of the calendar collection is being shown as it would be 4366 returned by a CALDAV:calendar-query REPORT request designed to return 4367 all the calendar data in the collection: 4369 >> Request << 4371 REPORT /bernard/work/ HTTP/1.1 4372 Host: cal.example.com 4373 Depth: 1 4374 Content-Type: application/xml; charset="utf-8" 4375 Content-Length: xxxx 4377 4378 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4392 >> Response << 4394 HTTP/1.1 207 Multi-Status 4395 Content-Type: application/xml; charset="utf-8" 4396 Content-Length: xxxx 4398 4399 4402 4403 http://cal.example.com/bernard/work/abcd1.ics 4404 4405 4406 "fffff-abcd1" 4407 BEGIN:VCALENDAR 4408 VERSION:2.0 4409 PRODID:-//Example Corp.//CalDAV Client//EN 4410 BEGIN:VTIMEZONE 4411 LAST-MODIFIED:20040110T032845Z 4412 TZID:US/Eastern 4413 BEGIN:DAYLIGHT 4414 DTSTART:20000404T020000 4415 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 4416 TZNAME:EDT 4417 TZOFFSETFROM:-0500 4418 TZOFFSETTO:-0400 4419 END:DAYLIGHT 4420 BEGIN:STANDARD 4421 DTSTART:20001026T020000 4422 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 4423 TZNAME:EST 4424 TZOFFSETFROM:-0400 4425 TZOFFSETTO:-0500 4426 END:STANDARD 4427 END:VTIMEZONE 4428 BEGIN:VEVENT 4429 DTSTAMP:20060206T001102Z 4430 DTSTART;TZID=US/Eastern:20060102T100000 4431 DURATION:PT1H 4432 SUMMARY:Event #1 4433 Description:Go Steelers! 4434 UID:74855313FA803DA593CD579A@example.com 4435 END:VEVENT 4436 END:VCALENDAR 4437 4438 4439 HTTP/1.1 200 OK 4440 4441 4443 4444 http://cal.example.com/bernard/work/abcd2.ics 4445 4446 4447 "fffff-abcd2" 4448 BEGIN:VCALENDAR 4449 VERSION:2.0 4450 PRODID:-//Example Corp.//CalDAV Client//EN 4451 BEGIN:VTIMEZONE 4452 LAST-MODIFIED:20040110T032845Z 4453 TZID:US/Eastern 4454 BEGIN:DAYLIGHT 4455 DTSTART:20000404T020000 4456 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 4457 TZNAME:EDT 4458 TZOFFSETFROM:-0500 4459 TZOFFSETTO:-0400 4460 END:DAYLIGHT 4461 BEGIN:STANDARD 4462 DTSTART:20001026T020000 4463 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 4464 TZNAME:EST 4465 TZOFFSETFROM:-0400 4466 TZOFFSETTO:-0500 4467 END:STANDARD 4468 END:VTIMEZONE 4469 BEGIN:VEVENT 4470 DTSTAMP:20060206T001121Z 4471 DTSTART;TZID=US/Eastern:20060102T120000 4472 DURATION:PT1H 4473 RRULE:FREQ=DAILY;COUNT=5 4474 SUMMARY:Event #2 4475 UID:00959BC664CA650E933C892C@example.com 4476 END:VEVENT 4477 BEGIN:VEVENT 4478 DTSTAMP:20060206T001121Z 4479 DTSTART;TZID=US/Eastern:20060104T140000 4480 DURATION:PT1H 4481 RECURRENCE-ID;TZID=US/Eastern:20060104T120000 4482 SUMMARY:Event #2 bis 4483 UID:00959BC664CA650E933C892C@example.com 4484 END:VEVENT 4485 END:VCALENDAR 4486 4487 4488 HTTP/1.1 200 OK 4489 4490 4492 4493 http://cal.example.com/bernard/work/abcd3.ics 4494 4495 4496 "fffff-abcd3" 4497 BEGIN:VCALENDAR 4498 VERSION:2.0 4499 PRODID:-//Example Corp.//CalDAV Client//EN 4500 BEGIN:VTIMEZONE 4501 LAST-MODIFIED:20040110T032845Z 4502 TZID:US/Eastern 4503 BEGIN:DAYLIGHT 4504 DTSTART:20000404T020000 4505 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 4506 TZNAME:EDT 4507 TZOFFSETFROM:-0500 4508 TZOFFSETTO:-0400 4509 END:DAYLIGHT 4510 BEGIN:STANDARD 4511 DTSTART:20001026T020000 4512 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 4513 TZNAME:EST 4514 TZOFFSETFROM:-0400 4515 TZOFFSETTO:-0500 4516 END:STANDARD 4517 END:VTIMEZONE 4518 BEGIN:VEVENT 4519 ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com 4520 ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com 4521 DTSTAMP:20060206T001220Z 4522 DTSTART;TZID=US/Eastern:20060104T100000 4523 DURATION:PT1H 4524 LAST-MODIFIED:20060206T001330Z 4525 ORGANIZER:mailto:cyrus@example.com 4526 SEQUENCE:1 4527 STATUS:TENTATIVE 4528 SUMMARY:Event #3 4529 UID:DC6C50A017428C5216A2F1CD@example.com 4530 END:VEVENT 4531 END:VCALENDAR 4532 4533 4534 HTTP/1.1 200 OK 4535 4536 4538 4539 http://cal.example.com/bernard/work/abcd4.ics 4540 4541 4542 "fffff-abcd4" 4543 BEGIN:VCALENDAR 4544 VERSION:2.0 4545 PRODID:-//Example Corp.//CalDAV Client//EN 4546 BEGIN:VTODO 4547 DTSTAMP:20060205T235335Z 4548 DUE;VALUE=DATE:20060104 4549 STATUS:NEEDS-ACTION 4550 SUMMARY:Task #1 4551 UID:DDDEEB7915FA61233B861457@example.com 4552 BEGIN:VALARM 4553 ACTION:AUDIO 4554 TRIGGER;RELATED=START:-PT10M 4555 END:VALARM 4556 END:VTODO 4557 END:VCALENDAR 4558 4559 4560 HTTP/1.1 200 OK 4561 4562 4564 4565 http://cal.example.com/bernard/work/abcd5.ics 4566 4567 4568 "fffff-abcd5" 4569 BEGIN:VCALENDAR 4570 VERSION:2.0 4571 PRODID:-//Example Corp.//CalDAV Client//EN 4572 BEGIN:VTODO 4573 DTSTAMP:20060205T235300Z 4574 DUE;VALUE=DATE:20060106 4575 LAST-MODIFIED:20060205T235308Z 4576 SEQUENCE:1 4577 STATUS:NEEDS-ACTION 4578 SUMMARY:Task #2 4579 UID:E10BA47467C5C69BB74E8720@example.com 4580 BEGIN:VALARM 4581 ACTION:AUDIO 4582 TRIGGER;RELATED=START:-PT10M 4583 END:VALARM 4584 END:VTODO 4585 END:VCALENDAR 4586 4587 4588 HTTP/1.1 200 OK 4589 4590 4591 4592 http://cal.example.com/bernard/work/abcd6.ics 4593 4594 4595 "fffff-abcd6" 4596 BEGIN:VCALENDAR 4597 VERSION:2.0 4598 PRODID:-//Example Corp.//CalDAV Client//EN 4599 BEGIN:VTODO 4600 COMPLETED:20051223T122322Z 4601 DTSTAMP:20060205T235400Z 4602 DUE;VALUE=DATE:20051225 4603 LAST-MODIFIED:20060205T235308Z 4604 SEQUENCE:1 4605 STATUS:COMPLETED 4606 SUMMARY:Task #3 4607 UID:E10BA47467C5C69BB74E8722@example.com 4608 END:VTODO 4609 END:VCALENDAR 4610 4611 4612 HTTP/1.1 200 OK 4613 4614 4616 4617 http://cal.example.com/bernard/work/abcd7.ics 4618 4619 4620 "fffff-abcd7" 4621 BEGIN:VCALENDAR 4622 VERSION:2.0 4623 PRODID:-//Example Corp.//CalDAV Client//EN 4624 BEGIN:VTODO 4625 DTSTAMP:20060205T235600Z 4626 DUE;VALUE=DATE:20060101 4627 LAST-MODIFIED:20060205T235308Z 4628 SEQUENCE:1 4629 STATUS:CANCELLED 4630 SUMMARY:Task #4 4631 UID:E10BA47467C5C69BB74E8725@example.com 4632 END:VTODO 4633 END:VCALENDAR 4634 4635 4636 HTTP/1.1 200 OK 4637 4638 4639 4640 http://cal.example.com/bernard/work/abcd8.ics 4641 4642 4643 "fffff-abcd8" 4644 BEGIN:VCALENDAR 4645 VERSION:2.0 4646 PRODID:-//Example Corp.//CalDAV Client//EN 4647 BEGIN:VFREEBUSY 4648 ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com 4649 UID:76ef34-54a3d2@example.com 4650 DTSTAMP:20050530T123421Z 4651 DTSTART:20060101T000000Z 4652 DTEND:20060108T000000Z 4653 FREEBUSY:20050531T230000Z/20050601T010000Z 4654 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z 4655 FREEBUSY:20060103T100000Z/20060103T120000Z 4656 FREEBUSY:20060104T100000Z/20060104T120000Z 4657 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z 4658 FREEBUSY:20060106T100000Z/20060106T120000Z 4659 END:VFREEBUSY 4660 END:VCALENDAR 4661 4662 4663 HTTP/1.1 200 OK 4664 4665 4667 4669 Appendix C. Changes (to be removed prior to publication as an RFC) 4671 C.1. Changes in -15 4673 a. Switched to using collations for text-match element in calendar- 4674 query report. 4676 b. Removed caseless attribute from text-match element. 4678 c. Removed UNICODE4 reference. 4680 d. Removed mailing list comment. 4682 e. Made calendar-home-set property a SHOULD as it was in previous 4683 drafts. 4685 f. Now require https download of external attachments. 4687 g. Changed some improper uses of 2119 terms to lowercase. 4689 h. Updated some references to latest specs. 4691 C.2. Changes in -14 4693 a. Reverted to normative reference to 2518 and added informative 4694 reference to 2518bis. 4696 b. Reinserted section describing preconditions/postconditions. 4698 c. Removed redundant compliance statement in last paragraph of 4699 Section 3. 4701 d. Clarify that only text/calendar is allowed if supported-calendar- 4702 data property is not present. 4704 e. Removed redundant compliance statement in Conformance paragraph 4705 of Section 6.2.1. 4707 f. Removed redundant compliance statement in first paragraph of 4708 Section 7.5. 4710 g. Fixed incorrect whitespace in elements in example in Section 4711 7.7.6. 4713 h. Fixed incorrect CDATA descriptions in various places. 4715 C.3. Changes in -13 4717 a. Changed mailing list draft description. 4719 b. Added security review suggested text to Security Considerations. 4721 c. Changed external attachment support to require http URI 4722 downloads, and optionally others. 4724 d. Added reference to text-match element in Internationalization 4725 Considerations section. 4727 e. Changed 'undefined' to 'not specified here' in ETag behavior 4728 section. 4730 f. Added reference to RFC4346 with note that it obsoletes RFC2246 4732 C.4. Changes in -12 4734 a. Changed requirements for ETags on PUT to better reflect the needs 4735 of CalDAV clients wrt synchronization and reflect what other 4736 standards define or do not define. 4738 b. Changed CALDAV:read-free-busy privilege so that it is also 4739 defined on regular collections. 4741 C.5. Changes in -11 4743 a. Added statement that calendar-query Depth defaults to zero if 4744 header is not present. Fixed one multiget example's Depth 4745 header. 4747 b. Fixed reference to WebDAV Quota RFC. 4749 c. Changed DAV:resource to DAV:href in CALDAV:no-uid-conflict 4750 element. 4752 d. Added CALDAV:calendar-collection-location-ok pre-condition for 4753 COPY and MOVE. 4755 e. Added CALDAV:max-resource-size, CALDAV:min-date-time, CALDAV:max- 4756 date-time, CALDAV:max-instances, CALDAV:max-attendees-per- 4757 instance properties and preconditions. 4759 f. Changed to 2518bis reference. 4761 g. Now require 2518bis Class 3 behaviour. 4763 h. Fixed indentation in examples and removed bogus whitespace before 4764 tags. 4766 i. Fixed typo. 4768 j. Added text to element definition as a reminder 4769 about the need to do XML character data encoding on any iCalendar 4770 data within that element. 4772 k. Major reworking of CALDAV:time-range element description to 4773 better cover all possibilities for each type of component based 4774 on which properties are present. 4776 l. Added is-not-defined and negate-condition options to reports and 4777 a new example to illustrate use of those. 4779 m. Fixed descriptions of some calendar collection properties. 4781 n. Removed section describing preconditions/postconditions as this 4782 is incorporated into 2518bis. 4784 o. Clarified issue about separate component types in separate 4785 resources. 4787 p. Reworded section on servers being allowed to reject changes to 4788 their own private use iCal values. 4790 q. Clarified overridden component 'current' and 'original' time 4791 range overlap. 4793 r. Added more section references for XML element definitions. 4795 s. Reworded limit-recurrence-set definition to try and make it clear 4796 that mast component is always returned, but only some overridden 4797 one are returned. 4799 t. Clarified dependence on UNICODE reference for caseless matching. 4801 C.6. Changes in -10 4803 a. Added new section about support for X- items when storing data. 4805 b. Added new precondition to allow servers to reject queries on 4806 unsupported X- items, and a new example. 4808 c. Added new text about always supporting X- in calendar-data. 4810 d. Created new section for PUT, COPY and MOVE preconditions. 4812 e. Report examples re-done with full listing of calendar data in 4813 Appendix. 4815 f. Removed description of using UID, SUMMARY etc as resource name. 4817 g. Indicate that calendar object resource may contain only 4818 overridden components. 4820 h. Add security consideration about not expose details in resource 4821 names. 4823 i. Add constraint that free-busy-query can only be run on a 4824 collection. 4826 j. Add preconditions for calendar-timezone property/elements in 4827 MKCALENDAR, PROPPATCH and calendar-query REPORT. 4829 k. Fix principal-match example. 4831 C.7. Changes in -09 4833 a. Numerous editorial changes. 4835 b. Removed the CALDAV:is-defined XML element. 4837 c. Removed section on privilege aggregation. 4839 d. Renamed the CALDAV:expand-recurrence-set XML element to CALDAV: 4840 expand and clarified the server behavior. 4842 e. Renamed the CALDAV:calendar-component-restriction-set XML 4843 element to CALDAV:supported-calendar-component-set. 4845 f. Renamed the CALDAV:calendar-restrictions XML element to CALDAV: 4846 supported-calendar-data. 4848 g. Renamed some preconditions as "success conditions" instead of 4849 "failure causes". For instance, the precondition CALDAV: 4850 calendar-collection-location-bad has been renamed to CALDAV: 4851 calendar-collection-location-ok. 4853 h. Reordered some sections. 4855 i. Clarified the definition of CALDAV:time-range to specify that a 4856 repeating VALARM component is said to intersect a given time 4857 range if at least one of its trigger intersect the time range. 4859 j. Clarified that calendar object resources stored in calendar 4860 collections MUST NOT specify the iCalendar METHOD property. 4862 k. Clarified that CALDAV:calendar-data XML element is not a WebDAV 4863 property even though it is specified in the DAV:prop XML element 4864 in both calendaring REPORT requests and responses. 4866 l. Clarified CALDAV:limit-recurrence-set with respect to the RANGE 4867 parameter on the RECURRENCE-ID property. 4869 m. Changed the CALDAV:free-busy-query XML element to contain 4870 exactly one CALDAV:time-range XML element. 4872 n. Changed many ELEMENT and ATTLIST declarations to comply with DTD 4873 syntax. 4875 o. Changed XML element CALDAV:calendar-query to allow new XML 4876 element CALDAV:timezone. 4878 p. Changed the XML elements CALDAV:time-range, CALDAV:expand and 4879 CALDAV:limit-recurrence-set to only allow DATE-TIME with UTC 4880 time values for the "start" and "end" attributes. 4882 q. Changed description of CALDAV:limit-recurrence-set to specify 4883 that re-scheduled "overridden" recurrence instances whose 4884 original scheduled time used to overlap the time range specified 4885 by the "start" and "end" attribute should always be returned in 4886 a REPORT response. 4888 r. Changed the description of the value of CALDAV:calendar-data XML 4889 element to specify that the CR character (US-ASCII decimal 13) 4890 MAY be omitted in the iCalendar object specified in this XML 4891 element. 4893 s. Added specific requirements for entity tags support. 4895 t. Added more preconditions. 4897 u. Added further guidelines about finding calendars. 4899 v. Added XML element CALDAV:limit-freebusy-set to limit the set of 4900 FREEBUSY property values returned in VFREEBUSY components. 4902 w. Added property CALDAV:calendar-timezone on calendar collections. 4904 x. Added XML element CALDAV:timezone to override the CALDAV: 4905 calendar-timezone property for a given CALDAV:calendar-query 4906 REPORT request. 4908 y. Added text on the conversion of "floating date" and "floating 4909 time" values to date with UTC time values. 4911 z. Completed internationalization considerations section. 4913 aa. Completed security considerations section. 4915 C.8. Changes in -08 4917 a. Removed statement that said that client SHOULD always request 4918 DAV:getetag in calendar REPORTs. 4920 b. Removed redefiniton of DAV:response. 4922 c. Removed XML elements CALDAV:calendar-data-only. 4924 d. Removed resource type CALDAV:calendar-home. 4926 e. Moved the CALDAV:calendar-data element in the DAV:prop element in 4927 requests, and in the DAV:propstat element in responses. 4929 f. Further defined the request body of MKCALENDAR to allow clients 4930 to set properties at calendar collection creation time. 4932 g. Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set 4934 h. Clarified the fact that calendar collections may only contain 4935 calendar object resources and ordinary collections. 4937 i. Clarified that calendar REPORTs should only be applied to 4938 calendar object resources contained in calendar collections. 4940 j. Changed the CALDAV:calendar-component-restriction-set and CALDAV: 4941 calendar-restriction properties to always be protected. 4943 k. Changed to use existing postcondition DAV:needs-privileges 4944 instead of a new CALDAV:insufficient-privilege postcondition. 4946 l. Added example for limit-recurrence-set. 4948 m. Added example for expand-recurrence-set. 4950 n. Moved CALDAV:calendar-address-set in the calendar-schedule draft 4951 and renamed it to CALDAV:calendar-user-address-set. 4953 o. Added guidelines on attachments and alarms. 4955 C.9. Changes in -07 4957 a. Various editorial changes. 4959 b. Added properties calendar-restrictions and calendar-component- 4960 restriction-set on calendar collections. 4962 c. Added properties calendar-home-URL and calendar-address-set on 4963 principal resources. 4965 d. Removed property calendar-URL on principal resources. 4967 e. Added pre- and postconditions to reports. 4969 f. Added new XML elements calendar-data-only and limit-recurrent- 4970 set. 4972 g. Modified calendar-data XML element to support the attributes 4973 content-type and version. 4975 h. Reorganised sections 3, 4, 5 & 6 into two sections and re-ordered 4976 sub-sections. 4978 i. Added comment about client not setting a duplicate displayname. 4980 j. Removed three CalDAV OPTIONS requests. 4982 k. Changed "authenticated user" to "user" in various places. 4984 l. Rewrote section on calendar object resource restrictions for 4985 better clarity. 4987 C.10. Changes in -06 4989 a. Reworded section "Recurrence and the Data Model". 4991 b. Removed timezone collection feature. 4993 c. Removed ability for a server to return the Location header on a 4994 successful PUT request. 4996 d. Clarified restrictions on calendar object resources contained in 4997 calendar collections. 4999 e. Added preconditions on PUT in calendar collections. 5001 f. Added informative "Guidelines" section, with information on 5002 locking and how to find calendar collections. 5004 g. Moved "Sychronization Operations" section in the "Guidelines" 5005 section. 5007 C.11. Changes in -05 5009 a. Removed a lot of non-normative text. 5011 b. Removed property promotion/demotion requirements. 5013 c. Removed calendar-owner and cal-scale properties. 5015 d. Removed 'ical' prefix/text from element names. 5017 e. Relaxed WebDAV Class 2 (locking) requirement to a MAY. 5019 f. Relaxed MKCALENDAR requirement to a SHOULD. 5021 g. Moved the XML Namespace section in the Introduction. 5023 h. Added CALDAV: prefix to CalDAV XML elements in the text. 5025 i. Added CALDAV:calendar-multiget report. 5027 j. Added CALDAV:free-busy-query report. 5029 k. Added CALDAV:calendar-description property. 5031 l. Changed CALDAV:calendar-query-result element name to CALDAV: 5032 calendar-data 5034 m. Added description and examples of handling timezones. 5036 n. Added mandatory "start" and "end" attributes to the CALDAV: 5037 expand-recurrence-set element. 5039 o. Added three CalDAV OPTIONS requests. 5041 p. Grouped XML Element declarations in a separate section. 5043 C.12. Changes in -04 5045 a. Added a note about the HTTP Location response header. 5047 b. Added report calendar-query. 5049 c. Removed reports calendar-property-search and calendar-time-range. 5051 d. Removed section on CalDAV and timezones. 5053 e. Added requirement to return ETag on creation. 5055 f. Revised data model to remove sub-collections from calendar 5056 collection. 5058 g. Added informative references section. 5060 h. Removed dependencies on DASL. 5062 C.13. Changes in -03 5064 a. Removed Calendar Containers (simplification that doesn't seem to 5065 remove much functionality) 5067 b. Added MKCALENDAR to create calendars and all sub-collections 5069 c. Added cal-scale property to calendars 5071 C.14. Changes in -02 5073 Basically still adding major sections of content: 5075 a. Defined new field values to the OPTIONS "DAV:" response header 5077 b. Added new resource properties 5079 c. Added new principal properties 5081 d. Added new SCHEDULE method and related headers 5083 e. Added new privileges for scheduling 5085 C.15. Changes in -01 5087 a. Added section on privileges for calendaring, extending WebDAV ACL 5088 privilege set 5090 b. Defined what to do with unrecognized properties in the bodies of 5091 iCalendar events, with respect to property promotion/demotion 5093 Authors' Addresses 5095 Cyrus Daboo 5096 Apple Computer, Inc. 5097 1 Infinite Loop 5098 Cupertino, CA 95014 5099 USA 5101 Email: cyrus@daboo.name 5102 URI: http://www.apple.com/ 5104 Bernard Desruisseaux 5105 Oracle Corporation 5106 600 Blvd. de Maisonneuve West 5107 Suite 1900 5108 Montreal, QC H3A 3J2 5109 CA 5111 Email: bernard.desruisseaux@oracle.com 5112 URI: http://www.oracle.com/ 5114 Lisa Dusseault 5115 Open Source Application Foundation 5116 2064 Edgewood Dr. 5117 Palo Alto, CA 94303 5118 US 5120 Email: lisa@osafoundation.org 5121 URI: http://www.osafoundation.org/ 5123 Intellectual Property Statement 5125 The IETF takes no position regarding the validity or scope of any 5126 Intellectual Property Rights or other rights that might be claimed to 5127 pertain to the implementation or use of the technology described in 5128 this document or the extent to which any license under such rights 5129 might or might not be available; nor does it represent that it has 5130 made any independent effort to identify any such rights. Information 5131 on the procedures with respect to rights in RFC documents can be 5132 found in BCP 78 and BCP 79. 5134 Copies of IPR disclosures made to the IETF Secretariat and any 5135 assurances of licenses to be made available, or the result of an 5136 attempt made to obtain a general license or permission for the use of 5137 such proprietary rights by implementers or users of this 5138 specification can be obtained from the IETF on-line IPR repository at 5139 http://www.ietf.org/ipr. 5141 The IETF invites any interested party to bring to its attention any 5142 copyrights, patents or patent applications, or other proprietary 5143 rights that may cover technology that may be required to implement 5144 this standard. Please address the information to the IETF at 5145 ietf-ipr@ietf.org. 5147 Disclaimer of Validity 5149 This document and the information contained herein are provided on an 5150 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5151 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5152 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5153 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5154 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5155 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5157 Copyright Statement 5159 Copyright (C) The Internet Society (2006). This document is subject 5160 to the rights, licenses and restrictions contained in BCP 78, and 5161 except as set forth therein, the authors retain all their rights. 5163 Acknowledgment 5165 Funding for the RFC Editor function is currently provided by the 5166 Internet Society.