aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc4791.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/rfc4791.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc4791.txt5995
1 files changed, 5995 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc4791.txt b/vendor/sabre/dav/docs/rfc4791.txt
new file mode 100644
index 000000000..7a30bb214
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc4791.txt
@@ -0,0 +1,5995 @@
+
+
+
+
+
+
+Network Working Group C. Daboo
+Request for Comments: 4791 Apple
+Category: Standards Track B. Desruisseaux
+ Oracle
+ L. Dusseault
+ CommerceNet
+ March 2007
+
+
+ Calendaring Extensions to WebDAV (CalDAV)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ This document defines extensions to the Web Distributed Authoring and
+ Versioning (WebDAV) protocol to specify a standard way of accessing,
+ managing, and sharing calendaring and scheduling information based on
+ the iCalendar format. This document defines the "calendar-access"
+ feature of CalDAV.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 1]
+
+RFC 4791 CalDAV March 2007
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
+ 1.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5
+ 1.3. Method Preconditions and Postconditions . . . . . . . . . 6
+ 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6
+ 3. Calendaring Data Model . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. Calendar Server . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. Recurrence and the Data Model . . . . . . . . . . . . . . 8
+ 4. Calendar Resources . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Calendar Object Resources . . . . . . . . . . . . . . . . 9
+ 4.2. Calendar Collection . . . . . . . . . . . . . . . . . . . 10
+ 5. Calendar Access Feature . . . . . . . . . . . . . . . . . . . 11
+ 5.1. Calendar Access Support . . . . . . . . . . . . . . . . . 11
+ 5.1.1. Example: Using OPTIONS for the Discovery of
+ Calendar Access Support . . . . . . . . . . . . . . . 12
+ 5.2. Calendar Collection Properties . . . . . . . . . . . . . . 12
+ 5.2.1. CALDAV:calendar-description Property . . . . . . . . . 12
+ 5.2.2. CALDAV:calendar-timezone Property . . . . . . . . . . 13
+ 5.2.3. CALDAV:supported-calendar-component-set Property . . . 14
+ 5.2.4. CALDAV:supported-calendar-data Property . . . . . . . 15
+ 5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 16
+ 5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 17
+ 5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 18
+ 5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 19
+ 5.2.9. CALDAV:max-attendees-per-instance Property . . . . . . 19
+ 5.2.10. Additional Precondition for PROPPATCH . . . . . . . . 20
+ 5.3. Creating Resources . . . . . . . . . . . . . . . . . . . . 20
+ 5.3.1. MKCALENDAR Method . . . . . . . . . . . . . . . . . . 20
+ 5.3.1.1. Status Codes . . . . . . . . . . . . . . . . . . . 22
+ 5.3.1.2. Example: Successful MKCALENDAR Request . . . . . . 23
+ 5.3.2. Creating Calendar Object Resources . . . . . . . . . . 25
+ 5.3.2.1. Additional Preconditions for PUT, COPY, and
+ MOVE . . . . . . . . . . . . . . . . . . . . . . . 26
+ 5.3.3. Non-Standard Components, Properties, and Parameters . 28
+ 5.3.4. Calendar Object Resource Entity Tag . . . . . . . . . 28
+ 6. Calendaring Access Control . . . . . . . . . . . . . . . . . . 29
+ 6.1. Calendaring Privilege . . . . . . . . . . . . . . . . . . 29
+ 6.1.1. CALDAV:read-free-busy Privilege . . . . . . . . . . . 29
+ 6.2. Additional Principal Property . . . . . . . . . . . . . . 30
+ 6.2.1. CALDAV:calendar-home-set Property . . . . . . . . . . 30
+ 7. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . 31
+ 7.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 31
+ 7.2. Ordinary Collections . . . . . . . . . . . . . . . . . . . 31
+ 7.3. Date and Floating Time . . . . . . . . . . . . . . . . . . 32
+ 7.4. Time Range Filtering . . . . . . . . . . . . . . . . . . . 32
+ 7.5. Searching Text: Collations . . . . . . . . . . . . . . . . 33
+
+
+
+Daboo, et al. Standards Track [Page 2]
+
+RFC 4791 CalDAV March 2007
+
+
+ 7.5.1. CALDAV:supported-collation-set Property . . . . . . . 34
+ 7.6. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 34
+ 7.7. Non-Standard Components, Properties, and Parameters . . . 35
+ 7.8. CALDAV:calendar-query REPORT . . . . . . . . . . . . . . . 36
+ 7.8.1. Example: Partial Retrieval of Events by Time Range . . 38
+ 7.8.2. Example: Partial Retrieval of Recurring Events . . . . 42
+ 7.8.3. Example: Expanded Retrieval of Recurring Events . . . 45
+ 7.8.4. Example: Partial Retrieval of Stored Free Busy
+ Components . . . . . . . . . . . . . . . . . . . . . . 48
+ 7.8.5. Example: Retrieval of To-Dos by Alarm Time Range . . . 50
+ 7.8.6. Example: Retrieval of Event by UID . . . . . . . . . . 51
+ 7.8.7. Example: Retrieval of Events by PARTSTAT . . . . . . . 53
+ 7.8.8. Example: Retrieval of Events Only . . . . . . . . . . 55
+ 7.8.9. Example: Retrieval of All Pending To-Dos . . . . . . . 59
+ 7.8.10. Example: Attempt to Query Unsupported Property . . . . 62
+ 7.9. CALDAV:calendar-multiget REPORT . . . . . . . . . . . . . 63
+ 7.9.1. Example: Successful CALDAV:calendar-multiget REPORT . 64
+ 7.10. CALDAV:free-busy-query REPORT . . . . . . . . . . . . . . 66
+ 7.10.1. Example: Successful CALDAV:free-busy-query REPORT . . 68
+ 8. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 69
+ 8.1. Client-to-Client Interoperability . . . . . . . . . . . . 69
+ 8.2. Synchronization Operations . . . . . . . . . . . . . . . . 69
+ 8.2.1. Use of Reports . . . . . . . . . . . . . . . . . . . . 69
+ 8.2.1.1. Restrict the Time Range . . . . . . . . . . . . . 69
+ 8.2.1.2. Synchronize by Time Range . . . . . . . . . . . . 70
+ 8.2.1.3. Synchronization Process . . . . . . . . . . . . . 70
+ 8.2.2. Restrict the Properties Returned . . . . . . . . . . . 72
+ 8.3. Use of Locking . . . . . . . . . . . . . . . . . . . . . . 72
+ 8.4. Finding Calendars . . . . . . . . . . . . . . . . . . . . 72
+ 8.5. Storing and Using Attachments . . . . . . . . . . . . . . 74
+ 8.5.1. Inline Attachments . . . . . . . . . . . . . . . . . . 74
+ 8.5.2. External Attachments . . . . . . . . . . . . . . . . . 75
+ 8.6. Storing and Using Alarms . . . . . . . . . . . . . . . . . 76
+ 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 77
+ 9.1. CALDAV:calendar XML Element . . . . . . . . . . . . . . . 77
+ 9.2. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . 77
+ 9.3. CALDAV:mkcalendar-response XML Element . . . . . . . . . . 78
+ 9.4. CALDAV:supported-collation XML Element . . . . . . . . . . 78
+ 9.5. CALDAV:calendar-query XML Element . . . . . . . . . . . . 78
+ 9.6. CALDAV:calendar-data XML Element . . . . . . . . . . . . . 79
+ 9.6.1. CALDAV:comp XML Element . . . . . . . . . . . . . . . 80
+ 9.6.2. CALDAV:allcomp XML Element . . . . . . . . . . . . . . 81
+ 9.6.3. CALDAV:allprop XML Element . . . . . . . . . . . . . . 81
+ 9.6.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 82
+ 9.6.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 82
+ 9.6.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 83
+ 9.6.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 84
+ 9.7. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 85
+
+
+
+Daboo, et al. Standards Track [Page 3]
+
+RFC 4791 CalDAV March 2007
+
+
+ 9.7.1. CALDAV:comp-filter XML Element . . . . . . . . . . . . 85
+ 9.7.2. CALDAV:prop-filter XML Element . . . . . . . . . . . . 86
+ 9.7.3. CALDAV:param-filter XML Element . . . . . . . . . . . 87
+ 9.7.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 88
+ 9.7.5. CALDAV:text-match XML Element . . . . . . . . . . . . 88
+ 9.8. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 89
+ 9.9. CALDAV:time-range XML Element . . . . . . . . . . . . . . 90
+ 9.10. CALDAV:calendar-multiget XML Element . . . . . . . . . . . 94
+ 9.11. CALDAV:free-busy-query XML Element . . . . . . . . . . . . 95
+ 10. Internationalization Considerations . . . . . . . . . . . . . 95
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 95
+ 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
+ 12.1. Namespace Registration . . . . . . . . . . . . . . . . . . 96
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 96
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97
+ 14.1. Normative References . . . . . . . . . . . . . . . . . . . 97
+ 14.2. Informative References . . . . . . . . . . . . . . . . . . 98
+ Appendix A. CalDAV Method Privilege Table (Normative) . . . . . . 99
+ Appendix B. Calendar Collections Used in the Examples . . . . . . 99
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 4]
+
+RFC 4791 CalDAV March 2007
+
+
+1. Introduction
+
+ The concept of using HTTP [RFC2616] and WebDAV [RFC2518] as a basis
+ for a calendar access protocol is by no means a new concept: it was
+ discussed in the IETF CALSCH working group as early as 1997 or 1998.
+ Several companies have implemented calendar access protocols using
+ HTTP to upload and download iCalendar [RFC2445] objects, and using
+ WebDAV to get listings of resources. However, those implementations
+ do not interoperate because there are many small and big decisions to
+ be made in how to model calendaring data as WebDAV resources, as well
+ as how to implement required features that aren't already part of
+ WebDAV. This document proposes a way to model calendar data in
+ WebDAV, with additional features to make an interoperable calendar
+ access protocol.
+
+1.1. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ The term "protected" is used in the Conformance field of property
+ definitions as defined in Section 1.4.2 of [RFC3253].
+
+ When XML element types in the namespaces "DAV:" and
+ "urn:ietf:params:xml:ns:caldav" are referenced in this document
+ outside of the context of an XML fragment, the string "DAV:" and
+ "CALDAV:" will be prefixed to the element type names, respectively.
+
+1.2. XML Namespaces and Processing
+
+ Definitions of XML elements in this document use XML element type
+ declarations (as found in XML Document Type Declarations), described
+ in Section 3.2 of [W3C.REC-xml-20060816].
+
+ The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
+ elements defined in this specification, its revisions, and related
+ CalDAV specifications. XML elements defined by individual
+ implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav"
+ namespace, and instead should use a namespace that they control.
+
+ The XML declarations used in this document do not include namespace
+ information. Thus, implementers must not use these declarations as
+ the only way to create valid CalDAV properties or to validate CalDAV
+ XML element types. Some of the declarations refer to XML elements
+ defined by WebDAV [RFC2518], which use the "DAV:" namespace.
+ Wherever such XML elements appear, they are explicitly prefixed with
+ "DAV:" to avoid confusion.
+
+
+
+Daboo, et al. Standards Track [Page 5]
+
+RFC 4791 CalDAV March 2007
+
+
+ Also note that some CalDAV XML element names are identical to WebDAV
+ XML element names, though their namespace differs. Care must be
+ taken not to confuse the two sets of names.
+
+ Processing of XML by CalDAV clients and servers MUST follow the rules
+ described in [RFC2518]; in particular, Section 14, and Appendix 3 of
+ that specification.
+
+1.3. Method Preconditions and Postconditions
+
+ A "precondition" of a method describes the state of the server that
+ must be true for that method to be performed. A "postcondition" of a
+ method describes the state of the server that must be true after that
+ method has been completed. If a method precondition or postcondition
+ for a request is not satisfied, the response status of the request
+ MUST either be 403 (Forbidden), if the request should not be repeated
+ because it will always fail, or 409 (Conflict), if it is expected
+ that the user might be able to resolve the conflict and resubmit the
+ request.
+
+ In order to allow better client handling of 403 and 409 responses, a
+ distinct XML element type is associated with each method precondition
+ and postcondition of a request. When a particular precondition is
+ not satisfied or a particular postcondition cannot be achieved, the
+ appropriate XML element MUST be returned as the child of a top-level
+ DAV:error element in the response body, unless otherwise negotiated
+ by the request.
+
+2. Requirements Overview
+
+ This section lists what functionality is required of a CalDAV server.
+ To advertise support for CalDAV, a server:
+
+ o MUST support iCalendar [RFC2445] as a media type for the calendar
+ object resource format;
+
+ o MUST support WebDAV Class 1 [RFC2518] (note that [rfc2518bis]
+ describes clarifications to [RFC2518] that aid interoperability);
+
+ o MUST support WebDAV ACL [RFC3744] with the additional privilege
+ defined in Section 6.1 of this document;
+
+ o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
+ (note that [RFC2246] has been obsoleted by [RFC4346]);
+
+ o MUST support ETags [RFC2616] with additional requirements
+ specified in Section 5.3.4 of this document;
+
+
+
+
+Daboo, et al. Standards Track [Page 6]
+
+RFC 4791 CalDAV March 2007
+
+
+ o MUST support all calendaring reports defined in Section 7 of this
+ document; and
+
+ o MUST advertise support on all calendar collections and calendar
+ object resources for the calendaring reports in the DAV:supported-
+ report-set property, as defined in Versioning Extensions to WebDAV
+ [RFC3253].
+
+ In addition, a server:
+
+ o SHOULD support the MKCALENDAR method defined in Section 5.3.1 of
+ this document.
+
+3. Calendaring Data Model
+
+ One of the features that has made WebDAV a successful protocol is its
+ firm data model. This makes it a useful framework for other
+ applications such as calendaring. This specification follows the
+ same pattern by developing all features based on a well-described
+ data model.
+
+ As a brief overview, a CalDAV calendar is modeled as a WebDAV
+ collection with a defined structure; each calendar collection
+ contains a number of resources representing calendar objects as its
+ direct child resource. Each resource representing a calendar object
+ (event, to-do, journal entry, or other calendar components) is called
+ a "calendar object resource". Each calendar object resource and each
+ calendar collection can be individually locked and have individual
+ WebDAV properties. Requirements derived from this model are provided
+ in Section 4.1 and Section 4.2.
+
+3.1. Calendar Server
+
+ A CalDAV server is a calendaring-aware engine combined with a WebDAV
+ repository. A WebDAV repository is a set of WebDAV collections,
+ containing other WebDAV resources, within a unified URL namespace.
+ For example, the repository "http://www.example.com/webdav/" may
+ contain WebDAV collections and resources, all of which have URLs
+ beginning with "http://www.example.com/webdav/". Note that the root
+ URL, "http://www.example.com/", may not itself be a WebDAV repository
+ (for example, if the WebDAV support is implemented through a servlet
+ or other Web server extension).
+
+ A WebDAV repository MAY include calendar data in some parts of its
+ URL namespace, and non-calendaring data in other parts.
+
+ A WebDAV repository can advertise itself as a CalDAV server if it
+ supports the functionality defined in this specification at any point
+
+
+
+Daboo, et al. Standards Track [Page 7]
+
+RFC 4791 CalDAV March 2007
+
+
+ within the root of the repository. That might mean that calendaring
+ data is spread throughout the repository and mixed with non-calendar
+ data in nearby collections (e.g., calendar data may be found in
+ /home/lisa/calendars/ as well as in /home/bernard/calendars/, and
+ non-calendar data in /home/lisa/contacts/). Or, it might mean that
+ calendar data can be found only in certain sections of the repository
+ (e.g., /calendar/). Calendaring features are only required in the
+ repository sections that are or contain calendar object resources.
+ Therefore, a repository confining calendar data to the /calendar/
+ collection would only need to support the CalDAV required features
+ within that collection.
+
+ The CalDAV server or repository is the canonical location for
+ calendar data and state information. Clients may submit requests to
+ change data or download data. Clients may store calendar objects
+ offline and attempt to synchronize at a later time. However, clients
+ MUST be prepared for calendar data on the server to change between
+ the time of last synchronization and when attempting an update, as
+ calendar collections may be shared and accessible via multiple
+ clients. Entity tags and other features make this possible.
+
+3.2. Recurrence and the Data Model
+
+ Recurrence is an important part of the data model because it governs
+ how many resources are expected to exist. This specification models
+ a recurring calendar component and its recurrence exceptions as a
+ single resource. In this model, recurrence rules, recurrence dates,
+ exception rules, and exception dates are all part of the data in a
+ single calendar object resource. This model avoids problems of
+ limiting how many recurrence instances to store in the repository,
+ how to keep recurrence instances in sync with the recurring calendar
+ component, and how to link recurrence exceptions with the recurring
+ calendar component. It also results in less data to synchronize
+ between client and server, and makes it easier to make changes to all
+ recurrence instances or to a recurrence rule. It makes it easier to
+ create a recurring calendar component and to delete all recurrence
+ instances.
+
+ Clients are not forced to retrieve information about all recurrence
+ instances of a recurring component. The CALDAV:calendar-query and
+ CALDAV:calendar-multiget reports defined in this document allow
+ clients to retrieve only recurrence instances that overlap a given
+ time range.
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 8]
+
+RFC 4791 CalDAV March 2007
+
+
+4. Calendar Resources
+
+4.1. Calendar Object Resources
+
+ Calendar object resources contained in calendar collections MUST NOT
+ contain more than one type of calendar component (e.g., VEVENT,
+ VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
+ components, which MUST be specified for each unique TZID parameter
+ value specified in the iCalendar object. For instance, a calendar
+ object resource can contain one VEVENT component and one VTIMEZONE
+ component, but it cannot contain one VEVENT component and one VTODO
+ component. Instead, the VEVENT and VTODO components would have to be
+ stored in separate calendar object resources in the same collection.
+
+ Calendar object resources contained in calendar collections MUST NOT
+ specify the iCalendar METHOD property.
+
+ The UID property value of the calendar components contained in a
+ calendar object resource MUST be unique in the scope of the calendar
+ collection in which they are stored.
+
+ Calendar components in a calendar collection that have different UID
+ property values MUST be stored in separate calendar object resources.
+
+ Calendar components with the same UID property value, in a given
+ calendar collection, MUST be contained in the same calendar object
+ resource. This ensures that all components in a recurrence "set" are
+ contained in the same calendar object resource. It is possible for a
+ calendar object resource to just contain components that represent
+ "overridden" instances (ones that modify the behavior of a regular
+ instance, and thus include a RECURRENCE-ID property) without also
+ including the "master" recurring component (the one that defines the
+ recurrence "set" and does not contain any RECURRENCE-ID property).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 9]
+
+RFC 4791 CalDAV March 2007
+
+
+ For example, given the following iCalendar object:
+
+ BEGIN:VCALENDAR
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ VERSION:2.0
+ BEGIN:VEVENT
+ UID:1@example.com
+ SUMMARY:One-off Meeting
+ DTSTAMP:20041210T183904Z
+ DTSTART:20041207T120000Z
+ DTEND:20041207T130000Z
+ END:VEVENT
+ BEGIN:VEVENT
+ UID:2@example.com
+ SUMMARY:Weekly Meeting
+ DTSTAMP:20041210T183838Z
+ DTSTART:20041206T120000Z
+ DTEND:20041206T130000Z
+ RRULE:FREQ=WEEKLY
+ END:VEVENT
+ BEGIN:VEVENT
+ UID:2@example.com
+ SUMMARY:Weekly Meeting
+ RECURRENCE-ID:20041213T120000Z
+ DTSTAMP:20041210T183838Z
+ DTSTART:20041213T130000Z
+ DTEND:20041213T140000Z
+ END:VEVENT
+ END:VCALENDAR
+
+ The VEVENT component with the UID value "1@example.com" would be
+ stored in its own calendar object resource. The two VEVENT
+ components with the UID value "2@example.com", which represent a
+ recurring event where one recurrence instance has been overridden,
+ would be stored in the same calendar object resource.
+
+4.2. Calendar Collection
+
+ A calendar collection contains calendar object resources that
+ represent calendar components within a calendar. A calendar
+ collection is manifested to clients as a WebDAV resource collection
+ identified by a URL. A calendar collection MUST report the DAV:
+ collection and CALDAV:calendar XML elements in the value of the DAV:
+ resourcetype property. The element type declaration for CALDAV:
+ calendar is:
+
+ <!ELEMENT calendar EMPTY>
+
+
+
+
+Daboo, et al. Standards Track [Page 10]
+
+RFC 4791 CalDAV March 2007
+
+
+ A calendar collection can be created through provisioning (i.e.,
+ automatically created when a user's account is provisioned), or it
+ can be created with the MKCALENDAR method (see Section 5.3.1). This
+ method can be useful for a user to create additional calendars (e.g.,
+ soccer schedule) or for users to share a calendar (e.g., team events
+ or conference rooms). However, note that this document doesn't
+ define the purpose of extra calendar collections. Users must rely on
+ non-standard cues to find out what a calendar collection is for, or
+ use the CALDAV:calendar-description property defined in Section 5.2.1
+ to provide such a cue.
+
+ The following restrictions are applied to the resources within a
+ calendar collection:
+
+ a. Calendar collections MUST only contain calendar object resources
+ and collections that are not calendar collections, i.e., the only
+ "top-level" non-collection resources allowed in a calendar
+ collection are calendar object resources. This ensures that
+ calendar clients do not have to deal with non-calendar data in a
+ calendar collection, though they do have to distinguish between
+ calendar object resources and collections when using standard
+ WebDAV techniques to examine the contents of a collection.
+
+ b. Collections contained in calendar collections MUST NOT contain
+ calendar collections at any depth, i.e., "nesting" of calendar
+ collections within other calendar collections at any depth is not
+ allowed. This specification does not define how collections
+ contained in a calendar collection are used or how they relate to
+ any calendar object resources contained in the calendar
+ collection.
+
+ Multiple calendar collections MAY be children of the same collection.
+
+5. Calendar Access Feature
+
+5.1. Calendar Access Support
+
+ A server supporting the features described in this document MUST
+ include "calendar-access" as a field in the DAV response header from
+ an OPTIONS request on any resource that supports any calendar
+ properties, reports, method, or privilege. A value of "calendar-
+ access" in the DAV response header MUST indicate that the server
+ supports all MUST level requirements specified in this document.
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 11]
+
+RFC 4791 CalDAV March 2007
+
+
+5.1.1. Example: Using OPTIONS for the Discovery of Calendar Access
+ Support
+
+ >> Request <<
+
+ OPTIONS /home/bernard/calendars/ HTTP/1.1
+ Host: cal.example.com
+
+ >> Response <<
+
+ HTTP/1.1 200 OK
+ Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
+ Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
+ DAV: 1, 2, access-control, calendar-access
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Length: 0
+
+ In this example, the OPTIONS method returns the value "calendar-
+ access" in the DAV response header to indicate that the collection
+ "/home/bernard/calendars/" supports the properties, reports, method,
+ or privilege defined in this specification.
+
+5.2. Calendar Collection Properties
+
+ This section defines properties for calendar collections.
+
+5.2.1. CALDAV:calendar-description Property
+
+ Name: calendar-description
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a human-readable description of the calendar
+ collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MAY be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]). An xml:lang attribute indicating the human
+ language of the description SHOULD be set for this property by
+ clients or through server provisioning. Servers MUST return any
+ xml:lang attribute if set for the property.
+
+ Description: If present, the property contains a description of the
+ calendar collection that is suitable for presentation to a user.
+ If not present, the client should assume no description for the
+ calendar collection.
+
+
+
+
+Daboo, et al. Standards Track [Page 12]
+
+RFC 4791 CalDAV March 2007
+
+
+ Definition:
+
+ <!ELEMENT calendar-description (#PCDATA)>
+ PCDATA value: string
+
+ Example:
+
+ <C:calendar-description xml:lang="fr-CA"
+ xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >Calendrier de Mathilde Desruisseaux</C:calendar-description>
+
+5.2.2. CALDAV:calendar-timezone Property
+
+ Name: calendar-timezone
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a time zone on a calendar collection.
+
+ Conformance: This property SHOULD be defined on all calendar
+ collections. If defined, it SHOULD NOT be returned by a PROPFIND
+ DAV:allprop request (as defined in Section 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:calendar-timezone property is used to
+ specify the time zone the server should rely on to resolve "date"
+ values and "date with local time" values (i.e., floating time) to
+ "date with UTC time" values. The server will require this
+ information to determine if a calendar component scheduled with
+ "date" values or "date with local time" values overlaps a CALDAV:
+ time-range specified in a CALDAV:calendar-query REPORT. The
+ server will also require this information to compute the proper
+ FREEBUSY time period as "date with UTC time" in the VFREEBUSY
+ component returned in a response to a CALDAV:free-busy-query
+ REPORT request that takes into account calendar components
+ scheduled with "date" values or "date with local time" values. In
+ the absence of this property, the server MAY rely on the time zone
+ of their choice.
+
+ Note: The iCalendar data embedded within the CALDAV:calendar-
+ timezone XML element MUST follow the standard XML character data
+ encoding rules, including use of &lt;, &gt;, &amp; etc. entity
+ encoding or the use of a <![CDATA[ ... ]]> construct. In the
+ later case, the iCalendar data cannot contain the character
+ sequence "]]>", which is the end delimiter for the CDATA section.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 13]
+
+RFC 4791 CalDAV March 2007
+
+
+ Definition:
+
+ <!ELEMENT calendar-timezone (#PCDATA)>
+ PCDATA value: an iCalendar object with exactly one VTIMEZONE
+ component.
+
+ Example:
+
+ <C:calendar-timezone
+ xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ TZID:US-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:Eastern Standard Time (US &amp; Canada)
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:Eastern Daylight Time (US &amp; Canada)
+ END:DAYLIGHT
+ END:VTIMEZONE
+ END:VCALENDAR
+ </C:calendar-timezone>
+
+5.2.3. CALDAV:supported-calendar-component-set Property
+
+ Name: supported-calendar-component-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies the calendar component types (e.g., VEVENT,
+ VTODO, etc.) that calendar object resources can contain in the
+ calendar collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+
+
+
+Daboo, et al. Standards Track [Page 14]
+
+RFC 4791 CalDAV March 2007
+
+
+ Description: The CALDAV:supported-calendar-component-set property is
+ used to specify restrictions on the calendar component types that
+ calendar object resources may contain in a calendar collection.
+ Any attempt by the client to store calendar object resources with
+ component types not listed in this property, if it exists, MUST
+ result in an error, with the CALDAV:supported-calendar-component
+ precondition (Section 5.3.2.1) being violated. Since this
+ property is protected, it cannot be changed by clients using a
+ PROPPATCH request. However, clients can initialize the value of
+ this property when creating a new calendar collection with
+ MKCALENDAR. The empty-element tag <C:comp name="VTIMEZONE"/> MUST
+ only be specified if support for calendar object resources that
+ only contain VTIMEZONE components is provided or desired. Support
+ for VTIMEZONE components in calendar object resources that contain
+ VEVENT or VTODO components is always assumed. In the absence of
+ this property, the server MUST accept all component types, and the
+ client can assume that all component types are accepted.
+
+ Definition:
+
+ <!ELEMENT supported-calendar-component-set (comp+)>
+
+ Example:
+
+ <C:supported-calendar-component-set
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:comp name="VEVENT"/>
+ <C:comp name="VTODO"/>
+ </C:supported-calendar-component-set>
+
+5.2.4. CALDAV:supported-calendar-data Property
+
+ Name: supported-calendar-data
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies what media types are allowed for calendar object
+ resources in a calendar collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:supported-calendar-data property is used to
+ specify the media type supported for the calendar object resources
+ contained in a given calendar collection (e.g., iCalendar version
+ 2.0). Any attempt by the client to store calendar object
+
+
+
+Daboo, et al. Standards Track [Page 15]
+
+RFC 4791 CalDAV March 2007
+
+
+ resources with a media type not listed in this property MUST
+ result in an error, with the CALDAV:supported-calendar-data
+ precondition (Section 5.3.2.1) being violated. In the absence of
+ this property, the server MUST only accept data with the media
+ type "text/calendar" and iCalendar version 2.0, and clients can
+ assume that the server will only accept this data.
+
+ Definition:
+
+ <!ELEMENT supported-calendar-data (calendar-data+)>
+
+ Example:
+
+ <C:supported-calendar-data
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:calendar-data content-type="text/calendar" version="2.0"/>
+ </C:supported-calendar-data>
+
+5.2.5. CALDAV:max-resource-size Property
+
+ Name: max-resource-size
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a numeric value indicating the maximum size of a
+ resource in octets that the server is willing to accept when a
+ calendar object resource is stored in a calendar collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:max-resource-size is used to specify a
+ numeric value that represents the maximum size in octets that the
+ server is willing to accept when a calendar object resource is
+ stored in a calendar collection. Any attempt to store a calendar
+ object resource exceeding this size MUST result in an error, with
+ the CALDAV:max-resource-size precondition (Section 5.3.2.1) being
+ violated. In the absence of this property, the client can assume
+ that the server will allow storing a resource of any reasonable
+ size.
+
+ Definition:
+
+ <!ELEMENT max-resource-size (#PCDATA)>
+ PCDATA value: a numeric value (positive integer)
+
+
+
+
+Daboo, et al. Standards Track [Page 16]
+
+RFC 4791 CalDAV March 2007
+
+
+ Example:
+
+ <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >102400</C:max-resource-size>
+
+5.2.6. CALDAV:min-date-time Property
+
+ Name: min-date-time
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a DATE-TIME value indicating the earliest date and
+ time (in UTC) that the server is willing to accept for any DATE or
+ DATE-TIME value in a calendar object resource stored in a calendar
+ collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:min-date-time is used to specify an
+ iCalendar DATE-TIME value in UTC that indicates the earliest
+ inclusive date that the server is willing to accept for any
+ explicit DATE or DATE-TIME value in a calendar object resource
+ stored in a calendar collection. Any attempt to store a calendar
+ object resource using a DATE or DATE-TIME value earlier than this
+ value MUST result in an error, with the CALDAV:min-date-time
+ precondition (Section 5.3.2.1) being violated. Note that servers
+ MUST accept recurring components that specify instances beyond
+ this limit, provided none of those instances have been overridden.
+ In that case, the server MAY simply ignore those instances outside
+ of the acceptable range when processing reports on the calendar
+ object resource. In the absence of this property, the client can
+ assume any valid iCalendar date may be used at least up to the
+ CALDAV:max-date-time value, if that is defined.
+
+ Definition:
+
+ <!ELEMENT min-date-time (#PCDATA)>
+ PCDATA value: an iCalendar format DATE-TIME value in UTC
+
+ Example:
+
+ <C:min-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >19000101T000000Z</C:min-date-time>
+
+
+
+
+
+Daboo, et al. Standards Track [Page 17]
+
+RFC 4791 CalDAV March 2007
+
+
+5.2.7. CALDAV:max-date-time Property
+
+ Name: max-date-time
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a DATE-TIME value indicating the latest date and
+ time (in UTC) that the server is willing to accept for any DATE or
+ DATE-TIME value in a calendar object resource stored in a calendar
+ collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:max-date-time is used to specify an
+ iCalendar DATE-TIME value in UTC that indicates the inclusive
+ latest date that the server is willing to accept for any date or
+ time value in a calendar object resource stored in a calendar
+ collection. Any attempt to store a calendar object resource using
+ a DATE or DATE-TIME value later than this value MUST result in an
+ error, with the CALDAV:max-date-time precondition
+ (Section 5.3.2.1) being violated. Note that servers MUST accept
+ recurring components that specify instances beyond this limit,
+ provided none of those instances have been overridden. In that
+ case, the server MAY simply ignore those instances outside of the
+ acceptable range when processing reports on the calendar object
+ resource. In the absence of this property, the client can assume
+ any valid iCalendar date may be used at least down to the CALDAV:
+ min-date-time value, if that is defined.
+
+ Definition:
+
+ <!ELEMENT max-date-time (#PCDATA)>
+ PCDATA value: an iCalendar format DATE-TIME value in UTC
+
+ Example:
+
+ <C:max-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >20491231T235959Z</C:max-date-time>
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 18]
+
+RFC 4791 CalDAV March 2007
+
+
+5.2.8. CALDAV:max-instances Property
+
+ Name: max-instances
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a numeric value indicating the maximum number of
+ recurrence instances that a calendar object resource stored in a
+ calendar collection can generate.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:max-instances is used to specify a numeric
+ value that indicates the maximum number of recurrence instances
+ that a calendar object resource stored in a calendar collection
+ can generate. Any attempt to store a calendar object resource
+ with a recurrence pattern that generates more instances than this
+ value MUST result in an error, with the CALDAV:max-instances
+ precondition (Section 5.3.2.1) being violated. In the absence of
+ this property, the client can assume that the server has no limits
+ on the number of recurrence instances it can handle or expand.
+
+ Definition:
+
+ <!ELEMENT max-instances (#PCDATA)>
+ PCDATA value: a numeric value (integer greater than zero)
+
+ Example:
+
+ <C:max-instances xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >100</C:max-instances>
+
+5.2.9. CALDAV:max-attendees-per-instance Property
+
+ Name: max-attendees-per-instance
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Provides a numeric value indicating the maximum number of
+ ATTENDEE properties in any instance of a calendar object resource
+ stored in a calendar collection.
+
+ Conformance: This property MAY be defined on any calendar
+ collection. If defined, it MUST be protected and SHOULD NOT be
+
+
+
+
+Daboo, et al. Standards Track [Page 19]
+
+RFC 4791 CalDAV March 2007
+
+
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:max-attendees-per-instance is used to
+ specify a numeric value that indicates the maximum number of
+ iCalendar ATTENDEE properties on any one instance of a calendar
+ object resource stored in a calendar collection. Any attempt to
+ store a calendar object resource with more ATTENDEE properties per
+ instance than this value MUST result in an error, with the CALDAV:
+ max-attendees-per-instance precondition (Section 5.3.2.1) being
+ violated. In the absence of this property, the client can assume
+ that the server can handle any number of ATTENDEE properties in a
+ calendar component.
+
+ Definition:
+
+ <!ELEMENT max-attendees-per-instance (#PCDATA)>
+ PCDATA value: a numeric value (integer greater than zero)
+
+ Example:
+
+ <C:max-attendees-per-instance
+ xmlns:C="urn:ietf:params:xml:ns:caldav"
+ >25</C:max-attendees-per-instance>
+
+5.2.10. Additional Precondition for PROPPATCH
+
+ This specification requires an additional Precondition for the
+ PROPPATCH method. The precondition is:
+
+ (CALDAV:valid-calendar-data): The time zone specified in CALDAV:
+ calendar-timezone property MUST be a valid iCalendar object
+ containing a single valid VTIMEZONE component.
+
+5.3. Creating Resources
+
+ Calendar collections and calendar object resources may be created by
+ either a CalDAV client or by the CalDAV server. This specification
+ defines restrictions and a data model that both clients and servers
+ MUST adhere to when manipulating such calendar data.
+
+5.3.1. MKCALENDAR Method
+
+ An HTTP request using the MKCALENDAR method creates a new calendar
+ collection resource. A server MAY restrict calendar collection
+ creation to particular collections.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 20]
+
+RFC 4791 CalDAV March 2007
+
+
+ Support for MKCALENDAR on the server is only RECOMMENDED and not
+ REQUIRED because some calendar stores only support one calendar per
+ user (or principal), and those are typically pre-created for each
+ account. However, servers and clients are strongly encouraged to
+ support MKCALENDAR whenever possible to allow users to create
+ multiple calendar collections to help organize their data better.
+
+ Clients SHOULD use the DAV:displayname property for a human-readable
+ name of the calendar. Clients can either specify the value of the
+ DAV:displayname property in the request body of the MKCALENDAR
+ request, or alternatively issue a PROPPATCH request to change the
+ DAV:displayname property to the appropriate value immediately after
+ issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV:
+ displayname property to be the same as any other calendar collection
+ at the same URI "level". When displaying calendar collections to
+ users, clients SHOULD check the DAV:displayname property and use that
+ value as the name of the calendar. In the event that the DAV:
+ displayname property is empty, the client MAY use the last part of
+ the calendar collection URI as the name; however, that path segment
+ may be "opaque" and not represent any meaningful human-readable text.
+
+ If a MKCALENDAR request fails, the server state preceding the request
+ MUST be restored.
+
+ Marshalling:
+ If a request body is included, it MUST be a CALDAV:mkcalendar XML
+ element. Instruction processing MUST occur in the order
+ instructions are received (i.e., from top to bottom).
+ Instructions MUST either all be executed or none executed. Thus,
+ if any error occurs during processing, all executed instructions
+ MUST be undone and a proper error result returned. Instruction
+ processing details can be found in the definition of the DAV:set
+ instruction in Section 12.13.2 of [RFC2518].
+
+ <!ELEMENT mkcalendar (DAV:set)>
+
+ If a response body for a successful request is included, it MUST
+ be a CALDAV:mkcalendar-response XML element.
+
+ <!ELEMENT mkcalendar-response ANY>
+
+ The response MUST include a Cache-Control:no-cache header.
+
+ Preconditions:
+
+ (DAV:resource-must-be-null): A resource MUST NOT exist at the
+ Request-URI;
+
+
+
+
+Daboo, et al. Standards Track [Page 21]
+
+RFC 4791 CalDAV March 2007
+
+
+ (CALDAV:calendar-collection-location-ok): The Request-URI MUST
+ identify a location where a calendar collection can be created;
+
+ (CALDAV:valid-calendar-data): The time zone specified in the
+ CALDAV:calendar-timezone property MUST be a valid iCalendar object
+ containing a single valid VTIMEZONE component;
+
+ (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
+ the current user on the parent collection of the Request-URI.
+
+ Postconditions:
+
+ (CALDAV:initialize-calendar-collection): A new calendar collection
+ exists at the Request-URI. The DAV:resourcetype of the calendar
+ collection MUST contain both DAV:collection and CALDAV:calendar
+ XML elements.
+
+5.3.1.1. Status Codes
+
+ The following are examples of response codes one would expect to get
+ in a response to a MKCALENDAR request. Note that this list is by no
+ means exhaustive.
+
+ 201 (Created) - The calendar collection resource was created in
+ its entirety;
+
+ 207 (Multi-Status) - The calendar collection resource was not
+ created since one or more DAV:set instructions specified in the
+ request body could not be processed successfully. The following
+ are examples of response codes one would expect to be used in a
+ 207 (Multi-Status) response in this situation:
+
+ 403 (Forbidden) - The client, for reasons the server chooses
+ not to specify, cannot alter one of the properties;
+
+ 409 (Conflict) - The client has provided a value whose
+ semantics are not appropriate for the property. This includes
+ trying to set read-only properties;
+
+ 424 (Failed Dependency) - The DAV:set instruction on the
+ specified resource would have succeeded if it were not for the
+ failure of another DAV:set instruction specified in the request
+ body;
+
+ 423 (Locked) - The specified resource is locked and the client
+ either is not a lock owner or the lock type requires a lock
+ token to be submitted and the client did not submit it; and
+
+
+
+
+Daboo, et al. Standards Track [Page 22]
+
+RFC 4791 CalDAV March 2007
+
+
+ 507 (Insufficient Storage) - The server did not have sufficient
+ space to record the property;
+
+ 403 (Forbidden) - This indicates at least one of two conditions:
+ 1) the server does not allow the creation of calendar collections
+ at the given location in its namespace, or 2) the parent
+ collection of the Request-URI exists but cannot accept members;
+
+ 409 (Conflict) - A collection cannot be made at the Request-URI
+ until one or more intermediate collections have been created;
+
+ 415 (Unsupported Media Type) - The server does not support the
+ request type of the body; and
+
+ 507 (Insufficient Storage) - The resource does not have sufficient
+ space to record the state of the resource after the execution of
+ this method.
+
+5.3.1.2. Example: Successful MKCALENDAR Request
+
+ This example creates a calendar collection called /home/lisa/
+ calendars/events/ on the server cal.example.com with specific values
+ for the properties DAV:displayname, CALDAV:calendar-description,
+ CALDAV:supported-calendar-component-set, and CALDAV:calendar-
+ timezone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 23]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
+ Host: cal.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:mkcalendar xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:set>
+ <D:prop>
+ <D:displayname>Lisa's Events</D:displayname>
+ <C:calendar-description xml:lang="en"
+ >Calendar restricted to events.</C:calendar-description>
+ <C:supported-calendar-component-set>
+ <C:comp name="VEVENT"/>
+ </C:supported-calendar-component-set>
+ <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ TZID:US-Eastern
+ LAST-MODIFIED:19870101T000000Z
+ BEGIN:STANDARD
+ DTSTART:19671029T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ TZNAME:Eastern Standard Time (US & Canada)
+ END:STANDARD
+ BEGIN:DAYLIGHT
+ DTSTART:19870405T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ TZNAME:Eastern Daylight Time (US & Canada)
+ END:DAYLIGHT
+ END:VTIMEZONE
+ END:VCALENDAR
+ ]]></C:calendar-timezone>
+ </D:prop>
+ </D:set>
+ </C:mkcalendar>
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 24]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Response <<
+
+ HTTP/1.1 201 Created
+ Cache-Control: no-cache
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Length: 0
+
+5.3.2. Creating Calendar Object Resources
+
+ Clients populate calendar collections with calendar object resources.
+ The URL for each calendar object resource is entirely arbitrary and
+ does not need to bear a specific relationship to the calendar object
+ resource's iCalendar properties or other metadata. New calendar
+ object resources MUST be created with a PUT request targeted at an
+ unmapped URI. A PUT request targeted at a mapped URI updates an
+ existing calendar object resource.
+
+ When servers create new resources, it's not hard for the server to
+ choose an unmapped URI. It's slightly tougher for clients, because a
+ client might not want to examine all resources in the collection and
+ might not want to lock the entire collection to ensure that a new
+ resource isn't created with a name collision. However, there is an
+ HTTP feature to mitigate this. If the client intends to create a new
+ non-collection resource, such as a new VEVENT, the client SHOULD use
+ the HTTP request header "If-None-Match: *" on the PUT request. The
+ Request-URI on the PUT request MUST include the target collection,
+ where the resource is to be created, plus the name of the resource in
+ the last path segment. The "If-None-Match: *" request header ensures
+ that the client will not inadvertently overwrite an existing resource
+ if the last path segment turned out to already be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 25]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1
+ If-None-Match: *
+ Host: cal.example.com
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VEVENT
+ UID:20010712T182145Z-123401@example.com
+ DTSTAMP:20060712T182145Z
+ DTSTART:20060714T170000Z
+ DTEND:20060715T040000Z
+ SUMMARY:Bastille Day Party
+ END:VEVENT
+ END:VCALENDAR
+
+ >> Response <<
+
+ HTTP/1.1 201 Created
+ Content-Length: 0
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ ETag: "123456789-000-111"
+
+ The request to change an existing event is the same, but with a
+ specific ETag in the "If-Match" header, rather than the "If-None-
+ Match" header.
+
+ As indicated in Section 3.10 of [RFC2445], the URL of calendar object
+ resources containing (an arbitrary set of) calendaring and scheduling
+ information may be suffixed by ".ics", and the URL of calendar object
+ resources containing free or busy time information may be suffixed by
+ ".ifb".
+
+5.3.2.1. Additional Preconditions for PUT, COPY, and MOVE
+
+ This specification creates additional Preconditions for PUT, COPY,
+ and MOVE methods. These preconditions apply when a PUT operation of
+ a calendar object resource into a calendar collection occurs, or when
+ a COPY or MOVE operation of a calendar object resource into a
+ calendar collection occurs, or when a COPY or MOVE operation occurs
+ on a calendar collection.
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 26]
+
+RFC 4791 CalDAV March 2007
+
+
+ The new preconditions are:
+
+ (CALDAV:supported-calendar-data): The resource submitted in the
+ PUT request, or targeted by a COPY or MOVE request, MUST be a
+ supported media type (i.e., iCalendar) for calendar object
+ resources;
+
+ (CALDAV:valid-calendar-data): The resource submitted in the PUT
+ request, or targeted by a COPY or MOVE request, MUST be valid data
+ for the media type being specified (i.e., MUST contain valid
+ iCalendar data);
+
+ (CALDAV:valid-calendar-object-resource): The resource submitted in
+ the PUT request, or targeted by a COPY or MOVE request, MUST obey
+ all restrictions specified in Section 4.1 (e.g., calendar object
+ resources MUST NOT contain more than one type of calendar
+ component, calendar object resources MUST NOT specify the
+ iCalendar METHOD property, etc.);
+
+ (CALDAV:supported-calendar-component): The resource submitted in
+ the PUT request, or targeted by a COPY or MOVE request, MUST
+ contain a type of calendar component that is supported in the
+ targeted calendar collection;
+
+ (CALDAV:no-uid-conflict): The resource submitted in the PUT
+ request, or targeted by a COPY or MOVE request, MUST NOT specify
+ an iCalendar UID property value already in use in the targeted
+ calendar collection or overwrite an existing calendar object
+ resource with one that has a different UID property value.
+ Servers SHOULD report the URL of the resource that is already
+ making use of the same UID property value in the DAV:href element;
+
+ <!ELEMENT no-uid-conflict (DAV:href)>
+
+ (CALDAV:calendar-collection-location-ok): In a COPY or MOVE
+ request, when the Request-URI is a calendar collection, the
+ Destination-URI MUST identify a location where a calendar
+ collection can be created;
+
+ (CALDAV:max-resource-size): The resource submitted in the PUT
+ request, or targeted by a COPY or MOVE request, MUST have an octet
+ size less than or equal to the value of the CALDAV:max-resource-
+ size property value (Section 5.2.5) on the calendar collection
+ where the resource will be stored;
+
+ (CALDAV:min-date-time): The resource submitted in the PUT request,
+ or targeted by a COPY or MOVE request, MUST have all of its
+ iCalendar DATE or DATE-TIME property values (for each recurring
+
+
+
+Daboo, et al. Standards Track [Page 27]
+
+RFC 4791 CalDAV March 2007
+
+
+ instance) greater than or equal to the value of the CALDAV:min-
+ date-time property value (Section 5.2.6) on the calendar
+ collection where the resource will be stored;
+
+ (CALDAV:max-date-time): The resource submitted in the PUT request,
+ or targeted by a COPY or MOVE request, MUST have all of its
+ iCalendar DATE or DATE-TIME property values (for each recurring
+ instance) less than the value of the CALDAV:max-date-time property
+ value (Section 5.2.7) on the calendar collection where the
+ resource will be stored;
+
+ (CALDAV:max-instances): The resource submitted in the PUT request,
+ or targeted by a COPY or MOVE request, MUST generate a number of
+ recurring instances less than or equal to the value of the CALDAV:
+ max-instances property value (Section 5.2.8) on the calendar
+ collection where the resource will be stored;
+
+ (CALDAV:max-attendees-per-instance): The resource submitted in the
+ PUT request, or targeted by a COPY or MOVE request, MUST have a
+ number of ATTENDEE properties on any one instance less than or
+ equal to the value of the CALDAV:max-attendees-per-instance
+ property value (Section 5.2.9) on the calendar collection where
+ the resource will be stored;
+
+5.3.3. Non-Standard Components, Properties, and Parameters
+
+ iCalendar provides a "standard mechanism for doing non-standard
+ things". This extension support allows implementers to make use of
+ non-standard components, properties, and parameters whose names are
+ prefixed with the text "X-".
+
+ Servers MUST support the use of non-standard components, properties,
+ and parameters in calendar object resources stored via the PUT
+ method.
+
+ Servers may need to enforce rules for their own "private" components,
+ properties, or parameters, so servers MAY reject any attempt by the
+ client to change those or use values for those outside of any
+ restrictions the server may have. Servers SHOULD ensure that any
+ "private" components, properties, or parameters it uses follow the
+ convention of including a vendor id in the "X-" name, as described in
+ Section 4.2 of [RFC2445], e.g., "X-ABC-PRIVATE".
+
+5.3.4. Calendar Object Resource Entity Tag
+
+ The DAV:getetag property MUST be defined and set to a strong entity
+ tag on all calendar object resources.
+
+
+
+
+Daboo, et al. Standards Track [Page 28]
+
+RFC 4791 CalDAV March 2007
+
+
+ A response to a GET request targeted at a calendar object resource
+ MUST contain an ETag response header field indicating the current
+ value of the strong entity tag of the calendar object resource.
+
+ Servers SHOULD return a strong entity tag (ETag header) in a PUT
+ response when the stored calendar object resource is equivalent by
+ octet equality to the calendar object resource submitted in the body
+ of the PUT request. This allows clients to reliably use the returned
+ strong entity tag for data synchronization purposes. For instance,
+ the client can do a PROPFIND request on the stored calendar object
+ resource and have the DAV:getetag property returned, and compare that
+ value with the strong entity tag it received on the PUT response, and
+ know that if they are equal, then the calendar object resource on the
+ server has not been changed.
+
+ In the case where the data stored by a server as a result of a PUT
+ request is not equivalent by octet equality to the submitted calendar
+ object resource, the behavior of the ETag response header is not
+ specified here, with the exception that a strong entity tag MUST NOT
+ be returned in the response. As a result, clients may need to
+ retrieve the modified calendar object resource (and ETag) as a basis
+ for further changes, rather than use the calendar object resource it
+ had sent with the PUT request.
+
+6. Calendaring Access Control
+
+6.1. Calendaring Privilege
+
+ CalDAV servers MUST support and adhere to the requirements of WebDAV
+ ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set
+ of privileges that can be applied to WebDAV collections and ordinary
+ resources. CalDAV servers MUST also support the calendaring
+ privilege defined in this section.
+
+6.1.1. CALDAV:read-free-busy Privilege
+
+ Calendar users often wish to allow other users to see their busy time
+ information, without viewing the other details of the calendar
+ components (e.g., location, summary, attendees). This allows a
+ significant amount of privacy while still allowing other users to
+ schedule meetings at times when the user is likely to be free.
+
+ The CALDAV:read-free-busy privilege controls which calendar
+ collections, regular collections, and calendar object resources are
+ examined when a CALDAV:free-busy-query REPORT request is processed
+ (see Section 7.10). This privilege can be granted on calendar
+ collections, regular collections, or calendar object resources.
+
+
+
+
+Daboo, et al. Standards Track [Page 29]
+
+RFC 4791 CalDAV March 2007
+
+
+ Servers MUST support this privilege on all calendar collections,
+ regular collections, and calendar object resources.
+
+
+ <!ELEMENT read-free-busy EMPTY>
+
+ The CALDAV:read-free-busy privilege MUST be aggregated in the DAV:
+ read privilege. Servers MUST allow the CALDAV:read-free-busy to be
+ granted without the DAV:read privilege being granted.
+
+ Clients should note that when only the CALDAV:read-free-busy
+ privilege has been granted on a resource, access to GET, HEAD,
+ OPTIONS, and PROPFIND on the resource is not implied (those
+ operations are governed by the DAV:read privilege).
+
+6.2. Additional Principal Property
+
+ This section defines an additional property for WebDAV principal
+ resources, as defined in [RFC3744].
+
+6.2.1. CALDAV:calendar-home-set Property
+
+ Name: calendar-home-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identifies the URL of any WebDAV collections that contain
+ calendar collections owned by the associated principal resource.
+
+ Conformance: This property SHOULD be defined on a principal
+ resource. If defined, it MAY be protected and SHOULD NOT be
+ returned by a PROPFIND DAV:allprop request (as defined in Section
+ 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:calendar-home-set property is meant to allow
+ users to easily find the calendar collections owned by the
+ principal. Typically, users will group all the calendar
+ collections that they own under a common collection. This
+ property specifies the URL of collections that are either calendar
+ collections or ordinary collections that have child or descendant
+ calendar collections owned by the principal.
+
+ Definition:
+
+ <!ELEMENT calendar-home-set (DAV:href*)>
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 30]
+
+RFC 4791 CalDAV March 2007
+
+
+ Example:
+
+ <C:calendar-home-set xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:href>http://cal.example.com/home/bernard/calendars/</D:href>
+ </C:calendar-home-set>
+
+7. Calendaring Reports
+
+ This section defines the reports that CalDAV servers MUST support on
+ calendar collections and calendar object resources.
+
+ CalDAV servers MUST advertise support for these reports on all
+ calendar collections and calendar object resources with the DAV:
+ supported-report-set property, defined in Section 3.1.5 of [RFC3253].
+ CalDAV servers MAY also advertise support for these reports on
+ ordinary collections.
+
+ Some of these reports allow calendar data (from possibly multiple
+ resources) to be returned.
+
+7.1. REPORT Method
+
+ The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
+ extensible mechanism for obtaining information about one or more
+ resources. Unlike the PROPFIND method, which returns the value of
+ one or more named properties, the REPORT method can involve more
+ complex processing. REPORT is valuable in cases where the server has
+ access to all of the information needed to perform the complex
+ request (such as a query), and where it would require multiple
+ requests for the client to retrieve the information needed to perform
+ the same request.
+
+ CalDAV servers MUST support the DAV:expand-property REPORT defined in
+ Section 3.8 of [RFC3253].
+
+7.2. Ordinary Collections
+
+ Servers MAY support the reports defined in this document on ordinary
+ collections (collections that are not calendar collections), in
+ addition to calendar collections or calendar object resources. In
+ computing responses to the reports on ordinary collections, servers
+ MUST only consider calendar object resources contained in calendar
+ collections that are targeted by the REPORT request, based on the
+ value of the Depth request header.
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 31]
+
+RFC 4791 CalDAV March 2007
+
+
+7.3. Date and Floating Time
+
+ iCalendar provides a way to specify DATE and DATE-TIME values that
+ are not bound to any time zone in particular, hereafter called
+ "floating date" and "floating time", respectively. These values are
+ used to represent the same day, hour, minute, and second value,
+ regardless of which time zone is being observed. For instance, the
+ DATE value "20051111", represents November 11, 2005 in no specific
+ time zone, while the DATE-TIME value "20051111T111100" represents
+ November 11, 2005, at 11:11 A.M. in no specific time zone.
+
+ CalDAV servers may need to convert "floating date" and "floating
+ time" values in date with UTC time values in the processing of
+ calendaring REPORT requests.
+
+ For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the
+ value of the CALDAV:timezone XML element, if specified as part of the
+ request body, to perform the proper conversion of "floating date" and
+ "floating time" values to date with UTC time values. If the CALDAV:
+ timezone XML element is not specified in the request body, CalDAV
+ servers MUST rely on the value of the CALDAV:calendar-timezone
+ property, if defined, or else the CalDAV servers MAY rely on the time
+ zone of their choice.
+
+ For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on
+ the value of the CALDAV:calendar-timezone property, if defined, to
+ compute the proper FREEBUSY time period value as date with UTC time
+ for calendar components scheduled with "floating date" or "floating
+ time". If the CALDAV:calendar-timezone property is not defined,
+ CalDAV servers MAY rely on the time zone of their choice.
+
+7.4. Time Range Filtering
+
+ Some of the reports defined in this section can include a time range
+ filter that is used to restrict the set of calendar object resources
+ returned to just those that overlap the specified time range. The
+ time range filter can be applied to a calendar component as a whole,
+ or to specific calendar component properties with DATE or DATE-TIME
+ value types.
+
+ To determine whether a calendar object resource matches the time
+ range filter element, the start and end times for the targeted
+ component or property are determined and then compared to the
+ requested time range. If there is an overlap with the requested time
+ range, then the calendar object resource matches the filter element.
+ The rules defined in [RFC2445] for determining the actual start and
+ end times of calendar components MUST be used, and these are fully
+ enumerated in Section 9.9 of this document.
+
+
+
+Daboo, et al. Standards Track [Page 32]
+
+RFC 4791 CalDAV March 2007
+
+
+ When such time range filtering is used, special consideration must be
+ given to recurring calendar components, such as VEVENT and VTODO.
+ The server MUST expand recurring components to determine whether any
+ recurrence instances overlap the specified time range. If one or
+ more recurrence instances overlap the time range, then the calendar
+ object resource matches the filter element.
+
+7.5. Searching Text: Collations
+
+ Some of the reports defined in this section do text matches of
+ character strings provided by the client and are compared to stored
+ calendar data. Since iCalendar data is, by default, encoded in the
+ UTF-8 charset and may include characters outside the US-ASCII charset
+ range in some property and parameter values, there is a need to
+ ensure that text matching follows well-defined rules.
+
+ To deal with this, this specification makes use of the IANA Collation
+ Registry defined in [RFC4790] to specify collations that may be used
+ to carry out the text comparison operations with a well-defined rule.
+
+ The comparisons used in CalDAV are all "substring" matches, as per
+ [RFC4790], Section 4.2. Collations supported by the server MUST
+ support "substring" match operations.
+
+ CalDAV servers are REQUIRED to support the "i;ascii-casemap" and
+ "i;octet" collations, as described in [RFC4790], and MAY support
+ other collations.
+
+ Servers MUST advertise the set of collations that they support via
+ the CALDAV:supported-collation-set property defined on any resource
+ that supports reports that use collations.
+
+ Clients MUST only use collations from the list advertised by the
+ server.
+
+ In the absence of a collation explicitly specified by the client, or
+ if the client specifies the "default" collation identifier (as
+ defined in [RFC4790], Section 3.1), the server MUST default to using
+ "i;ascii-casemap" as the collation.
+
+ Wildcards (as defined in [RFC4790], Section 3.2) MUST NOT be used in
+ the collation identifier.
+
+ If the client chooses a collation not supported by the server, the
+ server MUST respond with a CALDAV:supported-collation precondition
+ error response.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 33]
+
+RFC 4791 CalDAV March 2007
+
+
+7.5.1. CALDAV:supported-collation-set Property
+
+ Name: supported-collation-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identifies the set of collations supported by the server
+ for text matching operations.
+
+ Conformance: This property MUST be defined on any resource that
+ supports a report that does text matching. If defined, it MUST be
+ protected and SHOULD NOT be returned by a PROPFIND DAV:allprop
+ request (as defined in Section 12.14.1 of [RFC2518]).
+
+ Description: The CALDAV:supported-collation-set property contains
+ zero or more CALDAV:supported-collation elements, which specify
+ the collection identifiers of the collations supported by the
+ server.
+
+ Definition:
+
+ <!ELEMENT supported-collation-set (supported-collation*)>
+
+ <!ELEMENT supported-collation (#PCDATA)>
+
+ Example:
+
+ <C:supported-collation-set
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:supported-collation>i;ascii-casemap</C:supported-collation>
+ <C:supported-collation>i;octet</C:supported-collation>
+ </C:supported-collation-set>
+
+7.6. Partial Retrieval
+
+ Some calendaring reports defined in this document allow partial
+ retrieval of calendar object resources. A CalDAV client can specify
+ what information to return in the body of a calendaring REPORT
+ request.
+
+ A CalDAV client can request particular WebDAV property values, all
+ WebDAV property values, or a list of the names of the resource's
+ WebDAV properties. A CalDAV client can also request calendar data to
+ be returned and specify whether all calendar components and
+ properties should be returned, or only particular ones. See CALDAV:
+ calendar-data in Section 9.6.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 34]
+
+RFC 4791 CalDAV March 2007
+
+
+ By default, the returned calendar data will include the component
+ that defines the recurrence set, referred to as the "master
+ component", as well as the components that define exceptions to the
+ recurrence set, referred to as the "overridden components".
+
+ A CalDAV client that is only interested in the recurrence instances
+ that overlap a specified time range can request to receive only the
+ "master component", along with the "overridden components" that
+ impact the specified time range, and thus, limit the data returned by
+ the server (see CALDAV:limit-recurrence-set in Section 9.6.6). An
+ overridden component impacts a time range if its current start and
+ end times overlap the time range, or if the original start and end
+ times -- the ones that would have been used if the instance were not
+ overridden -- overlap the time range, or if it affects other
+ instances that overlap the time range.
+
+ A CalDAV client with no support for recurrence properties (i.e.,
+ EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components,
+ or a client unwilling to perform recurrence expansion because of
+ limited processing capability, can request to receive only the
+ recurrence instances that overlap a specified time range as separate
+ calendar components that each define exactly one recurrence instance
+ (see CALDAV:expand in Section 9.6.5.)
+
+ Finally, in the case of VFREEBUSY components, a CalDAV client can
+ request to receive only the FREEBUSY property values that overlap a
+ specified time range (see CALDAV:limit-freebusy-set in
+ Section 9.6.7.)
+
+7.7. Non-Standard Components, Properties, and Parameters
+
+ Servers MUST support the use of non-standard component, property, or
+ parameter names in the CALDAV:calendar-data XML element in
+ calendaring REPORT requests to allow clients to request that non-
+ standard components, properties, and parameters be returned in the
+ calendar data provided in the response.
+
+ Servers MAY support the use of non-standard component, property, or
+ parameter names in the CALDAV:comp-filter, CALDAV:prop-filter, and
+ CALDAV:param-filter XML elements specified in the CALDAV:filter XML
+ element of calendaring REPORT requests.
+
+ Servers MUST fail with the CALDAV:supported-filter precondition if a
+ calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop-
+ filter, or CALDAV:param-filter XML element that makes reference to a
+ non-standard component, property, or parameter name on which the
+ server does not support queries.
+
+
+
+
+Daboo, et al. Standards Track [Page 35]
+
+RFC 4791 CalDAV March 2007
+
+
+7.8. CALDAV:calendar-query REPORT
+
+ The CALDAV:calendar-query REPORT performs a search for all calendar
+ object resources that match a specified filter. The response of this
+ report will contain all the WebDAV properties and calendar object
+ resource data specified in the request. In the case of the CALDAV:
+ calendar-data XML element, one can explicitly specify the calendar
+ components and properties that should be returned in the calendar
+ object resource data that matches the filter.
+
+ The format of this report is modeled on the PROPFIND method. The
+ request and response bodies of the CALDAV:calendar-query REPORT use
+ XML elements that are also used by PROPFIND. In particular, the
+ request can include XML elements to request WebDAV properties to be
+ returned. When that occurs, the response should follow the same
+ behavior as PROPFIND with respect to the DAV:multistatus response
+ elements used to return specific property results. For instance, a
+ request to retrieve the value of a property that does not exist is an
+ error and MUST be noted with a response XML element that contains a
+ 404 (Not Found) status value.
+
+ Support for the CALDAV:calendar-query REPORT is REQUIRED.
+
+ Marshalling:
+
+ The request body MUST be a CALDAV:calendar-query XML element, as
+ defined in Section 9.5.
+
+ The request MAY include a Depth header. If no Depth header is
+ included, Depth:0 is assumed.
+
+ The response body for a successful request MUST be a DAV:
+ multistatus XML element (i.e., the response uses the same format
+ as the response for PROPFIND). In the case where there are no
+ response elements, the returned DAV:multistatus XML element is
+ empty.
+
+ The response body for a successful CALDAV:calendar-query REPORT
+ request MUST contain a DAV:response element for each iCalendar
+ object that matched the search filter. Calendar data is being
+ returned in the CALDAV:calendar-data XML element inside the DAV:
+ propstat XML element.
+
+ Preconditions:
+
+ (CALDAV:supported-calendar-data): The attributes "content-type"
+ and "version" of the CALDAV:calendar-data XML element (see
+
+
+
+
+Daboo, et al. Standards Track [Page 36]
+
+RFC 4791 CalDAV March 2007
+
+
+ Section 9.6) specify a media type supported by the server for
+ calendar object resources.
+
+ (CALDAV:valid-filter): The CALDAV:filter XML element (see
+ Section 9.7) specified in the REPORT request MUST be valid. For
+ instance, a CALDAV:filter cannot nest a <C:comp name="VEVENT">
+ element in a <C:comp name="VTODO"> element, and a CALDAV:filter
+ cannot nest a <C:time-range start="..." end="..."> element in a
+ <C:prop name="SUMMARY"> element.
+
+ (CALDAV:supported-filter): The CALDAV:comp-filter (see
+ Section 9.7.1), CALDAV:prop-filter (see Section 9.7.2), and
+ CALDAV:param-filter (see Section 9.7.3) XML elements used in the
+ CALDAV:filter XML element (see Section 9.7) in the REPORT request
+ only make reference to components, properties, and parameters for
+ which queries are supported by the server, i.e., if the CALDAV:
+ filter element attempts to reference an unsupported component,
+ property, or parameter, this precondition is violated. Servers
+ SHOULD report the CALDAV:comp-filter, CALDAV:prop-filter, or
+ CALDAV:param-filter for which it does not provide support.
+
+ <!ELEMENT supported-filter (comp-filter*,
+ prop-filter*,
+ param-filter*)>
+
+ (CALDAV:valid-calendar-data): The time zone specified in the
+ REPORT request MUST be a valid iCalendar object containing a
+ single valid VTIMEZONE component.
+
+ (CALDAV:min-date-time): Any XML element specifying a range of time
+ MUST have its start or end DATE or DATE-TIME values greater than
+ or equal to the value of the CALDAV:min-date-time property value
+ (Section 5.2.6) on the calendar collections being targeted by the
+ REPORT request;
+
+ (CALDAV:max-date-time): Any XML element specifying a range of time
+ MUST have its start or end DATE or DATE-TIME values less than or
+ equal to the value of the CALDAV:max-date-time property value
+ (Section 5.2.7) on the calendar collections being targeted by the
+ REPORT request;
+
+ (CALDAV:supported-collation): Any XML attribute specifying a
+ collation MUST specify a collation supported by the server as
+ described in Section 7.5.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 37]
+
+RFC 4791 CalDAV March 2007
+
+
+ Postconditions:
+
+ (DAV:number-of-matches-within-limits): The number of matching
+ calendar object resources must fall within server-specific,
+ predefined limits. For example, this condition might be triggered
+ if a search specification would cause the return of an extremely
+ large number of responses.
+
+7.8.1. Example: Partial Retrieval of Events by Time Range
+
+ In this example, the client requests the server to return specific
+ components and properties of the VEVENT components that overlap the
+ time range from January 4, 2006, at 00:00:00 A.M. UTC to January 5,
+ 2006, at 00:00:00 A.M. UTC. In addition, the DAV:getetag property is
+ also requested and returned as part of the response. Note that the
+ first calendar object returned is a recurring event whose first
+ instance lies outside the requested time range, but whose third
+ instance does overlap the time range. Note that due to the CALDAV:
+ calendar-data element restrictions, the DTSTAMP property in VEVENT
+ components has not been returned, and the only property returned in
+ the VCALENDAR object is VERSION.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 38]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <D:getetag/>
+ <C:calendar-data>
+ <C:comp name="VCALENDAR">
+ <C:prop name="VERSION"/>
+ <C:comp name="VEVENT">
+ <C:prop name="SUMMARY"/>
+ <C:prop name="UID"/>
+ <C:prop name="DTSTART"/>
+ <C:prop name="DTEND"/>
+ <C:prop name="DURATION"/>
+ <C:prop name="RRULE"/>
+ <C:prop name="RDATE"/>
+ <C:prop name="EXRULE"/>
+ <C:prop name="EXDATE"/>
+ <C:prop name="RECURRENCE-ID"/>
+ </C:comp>
+ <C:comp name="VTIMEZONE"/>
+ </C:comp>
+ </C:calendar-data>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:time-range start="20060104T000000Z"
+ end="20060105T000000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+
+
+Daboo, et al. Standards Track [Page 39]
+
+RFC 4791 CalDAV March 2007
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd2"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTART;TZID=US/Eastern:20060102T120000
+ DURATION:PT1H
+ RRULE:FREQ=DAILY;COUNT=5
+ SUMMARY:Event #2
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTART;TZID=US/Eastern:20060104T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTART;TZID=US/Eastern:20060106T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060106T120000
+ SUMMARY:Event #2 bis bis
+ UID:00959BC664CA650E933C892C@example.com
+
+
+
+Daboo, et al. Standards Track [Page 40]
+
+RFC 4791 CalDAV March 2007
+
+
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+
+
+
+
+Daboo, et al. Standards Track [Page 41]
+
+RFC 4791 CalDAV March 2007
+
+
+7.8.2. Example: Partial Retrieval of Recurring Events
+
+ In this example, the client requests the server to return VEVENT
+ components that overlap the time range from January 3, 2006, at 00:
+ 00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC. Use of the
+ CALDAV:limit-recurrence-set element causes the server to only return
+ overridden recurrence components that overlap the time range
+ specified in that element or that affect other instances that overlap
+ the time range (e.g., in the case of a THISANDFUTURE behavior). In
+ this example, the first overridden component in the matching resource
+ is returned, but the second one is not.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <C:calendar-data>
+ <C:limit-recurrence-set start="20060103T000000Z"
+ end="20060105T000000Z"/>
+ </C:calendar-data>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:time-range start="20060103T000000Z"
+ end="20060105T000000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+
+
+
+Daboo, et al. Standards Track [Page 42]
+
+RFC 4791 CalDAV March 2007
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd2"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060102T120000
+ DURATION:PT1H
+ RRULE:FREQ=DAILY;COUNT=5
+ SUMMARY:Event #2
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060104T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+
+
+
+Daboo, et al. Standards Track [Page 43]
+
+RFC 4791 CalDAV March 2007
+
+
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+
+
+
+Daboo, et al. Standards Track [Page 44]
+
+RFC 4791 CalDAV March 2007
+
+
+ </D:response>
+ </D:multistatus>
+
+7.8.3. Example: Expanded Retrieval of Recurring Events
+
+ In this example, the client requests the server to return VEVENT
+ components that overlap the time range from January 2, 2006, at 00:
+ 00:00 A.M. UTC to January 5, 2006, at 00:00:00 A.M. UTC and to return
+ recurring calendar components expanded into individual recurrence
+ instance calendar components. Use of the CALDAV:expand element
+ causes the server to only return overridden recurrence instances that
+ overlap the time range specified in that element.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <C:calendar-data>
+ <C:expand start="20060103T000000Z"
+ end="20060105T000000Z"/>
+ </C:calendar-data>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:time-range start="20060103T000000Z"
+ end="20060105T000000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+
+
+Daboo, et al. Standards Track [Page 45]
+
+RFC 4791 CalDAV March 2007
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd2"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART:20060103T170000
+ DURATION:PT1H
+ RECURRENCE-ID:20060103T170000
+ SUMMARY:Event #2
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART:20060104T190000
+ DURATION:PT1H
+ RECURRENCE-ID:20060104T170000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART:20060104T150000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+
+
+
+Daboo, et al. Standards Track [Page 46]
+
+RFC 4791 CalDAV March 2007
+
+
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 47]
+
+RFC 4791 CalDAV March 2007
+
+
+7.8.4. Example: Partial Retrieval of Stored Free Busy Components
+
+ In this example, the client requests the server to return the
+ VFREEBUSY components that have free busy information that overlap the
+ time range from January 2, 2006, at 00:00:00 A.M. UTC (inclusively)
+ to January 3, 2006, at 00:00:00 A.M. UTC (exclusively). Use of the
+ CALDAV:limit-freebusy-set element causes the server to only return
+ the FREEBUSY property values that overlap the time range specified in
+ that element. Note that this is not an example of discovering when
+ the calendar owner is busy.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <C:calendar-data>
+ <C:limit-freebusy-set start="20060102T000000Z"
+ end="20060103T000000Z"/>
+ </C:calendar-data>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VFREEBUSY">
+ <C:time-range start="20060102T000000Z"
+ end="20060103T000000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 48]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd8"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VFREEBUSY
+ ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
+ UID:76ef34-54a3d2@example.com
+ DTSTAMP:20050530T123421Z
+ DTSTART:20060101T100000Z
+ DTEND:20060108T100000Z
+ FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 49]
+
+RFC 4791 CalDAV March 2007
+
+
+7.8.5. Example: Retrieval of To-Dos by Alarm Time Range
+
+ In this example, the client requests the server to return the VTODO
+ components that have an alarm trigger scheduled in the specified time
+ range.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VTODO">
+ <C:comp-filter name="VALARM">
+ <C:time-range start="20060106T100000Z"
+ end="20060107T100000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 50]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd4"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ DTSTAMP:20060205T235300Z
+ DUE;TZID=US/Eastern:20060106T120000
+ LAST-MODIFIED:20060205T235308Z
+ SEQUENCE:1
+ STATUS:NEEDS-ACTION
+ SUMMARY:Task #2
+ UID:E10BA47467C5C69BB74E8720@example.com
+ BEGIN:VALARM
+ ACTION:AUDIO
+ TRIGGER;RELATED=START:-PT10M
+ END:VALARM
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+7.8.6. Example: Retrieval of Event by UID
+
+ In this example, the client requests the server to return the VEVENT
+ component that has the UID property set to
+ "DC6C50A017428C5216A2F1CD@example.com".
+
+ See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 51]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:prop-filter name="UID">
+ <C:text-match collation="i;octet"
+ >DC6C50A017428C5216A2F1CD@example.com</C:text-match>
+ </C:prop-filter>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+
+
+
+Daboo, et al. Standards Track [Page 52]
+
+RFC 4791 CalDAV March 2007
+
+
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+7.8.7. Example: Retrieval of Events by PARTSTAT
+
+ In this example, the client requests the server to return the VEVENT
+ components that have the ATTENDEE property with the value
+ "mailto:lisa@example.com" and for which the PARTSTAT parameter is set
+ to NEEDS-ACTION.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 53]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:prop-filter name="ATTENDEE">
+ <C:text-match collation="i;ascii-casemap"
+ >mailto:lisa@example.com</C:text-match>
+ <C:param-filter name="PARTSTAT">
+ <C:text-match collation="i;ascii-casemap"
+ >NEEDS-ACTION</C:text-match>
+ </C:param-filter>
+ </C:prop-filter>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+
+
+
+Daboo, et al. Standards Track [Page 54]
+
+RFC 4791 CalDAV March 2007
+
+
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+7.8.8. Example: Retrieval of Events Only
+
+ In this example, the client requests the server to return all VEVENT
+ components.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 55]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT"/>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd1"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+
+
+
+Daboo, et al. Standards Track [Page 56]
+
+RFC 4791 CalDAV March 2007
+
+
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001102Z
+ DTSTART;TZID=US/Eastern:20060102T100000
+ DURATION:PT1H
+ SUMMARY:Event #1
+ Description:Go Steelers!
+ UID:74855313FA803DA593CD579A@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd2"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+
+
+
+Daboo, et al. Standards Track [Page 57]
+
+RFC 4791 CalDAV March 2007
+
+
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060102T120000
+ DURATION:PT1H
+ RRULE:FREQ=DAILY;COUNT=5
+ SUMMARY:Event #2
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060104T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060106T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060106T120000
+ SUMMARY:Event #2 bis bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+
+
+
+Daboo, et al. Standards Track [Page 58]
+
+RFC 4791 CalDAV March 2007
+
+
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+7.8.9. Example: Retrieval of All Pending To-Dos
+
+ In this example, the client requests the server to return all VTODO
+ components that do not include a COMPLETED property and do not have a
+ STATUS property value matching CANCELLED, i.e., VTODOs that still
+ need to be worked on.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 59]
+
+RFC 4791 CalDAV March 2007
+
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VTODO">
+ <C:prop-filter name="COMPLETED">
+ <C:is-not-defined/>
+ </C:prop-filter>
+ <C:prop-filter name="STATUS">
+ <C:text-match
+ negate-condition="yes">CANCELLED</C:text-match>
+ </C:prop-filter>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd4"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+
+
+
+Daboo, et al. Standards Track [Page 60]
+
+RFC 4791 CalDAV March 2007
+
+
+ DTSTAMP:20060205T235335Z
+ DUE;VALUE=DATE:20060104
+ STATUS:NEEDS-ACTION
+ SUMMARY:Task #1
+ UID:DDDEEB7915FA61233B861457@example.com
+ BEGIN:VALARM
+ ACTION:AUDIO
+ TRIGGER;RELATED=START:-PT10M
+ END:VALARM
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd5"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ DTSTAMP:20060205T235300Z
+ DUE;VALUE=DATE:20060106
+ LAST-MODIFIED:20060205T235308Z
+ SEQUENCE:1
+ STATUS:NEEDS-ACTION
+ SUMMARY:Task #2
+ UID:E10BA47467C5C69BB74E8720@example.com
+ BEGIN:VALARM
+ ACTION:AUDIO
+ TRIGGER;RELATED=START:-PT10M
+ END:VALARM
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ </D:multistatus>
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 61]
+
+RFC 4791 CalDAV March 2007
+
+
+7.8.10. Example: Attempt to Query Unsupported Property
+
+ In this example, the client requests the server to return all VEVENT
+ components that include an X-ABC-GUID property with a value matching
+ "ABC". However, the server does not support querying that non-
+ standard property, and instead returns an error response.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop xmlns:D="DAV:">
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:prop-filter name="X-ABC-GUID">
+ <C:text-match>ABC</C:text-match>
+ </C:prop-filter>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 403 Forbidden
+ Date: Sat, 11 Nov 2005 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:error>
+ <C:supported-filter>
+ <C:prop-filter name="X-ABC-GUID"/>
+ </C:supported-filter>
+ </D:error>
+
+
+
+
+Daboo, et al. Standards Track [Page 62]
+
+RFC 4791 CalDAV March 2007
+
+
+7.9. CALDAV:calendar-multiget REPORT
+
+ The CALDAV:calendar-multiget REPORT is used to retrieve specific
+ calendar object resources from within a collection, if the Request-
+ URI is a collection, or to retrieve a specific calendar object
+ resource, if the Request-URI is a calendar object resource. This
+ report is similar to the CALDAV:calendar-query REPORT (see
+ Section 7.8), except that it takes a list of DAV:href elements,
+ instead of a CALDAV:filter element, to determine which calendar
+ object resources to return.
+
+ Support for the CALDAV:calendar-multiget REPORT is REQUIRED.
+
+ Marshalling:
+
+ The request body MUST be a CALDAV:calendar-multiget XML element
+ (see Section 9.10). If the Request-URI is a collection resource,
+ then the DAV:href elements MUST refer to calendar object resources
+ within that collection, and they MAY refer to calendar object
+ resources at any depth within the collection. As a result, the
+ "Depth" header MUST be ignored by the server and SHOULD NOT be
+ sent by the client. If the Request-URI refers to a non-collection
+ resource, then there MUST be a single DAV:href element that is
+ equivalent to the Request-URI.
+
+ The response body for a successful request MUST be a DAV:
+ multistatus XML element.
+
+ The response body for a successful CALDAV:calendar-multiget REPORT
+ request MUST contain a DAV:response element for each calendar
+ object resource referenced by the provided set of DAV:href
+ elements. Calendar data is being returned in the CALDAV:calendar-
+ data element inside the DAV:prop element.
+
+ In the case of an error accessing any of the provided DAV:href
+ resources, the server MUST return the appropriate error status
+ code in the DAV:status element of the corresponding DAV:response
+ element.
+
+ Preconditions:
+
+ (CALDAV:supported-calendar-data): The attributes "content-type"
+ and "version" of the CALDAV:calendar-data XML elements (see
+ Section 9.6) specify a media type supported by the server for
+ calendar object resources.
+
+ (CALDAV:min-date-time): Any XML element specifying a range of time
+ MUST have its start or end DATE or DATE-TIME values greater than
+
+
+
+Daboo, et al. Standards Track [Page 63]
+
+RFC 4791 CalDAV March 2007
+
+
+ or equal to the value of the CALDAV:min-date-time property value
+ (Section 5.2.6) on the calendar collections being targeted by the
+ REPORT request;
+
+ (CALDAV:max-date-time): Any XML element specifying a range of time
+ MUST have its start or end DATE or DATE-TIME values less than or
+ equal to the value of the CALDAV:max-date-time property value
+ (Section 5.2.7) on the calendar collections being targeted by the
+ REPORT request;
+
+ Postconditions:
+
+ None.
+
+7.9.1. Example: Successful CALDAV:calendar-multiget REPORT
+
+ In this example, the client requests the server to return specific
+ properties of the VEVENT components referenced by specific URIs. In
+ addition, the DAV:getetag property is also requested and returned as
+ part of the response. Note that in this example, the resource at
+ http://cal.example.com/bernard/work/mtg1.ics does not exist,
+ resulting in an error status response.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-multiget xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <D:href>/bernard/work/abcd1.ics</D:href>
+ <D:href>/bernard/work/mtg1.ics</D:href>
+ </C:calendar-multiget>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: application/xml; charset="utf-8"
+
+
+
+Daboo, et al. Standards Track [Page 64]
+
+RFC 4791 CalDAV March 2007
+
+
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd1"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001102Z
+ DTSTART;TZID=US/Eastern:20060102T100000
+ DURATION:PT1H
+ SUMMARY:Event #1
+ Description:Go Steelers!
+ UID:74855313FA803DA593CD579A@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/mtg1.ics</D:href>
+ <D:status>HTTP/1.1 404 Not Found</D:status>
+
+
+
+Daboo, et al. Standards Track [Page 65]
+
+RFC 4791 CalDAV March 2007
+
+
+ </D:response>
+ </D:multistatus>
+
+7.10. CALDAV:free-busy-query REPORT
+
+ The CALDAV:free-busy-query REPORT generates a VFREEBUSY component
+ containing free busy information for all the calendar object
+ resources targeted by the request and that have the CALDAV:read-free-
+ busy or DAV:read privilege granted to the current user.
+
+ Only VEVENT components without a TRANSP property or with the TRANSP
+ property set to OPAQUE, and VFREEBUSY components SHOULD be considered
+ in generating the free busy time information.
+
+ In the case of VEVENT components, the free or busy time type (FBTYPE)
+ of the FREEBUSY properties in the returned VFREEBUSY component SHOULD
+ be derived from the value of the TRANSP and STATUS properties, as
+ outlined in the table below:
+
+ +---------------------------++------------------+
+ | VEVENT || VFREEBUSY |
+ +-------------+-------------++------------------+
+ | TRANSP | STATUS || FBTYPE |
+ +=============+=============++==================+
+ | | CONFIRMED || BUSY |
+ | | (default) || |
+ | OPAQUE +-------------++------------------+
+ | (default) | CANCELLED || FREE |
+ | +-------------++------------------+
+ | | TENTATIVE || BUSY-TENTATIVE |
+ | +-------------++------------------+
+ | | x-name || BUSY or |
+ | | || x-name |
+ +-------------+-------------++------------------+
+ | | CONFIRMED || |
+ | TRANSPARENT | CANCELLED || FREE |
+ | | TENTATIVE || |
+ | | x-name || |
+ +-------------+-------------++------------------+
+
+ Duplicate busy time periods with the same FBTYPE parameter value
+ SHOULD NOT be specified in the returned VFREEBUSY component. Servers
+ SHOULD coalesce consecutive or overlapping busy time periods of the
+ same type. Busy time periods with different FBTYPE parameter values
+ MAY overlap.
+
+ Support for the CALDAV:free-busy-query REPORT is REQUIRED.
+
+
+
+
+Daboo, et al. Standards Track [Page 66]
+
+RFC 4791 CalDAV March 2007
+
+
+ Marshalling:
+
+ The request body MUST be a CALDAV:free-busy-query XML element (see
+ Section 9.11), which MUST contain exactly one CALDAV:time-range
+ XML element, as defined in Section 9.9.
+
+ The request MAY include a Depth header. If no Depth header is
+ included, Depth:0 is assumed.
+
+ The response body for a successful request MUST be an iCalendar
+ object that contains exactly one VFREEBUSY component that
+ describes the busy time intervals for the calendar object
+ resources containing VEVENT, or VFREEBUSY components that satisfy
+ the Depth value and for which the current user is at least granted
+ the CALDAV:read-free-busy privilege. If no calendar object
+ resources are found to satisfy these conditions, a VFREEBUSY
+ component with no FREEBUSY property MUST be returned. This report
+ only returns busy time information. Free time information can be
+ inferred from the returned busy time information.
+
+ If the current user is not granted the CALDAV:read-free-busy or
+ DAV:read privileges on the Request-URI, the CALDAV:free-busy-query
+ REPORT request MUST fail and return a 404 (Not Found) status
+ value. This restriction will prevent users from discovering URLs
+ of resources for which they are only granted the CALDAV:read-free-
+ busy privilege.
+
+ The CALDAV:free-busy-query REPORT request can only be run against
+ a collection (either a regular collection or a calendar
+ collection). An attempt to run the report on a calendar object
+ resource MUST fail and return a 403 (Forbidden) status value.
+
+ Preconditions:
+
+ None.
+
+ Postconditions:
+
+ (DAV:number-of-matches-within-limits): The number of matching
+ calendar object resources must fall within server-specific,
+ predefined limits. For example, this postcondition might fail if
+ the specified CALDAV:time-range would cause an extremely large
+ number of calendar object resources to be considered in computing
+ the response.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 67]
+
+RFC 4791 CalDAV March 2007
+
+
+7.10.1. Example: Successful CALDAV:free-busy-query REPORT
+
+ In this example, the client requests the server to return free busy
+ information on the calendar collection /bernard/work/, between 9:00
+ A.M. and 5:00 P.M. EST (2:00 P.M. and 10:00 P.M. UTC) on the January
+ 4, 2006. The server responds, indicating two busy time intervals of
+ one hour, one of which is tentative.
+
+ See Appendix B for the calendar data being targeted by this example.
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:time-range start="20060104T140000Z"
+ end="20060105T220000Z"/>
+ </C:free-busy-query>
+
+ >> Response <<
+
+ HTTP/1.1 200 OK
+ Date: Sat, 11 Nov 2006 09:32:12 GMT
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Server//EN
+ BEGIN:VFREEBUSY
+ DTSTAMP:20050125T090000Z
+ DTSTART:20060104T140000Z
+ DTEND:20060105T220000Z
+ FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
+ FREEBUSY:20060104T190000Z/PT1H
+ END:VFREEBUSY
+ END:VCALENDAR
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 68]
+
+RFC 4791 CalDAV March 2007
+
+
+8. Guidelines
+
+8.1. Client-to-Client Interoperability
+
+ There are a number of actions clients can take that will be legal
+ (the server will not return errors), but that can degrade
+ interoperability with other client implementations accessing the same
+ data. For example, a recurrence rule could be replaced with a set of
+ recurrence dates, a single recurring event could be replaced with a
+ set of independent resources to represent each recurrence, or the
+ start/end time values can be translated from the original time zone
+ to another time zone. Although this advice amounts to iCalendar
+ interoperability best practices and is not limited only to CalDAV
+ usage, interoperability problems are likely to be more evident in
+ CalDAV use cases.
+
+8.2. Synchronization Operations
+
+ WebDAV already provides functionality required to synchronize a
+ collection or set of collections, to make changes offline, and
+ provides a simple way to resolve conflicts when reconnected. ETags
+ are the key to making this work, but these are not required of all
+ WebDAV servers. Since offline functionality is more important to
+ calendar applications than to some other WebDAV applications, CalDAV
+ servers MUST support ETags, as specified in Section 5.3.4.
+
+8.2.1. Use of Reports
+
+8.2.1.1. Restrict the Time Range
+
+ The reports provided in CalDAV can be used by clients to optimize
+ their performance in terms of network bandwidth usage and resource
+ consumption on the local client machine. Both are certainly major
+ considerations for mobile or handheld devices with limited capacity,
+ but they are also relevant to desktop client applications in cases
+ where the calendar collections contain large amounts of data.
+
+ Typically, clients present calendar data to users in views that span
+ a finite time interval, so whenever possible, clients should only
+ retrieve calendar components from the server using CALDAV:calendar-
+ query REPORT, combined with a CALDAV:time-range element, to limit the
+ set of returned components to just those needed to populate the
+ current view.
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 69]
+
+RFC 4791 CalDAV March 2007
+
+
+8.2.1.2. Synchronize by Time Range
+
+ Typically in a calendar, historical data (events, to-dos, etc. that
+ have completed prior to the current date) do not change, though they
+ may be deleted. As a result, a client can speed up the
+ synchronization process by only considering data for the present time
+ and the future up to a reasonable limit (e.g., one week, one month).
+ If the user then tries to examine a portion of the calendar outside
+ the range that has been synchronized, the client can perform another
+ synchronization operation on the new time interval being examined.
+ This "just-in-time" synchronization can minimize bandwidth for common
+ user interaction behaviors.
+
+8.2.1.3. Synchronization Process
+
+ If a client wants to support calendar data synchronization, as
+ opposed to downloading calendar data each time it is needed, the
+ client needs to cache the calendar object resource's URI and ETag,
+ along with the actual calendar data. While the URI remains static
+ for the lifetime of the calendar object resource, the ETag will
+ change with each successive change to the calendar object resource.
+ Thus, to synchronize a local data cache with the server, the client
+ can first fetch the URI/ETag pairs for the time interval being
+ considered, and compare those results with the cached data. Any
+ cached component whose ETag differs from that on the server needs to
+ be refreshed.
+
+ In order to properly detect the changes between the server and client
+ data, the client will need to keep a record of which calendar object
+ resources have been created, changed, or deleted since the last
+ synchronization operation so that it can reconcile those changes with
+ the data on the server.
+
+ Here's an example of how to do that:
+
+ The client issues a CALDAV:calendar-query REPORT request for a
+ specific time range and asks for only the DAV:getetag property to be
+ returned:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 70]
+
+RFC 4791 CalDAV March 2007
+
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <D:getetag/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR">
+ <C:comp-filter name="VEVENT">
+ <C:time-range start="20040902T000000Z"
+ end="20040903T000000Z"/>
+ </C:comp-filter>
+ </C:comp-filter>
+ </C:filter>
+ </C:calendar-query>
+
+ The client then uses the results to determine which calendar object
+ resources have changed, been created, or deleted on the server, and
+ how those relate to locally cached calendar object resources that may
+ have changed, been created, or deleted. If the client determines
+ that there are calendar object resources on the server that need to
+ be fetched, the client issues a CALDAV:calendar-multiget REPORT
+ request to fetch its calendar data:
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-multiget xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <D:href>/bernard/work/abcd1.ics</D:href>
+ <D:href>/bernard/work/mtg1.ics</D:href>
+ </C:calendar-multiget>
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 71]
+
+RFC 4791 CalDAV March 2007
+
+
+8.2.2. Restrict the Properties Returned
+
+ A client may not need all the calendar properties of a calendar
+ object resource when presenting information to the user. Since some
+ calendar property values can be large (e.g., ATTACH or ATTENDEE), a
+ client can choose to restrict the calendar properties to be returned
+ in a calendaring REPORT request to those it knows it will use.
+
+ However, if a client needs to make a change to a calendar object
+ resource, it can only change the entire calendar object resource via
+ a PUT request. There is currently no way to incrementally make a
+ change to a set of calendar properties of a calendar object resource.
+ As a result, the client will have to get the entire calendar object
+ resource that is being changed.
+
+8.3. Use of Locking
+
+ WebDAV locks can be used to prevent two clients that are modifying
+ the same resource from either overwriting each others' changes
+ (though that problem can also be solved by using ETags) or wasting
+ time making changes that will conflict with another set of changes.
+ In a multi-user calendar system, an interactive calendar client could
+ lock an event while the user is editing the event, and unlock the
+ event when the user finishes or cancels. Locks can also be used to
+ prevent changes while data is being reorganized. For example, a
+ calendar client might lock two calendar collections prior to moving a
+ bunch of calendar resources from one to another.
+
+ Clients are responsible for requesting a lock timeout period that is
+ appropriate to the use case. When the user explicitly decides to
+ reserve a resource and prevent other changes, a long timeout might be
+ appropriate, but in cases where the client automatically decides to
+ lock the resource, the timeout should be short (and the client can
+ always refresh the lock should it need to). A short lock timeout
+ means that if the client is unable to remove the lock, the other
+ calendar users aren't prevented from making changes.
+
+8.4. Finding Calendars
+
+ Much of the time, a calendar client (or agent) will discover a new
+ calendar's location by being provided directly with the URL. For
+ example, a user will type his or her own calendar location into
+ client configuration information or copy and paste a URL from email
+ into the calendar application. The client need only confirm that the
+ URL points to a resource that is a calendar collection. The client
+ may also be able to browse WebDAV collections to find calendar
+ collections.
+
+
+
+
+Daboo, et al. Standards Track [Page 72]
+
+RFC 4791 CalDAV March 2007
+
+
+ The choice of HTTP URLs means that calendar object resources are
+ backward compatible with existing software, but does have the
+ disadvantage that existing software does not usually know to look at
+ the OPTIONS response to that URL to determine what can be done with
+ it. This is somewhat of a barrier for WebDAV usage as well as with
+ CalDAV usage. This specification does not offer a way through this
+ other than making the information available in the OPTIONS response
+ should this be requested.
+
+ For calendar sharing and scheduling use cases, one might wish to find
+ the calendar belonging to another user. If the other user has a
+ calendar in the same repository, that calendar can be found by using
+ the principal namespace required by WebDAV ACL support. For other
+ cases, the authors have no universal solution, but implementers can
+ consider whether to use vCard [RFC2426] or LDAP [RFC4511] standards
+ together with calendar attributes [RFC2739].
+
+ Because CalDAV requires servers to support WebDAV ACL [RFC3744],
+ including principal namespaces, and with the addition of the CALDAV:
+ calendar-home-set property, there are a couple options for CalDAV
+ clients to find one's own calendar or another user's calendar.
+
+ In this case, a DAV:principal-match REPORT is used to find a named
+ property (the CALDAV:calendar-home-set) on the Principal-URL of the
+ current user. Using this, a WebDAV client can learn "who am I" and
+ "where are my calendars". The REPORT request body looks like this:
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:principal-match xmlns:D="DAV:">
+ <D:self/>
+ <D:prop>
+ <C:calendar-home-set
+ xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+ </D:prop>
+ </D:principal-match>
+
+ To find other users' calendars, the DAV:principal-property-search
+ REPORT can be used to filter on some properties and return others.
+ To search for a calendar owned by a user named "Laurie", the REPORT
+ request body would look like this:
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 73]
+
+RFC 4791 CalDAV March 2007
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:principal-property-search xmlns:D="DAV:">
+ <D:property-search>
+ <D:prop>
+ <D:displayname/>
+ </D:prop>
+ <D:match>Laurie</D:match>
+ </D:property-search>
+ <D:prop>
+ <C:calendar-home-set
+ xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+ <D:displayname/>
+ </D:prop>
+ </D:principal-property-search>
+
+ The server performs a case-sensitive or caseless search for a
+ matching string subset of "Laurie" within the DAV:displayname
+ property. Thus, the server might return "Laurie Dusseault", "Laurier
+ Desruisseaux", or "Wilfrid Laurier" as matching DAV:displayname
+ values, and return the calendars for each of these.
+
+8.5. Storing and Using Attachments
+
+ CalDAV clients MAY create attachments in calendar components either
+ as inline or external. This section contains some guidelines for
+ creating and managing attachments.
+
+8.5.1. Inline Attachments
+
+ CalDAV clients MUST support inline attachments as specified in
+ iCalendar [RFC2445]. CalDAV servers MUST support inline attachments,
+ so clients can rely on being able to create attachments this way. On
+ the other hand, inline attachments have some drawbacks:
+
+ o Servers MAY impose limitations on the size of calendar object
+ resources (i.e., refusing PUT requests of very large iCalendar
+ objects). Servers that impose such limitations MUST use the
+ CALDAV:max-resource-size property on a calendar collection to
+ inform the client as to what the limitation is (see
+ Section 5.2.5).
+
+ o Servers MAY impose storage quota limitations on calendar
+ collections (See [RFC4331]).
+
+ o Any change to a calendar object resource containing an inline
+ attachment requires the entire inline attachment to be re-
+ uploaded.
+
+
+
+
+Daboo, et al. Standards Track [Page 74]
+
+RFC 4791 CalDAV March 2007
+
+
+ o Clients synchronizing a changed calendar object resource have to
+ download the entire calendar object resource, even if the
+ attachment is unchanged.
+
+8.5.2. External Attachments
+
+ CalDAV clients SHOULD support downloading of external attachments
+ referenced by arbitrary URI schemes, by either processing them
+ directly, or by passing the attachment URI to a suitable "helper
+ application" for processing, if such an application exists. CalDAV
+ clients MUST support downloading of external attachments referenced
+ by the "http" or "https" URI schemes. An external attachment could
+ be:
+
+ o In a collection in the calendar collection containing the calendar
+ object resource;
+
+ o Somewhere else in the same repository that hosts the calendar
+ collection; or
+
+ o On an HTTP or FTP server elsewhere.
+
+ CalDAV servers MAY provide support for child collections in calendar
+ collections. CalDAV servers MAY allow the MKCOL method to create
+ child collections in calendar collections. Child collections of
+ calendar collections MAY contain any type of resource except calendar
+ collections that they MUST NOT contain. Some CalDAV servers won't
+ allow child collections in calendar collections, and it may be
+ possible on such a server to discover other locations where
+ attachments can be stored.
+
+ Clients are entirely responsible for maintaining reference
+ consistency with calendar components that link to external
+ attachments. A client deleting a calendar component with an external
+ attachment might therefore also delete the attachment if that's
+ appropriate; however, appropriateness can be very hard to determine.
+ A new component might easily reference some pre-existing Web resource
+ that is intended to have independent existence from the calendar
+ component (the "attachment" could be a major proposal to be discussed
+ in a meeting, for instance). Best practices will probably emerge and
+ should probably be documented, but for now, clients should be wary of
+ engaging in aggressive "cleanup" of external attachments. A client
+ could involve the user in making decisions about removing
+ unreferenced documents, or a client could be conservative in only
+ deleting attachments it had created.
+
+ Also, clients are responsible for consistency of permissions when
+ using external attachments. One reason for servers to support the
+
+
+
+Daboo, et al. Standards Track [Page 75]
+
+RFC 4791 CalDAV March 2007
+
+
+ storage of attachments within child collections of calendar
+ collections is that ACL inheritance might make it easier to grant the
+ same permissions to attachments that are granted on the calendar
+ collection. Otherwise, it can be very difficult to keep permissions
+ synchronized. With attachments stored on separate repositories, it
+ can be impossible to keep permissions consistent -- the two
+ repositories may not support the same permissions or have the same
+ set of principals. Some systems have used tickets or other anonymous
+ access control mechanisms to provide partially satisfactory solutions
+ to these kinds of problems.
+
+8.6. Storing and Using Alarms
+
+ Note that all CalDAV calendar collections (including those the user
+ might treat as public or group calendars) can contain alarm
+ information on events and to-dos. Users can synchronize a calendar
+ between multiple devices and decide to have alarms execute on a
+ different device than the device that created the alarm. Not all
+ alarm action types are completely interoperable (e.g., those that
+ name a sound file to play).
+
+ When the action is AUDIO and the client is configured to execute
+ the alarm, the client SHOULD play the suggested sound if it's
+ available or play another sound, but SHOULD NOT rewrite the alarm
+ just to replace the suggested sound with a sound that's locally
+ available.
+
+ When the action is DISPLAY and the client is configured to execute
+ the alarm, the client SHOULD execute a display alarm by displaying
+ according to the suggested description or some reasonable
+ replacement, but SHOULD NOT rewrite the alarm for its own
+ convenience.
+
+ When the action is EMAIL and the client is incapable of sending
+ email, it SHOULD ignore the alarm, but it MUST continue to
+ synchronize the alarm itself.
+
+ This specification makes no recommendations about executing alarms
+ of type PROCEDURE, except to note that clients are advised to take
+ care to avoid creating security holes by executing these.
+
+ Non-interoperable alarm information (e.g., should somebody define a
+ color to be used in a display alarm) should be put in non-standard
+ properties inside the VALARM component in order to keep the basic
+ alarm usable on all devices.
+
+ Clients that allow changes to calendar object resources MUST
+ synchronize the alarm data that already exists in the resources.
+
+
+
+Daboo, et al. Standards Track [Page 76]
+
+RFC 4791 CalDAV March 2007
+
+
+ Clients MAY execute alarms that are downloaded in this fashion,
+ possibly based on user preference. If a client is only doing read
+ operations on a calendar and there is no risk of losing alarm
+ information, then the client MAY discard alarm information.
+
+ This specification makes no attempt to provide multi-user alarms on
+ group calendars or to find out for whom an alarm is intended.
+ Addressing those issues might require extensions to iCalendar; for
+ example, to store alarms per-user, or to indicate for which user a
+ VALARM was intended. In the meantime, clients might maximize
+ interoperability by generally not uploading alarm information to
+ public, group, or resource calendars.
+
+9. XML Element Definitions
+
+9.1. CALDAV:calendar XML Element
+
+ Name: calendar
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies the resource type of a calendar collection.
+
+ Description: See Section 4.2.
+
+ Definition:
+
+ <!ELEMENT calendar EMPTY>
+
+9.2. CALDAV:mkcalendar XML Element
+
+ Name: mkcalendar
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a request that includes the WebDAV property
+ values to be set for a calendar collection resource when it is
+ created.
+
+ Description: See Section 5.3.1.
+
+ Definition:
+
+ <!ELEMENT mkcalendar (DAV:set)>
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 77]
+
+RFC 4791 CalDAV March 2007
+
+
+9.3. CALDAV:mkcalendar-response XML Element
+
+ Name: mkcalendar-response
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a response body for a successful MKCALENDAR
+ request.
+
+ Description: See Section 5.3.1.
+
+ Definition:
+
+ <!ELEMENT mkcalendar-response ANY>
+
+9.4. CALDAV:supported-collation XML Element
+
+ Name: supported-collation
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identifies a single collation via its collation identifier,
+ as defined by [RFC4790].
+
+ Description: The CALDAV:supported-collation contains the text of a
+ collation identifier, as described in Section 7.5.1.
+
+ Definition:
+
+ <!ELEMENT supported-collation (#PCDATA)>
+ PCDATA value: collation identifier
+
+9.5. CALDAV:calendar-query XML Element
+
+ Name: calendar-query
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Defines a report for querying calendar object resources.
+
+ Description: See Section 7.8.
+
+ Definition:
+
+ <!ELEMENT calendar-query ((DAV:allprop |
+ DAV:propname |
+ DAV:prop)?, filter, timezone?)>
+
+
+
+
+Daboo, et al. Standards Track [Page 78]
+
+RFC 4791 CalDAV March 2007
+
+
+9.6. CALDAV:calendar-data XML Element
+
+ Name: calendar-data
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specified one of the following:
+
+ 1. A supported media type for calendar object resources when
+ nested in the CALDAV:supported-calendar-data property;
+
+ 2. The parts of a calendar object resource should be returned by
+ a calendaring report;
+
+ 3. The content of a calendar object resource in a response to a
+ calendaring report.
+
+ Description: When nested in the CALDAV:supported-calendar-data
+ property, the CALDAV:calendar-data XML element specifies a media
+ type supported by the CalDAV server for calendar object resources.
+
+ When used in a calendaring REPORT request, the CALDAV:calendar-
+ data XML element specifies which parts of calendar object
+ resources need to be returned in the response. If the CALDAV:
+ calendar-data XML element doesn't contain any CALDAV:comp element,
+ calendar object resources will be returned in their entirety.
+
+ Finally, when used in a calendaring REPORT response, the CALDAV:
+ calendar-data XML element specifies the content of a calendar
+ object resource. Given that XML parsers normalize the two-
+ character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal
+ 10) to a single LF character (US-ASCII decimal 10), the CR
+ character (US-ASCII decimal 13) MAY be omitted in calendar object
+ resources specified in the CALDAV:calendar-data XML element.
+ Furthermore, calendar object resources specified in the CALDAV:
+ calendar-data XML element MAY be invalid per their media type
+ specification if the CALDAV:calendar-data XML element part of the
+ calendaring REPORT request did not specify required properties
+ (e.g., UID, DTSTAMP, etc.), or specified a CALDAV:prop XML element
+ with the "novalue" attribute set to "yes".
+
+ Note: The CALDAV:calendar-data XML element is specified in requests
+ and responses inside the DAV:prop XML element as if it were a
+ WebDAV property. However, the CALDAV:calendar-data XML element is
+ not a WebDAV property and, as such, is not returned in PROPFIND
+ responses, nor used in PROPPATCH requests.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 79]
+
+RFC 4791 CalDAV March 2007
+
+
+ Note: The iCalendar data embedded within the CALDAV:calendar-data
+ XML element MUST follow the standard XML character data encoding
+ rules, including use of &lt;, &gt;, &amp; etc. entity encoding or
+ the use of a <![CDATA[ ... ]]> construct. In the later case, the
+ iCalendar data cannot contain the character sequence "]]>", which
+ is the end delimiter for the CDATA section.
+
+ Definition:
+
+ <!ELEMENT calendar-data EMPTY>
+
+ when nested in the CALDAV:supported-calendar-data property
+ to specify a supported media type for calendar object
+ resources;
+
+ <!ELEMENT calendar-data (comp?,
+ (expand | limit-recurrence-set)?,
+ limit-freebusy-set?)>
+
+ when nested in the DAV:prop XML element in a calendaring
+ REPORT request to specify which parts of calendar object
+ resources should be returned in the response;
+
+ <!ELEMENT calendar-data (#PCDATA)>
+ PCDATA value: iCalendar object
+
+ when nested in the DAV:prop XML element in a calendaring
+ REPORT response to specify the content of a returned
+ calendar object resource.
+
+ <!ATTLIST calendar-data content-type CDATA "text/calendar"
+ version CDATA "2.0">
+ content-type value: a MIME media type
+ version value: a version string
+
+ attributes can be used on all three variants of the
+ CALDAV:calendar-data XML element.
+
+9.6.1. CALDAV:comp XML Element
+
+ Name: comp
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Defines which component types to return.
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 80]
+
+RFC 4791 CalDAV March 2007
+
+
+ Description: The name value is a calendar component name (e.g.,
+ VEVENT).
+
+ Definition:
+
+ <!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>
+
+ <!ATTLIST comp name CDATA #REQUIRED>
+ name value: a calendar component name
+
+ Note: The CALDAV:prop and CALDAV:allprop elements have the same name
+ as the DAV:prop and DAV:allprop elements defined in [RFC2518].
+ However, the CALDAV:prop and CALDAV:allprop elements are defined
+ in the "urn:ietf:params:xml:ns:caldav" namespace instead of the
+ "DAV:" namespace.
+
+9.6.2. CALDAV:allcomp XML Element
+
+ Name: allcomp
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies that all components shall be returned.
+
+ Description: The CALDAV:allcomp XML element can be used when the
+ client wants all types of components returned by a calendaring
+ REPORT request.
+
+ Definition:
+
+ <!ELEMENT allcomp EMPTY>
+
+9.6.3. CALDAV:allprop XML Element
+
+ Name: allprop
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies that all properties shall be returned.
+
+ Description: The CALDAV:allprop XML element can be used when the
+ client wants all properties of components returned by a
+ calendaring REPORT request.
+
+ Definition:
+
+ <!ELEMENT allprop EMPTY>
+
+
+
+
+Daboo, et al. Standards Track [Page 81]
+
+RFC 4791 CalDAV March 2007
+
+
+ Note: The CALDAV:allprop element has the same name as the DAV:
+ allprop element defined in [RFC2518]. However, the CALDAV:allprop
+ element is defined in the "urn:ietf:params:xml:ns:caldav"
+ namespace instead of the "DAV:" namespace.
+
+9.6.4. CALDAV:prop XML Element
+
+ Name: prop
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Defines which properties to return in the response.
+
+ Description: The "name" attribute specifies the name of the calendar
+ property to return (e.g., ATTENDEE). The "novalue" attribute can
+ be used by clients to request that the actual value of the
+ property not be returned (if the "novalue" attribute is set to
+ "yes"). In that case, the server will return just the iCalendar
+ property name and any iCalendar parameters and a trailing ":"
+ without the subsequent value data.
+
+ Definition:
+
+ <!ELEMENT prop EMPTY>
+
+ <!ATTLIST prop name CDATA #REQUIRED
+ novalue (yes | no) "no">
+ name value: a calendar property name
+ novalue value: "yes" or "no"
+
+ Note: The CALDAV:prop element has the same name as the DAV:prop
+ element defined in [RFC2518]. However, the CALDAV:prop element is
+ defined in the "urn:ietf:params:xml:ns:caldav" namespace instead
+ of the "DAV:" namespace.
+
+9.6.5. CALDAV:expand XML Element
+
+ Name: expand
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Forces the server to expand recurring components into
+ individual recurrence instances.
+
+ Description: The CALDAV:expand XML element specifies that for a
+ given calendaring REPORT request, the server MUST expand the
+ recurrence set into calendar components that define exactly one
+
+
+
+
+Daboo, et al. Standards Track [Page 82]
+
+RFC 4791 CalDAV March 2007
+
+
+ recurrence instance, and MUST return only those whose scheduled
+ time intersect a specified time range.
+
+ The "start" attribute specifies the inclusive start of the time
+ range, and the "end" attribute specifies the non-inclusive end of
+ the time range. Both attributes are specified as date with UTC
+ time value. The value of the "end" attribute MUST be greater than
+ the value of the "start" attribute.
+
+ The server MUST use the same logic as defined for CALDAV:time-
+ range to determine if a recurrence instance intersects the
+ specified time range.
+
+ Recurring components, other than the initial instance, MUST
+ include a RECURRENCE-ID property indicating which instance they
+ refer to.
+
+ The returned calendar components MUST NOT use recurrence
+ properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT
+ have reference to or include VTIMEZONE components. Date and local
+ time with reference to time zone information MUST be converted
+ into date with UTC time.
+
+ Definition:
+
+ <!ELEMENT expand EMPTY>
+
+ <!ATTLIST expand start CDATA #REQUIRED
+ end CDATA #REQUIRED>
+ start value: an iCalendar "date with UTC time"
+ end value: an iCalendar "date with UTC time"
+
+9.6.6. CALDAV:limit-recurrence-set XML Element
+
+ Name: limit-recurrence-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a time range to limit the set of "overridden
+ components" returned by the server.
+
+ Description: The CALDAV:limit-recurrence-set XML element specifies
+ that for a given calendaring REPORT request, the server MUST
+ return, in addition to the "master component", only the
+ "overridden components" that impact a specified time range. An
+ overridden component impacts a time range if its current start and
+ end times overlap the time range, or if the original start and end
+
+
+
+
+Daboo, et al. Standards Track [Page 83]
+
+RFC 4791 CalDAV March 2007
+
+
+ times -- the ones that would have been used if the instance were
+ not overridden -- overlap the time range.
+
+ The "start" attribute specifies the inclusive start of the time
+ range, and the "end" attribute specifies the non-inclusive end of
+ the time range. Both attributes are specified as date with UTC
+ time value. The value of the "end" attribute MUST be greater than
+ the value of the "start" attribute.
+
+ The server MUST use the same logic as defined for CALDAV:time-
+ range to determine if the current or original scheduled time of an
+ "overridden" recurrence instance intersects the specified time
+ range.
+
+ Overridden components that have a RANGE parameter on their
+ RECURRENCE-ID property may specify one or more instances in the
+ recurrence set, and some of those instances may fall within the
+ specified time range or may have originally fallen within the
+ specified time range prior to being overridden. If that is the
+ case, the overridden component MUST be included in the results, as
+ it has a direct impact on the interpretation of instances within
+ the specified time range.
+
+ Definition:
+
+ <!ELEMENT limit-recurrence-set EMPTY>
+
+ <!ATTLIST limit-recurrence-set start CDATA #REQUIRED
+ end CDATA #REQUIRED>
+ start value: an iCalendar "date with UTC time"
+ end value: an iCalendar "date with UTC time"
+
+9.6.7. CALDAV:limit-freebusy-set XML Element
+
+ Name: limit-freebusy-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a time range to limit the set of FREEBUSY values
+ returned by the server.
+
+ Description: The CALDAV:limit-freebusy-set XML element specifies
+ that for a given calendaring REPORT request, the server MUST only
+ return the FREEBUSY property values of a VFREEBUSY component that
+ intersects a specified time range.
+
+ The "start" attribute specifies the inclusive start of the time
+ range, and the "end" attribute specifies the non-inclusive end of
+
+
+
+Daboo, et al. Standards Track [Page 84]
+
+RFC 4791 CalDAV March 2007
+
+
+ the time range. Both attributes are specified as "date with UTC
+ time" value. The value of the "end" attribute MUST be greater
+ than the value of the "start" attribute.
+
+ The server MUST use the same logic as defined for CALDAV:time-
+ range to determine if a FREEBUSY property value intersects the
+ specified time range.
+
+ Definition:
+
+ <!ELEMENT limit-freebusy-set EMPTY>
+
+ <!ATTLIST limit-freebusy-set start CDATA #REQUIRED
+ end CDATA #REQUIRED>
+ start value: an iCalendar "date with UTC time"
+ end value: an iCalendar "date with UTC time"
+
+9.7. CALDAV:filter XML Element
+
+ Name: filter
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a filter to limit the set of calendar components
+ returned by the server.
+
+ Description: The CALDAV:filter XML element specifies the search
+ filter used to limit the calendar components returned by a
+ calendaring REPORT request.
+
+ Definition:
+
+ <!ELEMENT filter (comp-filter)>
+
+9.7.1. CALDAV:comp-filter XML Element
+
+ Name: comp-filter
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies search criteria on calendar components.
+
+ Description: The CALDAV:comp-filter XML element specifies a query
+ targeted at the calendar object (i.e., VCALENDAR) or at a specific
+ calendar component type (e.g., VEVENT). The scope of the
+ CALDAV:comp-filter XML element is the calendar object when used as
+ a child of the CALDAV:filter XML element. The scope of the
+ CALDAV:comp-filter XML element is the enclosing calendar component
+
+
+
+Daboo, et al. Standards Track [Page 85]
+
+RFC 4791 CalDAV March 2007
+
+
+ when used as a child of another CALDAV:comp-filter XML element. A
+ CALDAV:comp-filter is said to match if:
+
+ * The CALDAV:comp-filter XML element is empty and the calendar
+ object or calendar component type specified by the "name"
+ attribute exists in the current scope;
+
+ or:
+
+ * The CALDAV:comp-filter XML element contains a CALDAV:is-not-
+ defined XML element and the calendar object or calendar
+ component type specified by the "name" attribute does not exist
+ in the current scope;
+
+ or:
+
+ * The CALDAV:comp-filter XML element contains a CALDAV:time-range
+ XML element and at least one recurrence instance in the
+ targeted calendar component is scheduled to overlap the
+ specified time range, and all specified CALDAV:prop-filter and
+ CALDAV:comp-filter child XML elements also match the targeted
+ calendar component;
+
+ or:
+
+ * The CALDAV:comp-filter XML element only contains CALDAV:prop-
+ filter and CALDAV:comp-filter child XML elements that all match
+ the targeted calendar component.
+
+ Definition:
+
+ <!ELEMENT comp-filter (is-not-defined | (time-range?,
+ prop-filter*, comp-filter*))>
+
+ <!ATTLIST comp-filter name CDATA #REQUIRED>
+ name value: a calendar object or calendar component
+ type (e.g., VEVENT)
+
+9.7.2. CALDAV:prop-filter XML Element
+
+ Name: prop-filter
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies search criteria on calendar properties.
+
+ Description: The CALDAV:prop-filter XML element specifies a query
+ targeted at a specific calendar property (e.g., CATEGORIES) in the
+
+
+
+Daboo, et al. Standards Track [Page 86]
+
+RFC 4791 CalDAV March 2007
+
+
+ scope of the enclosing calendar component. A calendar property is
+ said to match a CALDAV:prop-filter if:
+
+ * The CALDAV:prop-filter XML element is empty and a property of
+ the type specified by the "name" attribute exists in the
+ enclosing calendar component;
+
+ or:
+
+ * The CALDAV:prop-filter XML element contains a CALDAV:is-not-
+ defined XML element and no property of the type specified by
+ the "name" attribute exists in the enclosing calendar
+ component;
+
+ or:
+
+ * The CALDAV:prop-filter XML element contains a CALDAV:time-range
+ XML element and the property value overlaps the specified time
+ range, and all specified CALDAV:param-filter child XML elements
+ also match the targeted property;
+
+ or:
+
+ * The CALDAV:prop-filter XML element contains a CALDAV:text-match
+ XML element and the property value matches it, and all
+ specified CALDAV:param-filter child XML elements also match the
+ targeted property;
+
+ Definition:
+
+ <!ELEMENT prop-filter (is-not-defined |
+ ((time-range | text-match)?,
+ param-filter*))>
+
+ <!ATTLIST prop-filter name CDATA #REQUIRED>
+ name value: a calendar property name (e.g., ATTENDEE)
+
+9.7.3. CALDAV:param-filter XML Element
+
+ Name: param-filter
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Limits the search to specific parameter values.
+
+ Description: The CALDAV:param-filter XML element specifies a query
+ targeted at a specific calendar property parameter (e.g.,
+ PARTSTAT) in the scope of the calendar property on which it is
+
+
+
+Daboo, et al. Standards Track [Page 87]
+
+RFC 4791 CalDAV March 2007
+
+
+ defined. A calendar property parameter is said to match a CALDAV:
+ param-filter if:
+
+ * The CALDAV:param-filter XML element is empty and a parameter of
+ the type specified by the "name" attribute exists on the
+ calendar property being examined;
+
+ or:
+
+ * The CALDAV:param-filter XML element contains a CALDAV:is-not-
+ defined XML element and no parameter of the type specified by
+ the "name" attribute exists on the calendar property being
+ examined;
+
+ Definition:
+
+ <!ELEMENT param-filter (is-not-defined | text-match?)>
+
+ <!ATTLIST param-filter name CDATA #REQUIRED>
+ name value: a property parameter name (e.g., PARTSTAT)
+
+9.7.4. CALDAV:is-not-defined XML Element
+
+ Name: is-not-defined
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies that a match should occur if the enclosing
+ component, property, or parameter does not exist.
+
+ Description: The CALDAV:is-not-defined XML element specifies that a
+ match occurs if the enclosing component, property, or parameter
+ value specified in a calendaring REPORT request does not exist in
+ the calendar data being tested.
+
+ Definition:
+
+ <!ELEMENT is-not-defined EMPTY>
+
+9.7.5. CALDAV:text-match XML Element
+
+ Name: text-match
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a substring match on a property or parameter
+ value.
+
+
+
+
+Daboo, et al. Standards Track [Page 88]
+
+RFC 4791 CalDAV March 2007
+
+
+ Description: The CALDAV:text-match XML element specifies text used
+ for a substring match against the property or parameter value
+ specified in a calendaring REPORT request.
+
+ The "collation" attribute is used to select the collation that the
+ server MUST use for character string matching. In the absence of
+ this attribute, the server MUST use the "i;ascii-casemap"
+ collation.
+
+ The "negate-condition" attribute is used to indicate that this
+ test returns a match if the text matches when the attribute value
+ is set to "no", or return a match if the text does not match, if
+ the attribute value is set to "yes". For example, this can be
+ used to match components with a STATUS property not set to
+ CANCELLED.
+
+ Definition:
+
+ <!ELEMENT text-match (#PCDATA)>
+ PCDATA value: string
+
+ <!ATTLIST text-match collation CDATA "i;ascii-casemap"
+ negate-condition (yes | no) "no">
+
+9.8. CALDAV:timezone XML Element
+
+ Name: timezone
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies the time zone component to use when determining
+ the results of a report.
+
+ Description: The CALDAV:timezone XML element specifies that for a
+ given calendaring REPORT request, the server MUST rely on the
+ specified VTIMEZONE component instead of the CALDAV:calendar-
+ timezone property of the calendar collection, in which the
+ calendar object resource is contained to resolve "date" values and
+ "date with local time" values (i.e., floating time) to "date with
+ UTC time" values. The server will require this information to
+ determine if a calendar component scheduled with "date" values or
+ "date with local time" values intersects a CALDAV:time-range
+ specified in a CALDAV:calendar-query REPORT.
+
+ Note: The iCalendar data embedded within the CALDAV:timezone XML
+ element MUST follow the standard XML character data encoding
+ rules, including use of &lt;, &gt;, &amp; etc. entity encoding or
+ the use of a <![CDATA[ ... ]]> construct. In the later case, the
+
+
+
+Daboo, et al. Standards Track [Page 89]
+
+RFC 4791 CalDAV March 2007
+
+
+ iCalendar data cannot contain the character sequence "]]>", which
+ is the end delimiter for the CDATA section.
+
+ Definition:
+
+ <!ELEMENT timezone (#PCDATA)>
+ PCDATA value: an iCalendar object with exactly one VTIMEZONE
+
+9.9. CALDAV:time-range XML Element
+
+ Name: time-range
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a time range to limit the set of calendar
+ components returned by the server.
+
+ Description: The CALDAV:time-range XML element specifies that for a
+ given calendaring REPORT request, the server MUST only return the
+ calendar object resources that, depending on the context, have a
+ component or property whose value intersects a specified time
+ range.
+
+ The "start" attribute specifies the inclusive start of the time
+ range, and the "end" attribute specifies the non-inclusive end of
+ the time range. Both attributes MUST be specified as "date with
+ UTC time" value. Time ranges open at one end can be specified by
+ including only one attribute; however, at least one attribute MUST
+ always be present in the CALDAV:time-range element. If either the
+ "start" or "end" attribute is not specified in the CALDAV:time-
+ range XML element, assume "-infinity" and "+infinity" as their
+ value, respectively. If both "start" and "end" are present, the
+ value of the "end" attribute MUST be greater than the value of the
+ "start" attribute.
+
+ Time range tests MUST consider every recurrence instance when
+ testing the time range condition; if any one instance matches,
+ then the test returns true. Testing recurrence instances requires
+ the server to infer an effective value for DTSTART, DTEND,
+ DURATION, and DUE properties for an instance based on the
+ recurrence patterns and any overrides.
+
+ A VEVENT component overlaps a given time range if the condition
+ for the corresponding component state specified in the table below
+ is satisfied. Note that, as specified in [RFC2445], the DTSTART
+ property is REQUIRED in the VEVENT component. The conditions
+ depend on the presence of the DTEND and DURATION properties in the
+ VEVENT component. Furthermore, the value of the DTEND property
+
+
+
+Daboo, et al. Standards Track [Page 90]
+
+RFC 4791 CalDAV March 2007
+
+
+ MUST be later in time than the value of the DTSTART property. The
+ duration of a VEVENT component with no DTEND and DURATION
+ properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0
+ seconds when the DTSTART is a DATE-TIME value.
+
+ +---------------------------------------------------------------+
+ | VEVENT has the DTEND property? |
+ | +-----------------------------------------------------------+
+ | | VEVENT has the DURATION property? |
+ | | +-------------------------------------------------------+
+ | | | DURATION property value is greater than 0 seconds? |
+ | | | +---------------------------------------------------+
+ | | | | DTSTART property is a DATE-TIME value? |
+ | | | | +-----------------------------------------------+
+ | | | | | Condition to evaluate |
+ +---+---+---+---+-----------------------------------------------+
+ | Y | N | N | * | (start < DTEND AND end > DTSTART) |
+ +---+---+---+---+-----------------------------------------------+
+ | N | Y | Y | * | (start < DTSTART+DURATION AND end > DTSTART) |
+ | | +---+---+-----------------------------------------------+
+ | | | N | * | (start <= DTSTART AND end > DTSTART) |
+ +---+---+---+---+-----------------------------------------------+
+ | N | N | N | Y | (start <= DTSTART AND end > DTSTART) |
+ +---+---+---+---+-----------------------------------------------+
+ | N | N | N | N | (start < DTSTART+P1D AND end > DTSTART) |
+ +---+---+---+---+-----------------------------------------------+
+
+ A VTODO component is said to overlap a given time range if the
+ condition for the corresponding component state specified in the
+ table below is satisfied. The conditions depend on the presence
+ of the DTSTART, DURATION, DUE, COMPLETED, and CREATED properties
+ in the VTODO component. Note that, as specified in [RFC2445], the
+ DUE value MUST be a DATE-TIME value equal to or after the DTSTART
+ value if specified.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 91]
+
+RFC 4791 CalDAV March 2007
+
+
+ +-------------------------------------------------------------------+
+ | VTODO has the DTSTART property? |
+ | +---------------------------------------------------------------+
+ | | VTODO has the DURATION property? |
+ | | +-----------------------------------------------------------+
+ | | | VTODO has the DUE property? |
+ | | | +-------------------------------------------------------+
+ | | | | VTODO has the COMPLETED property? |
+ | | | | +---------------------------------------------------+
+ | | | | | VTODO has the CREATED property? |
+ | | | | | +-----------------------------------------------+
+ | | | | | | Condition to evaluate |
+ +---+---+---+---+---+-----------------------------------------------+
+ | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND |
+ | | | | | | ((end > DTSTART) OR |
+ | | | | | | (end >= DTSTART+DURATION)) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | Y | N | Y | * | * | ((start < DUE) OR (start <= DTSTART)) |
+ | | | | | | AND |
+ | | | | | | ((end > DTSTART) OR (end >= DUE)) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | N | N | Y | * | * | (start < DUE) AND (end >= DUE) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))|
+ | | | | | | AND |
+ | | | | | | ((end >= CREATED) OR (end >= COMPLETED))|
+ +---+---+---+---+---+-----------------------------------------------+
+ | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | N | N | N | N | Y | (end > CREATED) |
+ +---+---+---+---+---+-----------------------------------------------+
+ | N | N | N | N | N | TRUE |
+ +---+---+---+---+---+-----------------------------------------------+
+
+ A VJOURNAL component overlaps a given time range if the condition
+ for the corresponding component state specified in the table below
+ is satisfied. The conditions depend on the presence of the
+ DTSTART property in the VJOURNAL component and on whether the
+ DTSTART is a DATE-TIME or DATE value. The effective "duration" of
+ a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE
+ value, and 0 seconds when the DTSTART is a DATE-TIME value.
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 92]
+
+RFC 4791 CalDAV March 2007
+
+
+ +----------------------------------------------------+
+ | VJOURNAL has the DTSTART property? |
+ | +------------------------------------------------+
+ | | DTSTART property is a DATE-TIME value? |
+ | | +--------------------------------------------+
+ | | | Condition to evaluate |
+ +---+---+--------------------------------------------+
+ | Y | Y | (start <= DTSTART) AND (end > DTSTART) |
+ +---+---+--------------------------------------------+
+ | Y | N | (start < DTSTART+P1D) AND (end > DTSTART) |
+ +---+---+--------------------------------------------+
+ | N | * | FALSE |
+ +---+---+--------------------------------------------+
+
+ A VFREEBUSY component overlaps a given time range if the condition
+ for the corresponding component state specified in the table below
+ is satisfied. The conditions depend on the presence in the
+ VFREEBUSY component of the DTSTART and DTEND properties, and any
+ FREEBUSY properties in the absence of DTSTART and DTEND. Any
+ DURATION property is ignored, as it has a special meaning when
+ used in a VFREEBUSY component.
+
+ When only FREEBUSY properties are used, each period in each
+ FREEBUSY property is compared against the time range, irrespective
+ of the type of free busy information (free, busy, busy-tentative,
+ busy-unavailable) represented by the property.
+
+
+ +------------------------------------------------------+
+ | VFREEBUSY has both the DTSTART and DTEND properties? |
+ | +--------------------------------------------------+
+ | | VFREEBUSY has the FREEBUSY property? |
+ | | +----------------------------------------------+
+ | | | Condition to evaluate |
+ +---+---+----------------------------------------------+
+ | Y | * | (start <= DTEND) AND (end > DTSTART) |
+ +---+---+----------------------------------------------+
+ | N | Y | (start < freebusy-period-end) AND |
+ | | | (end > freebusy-period-start) |
+ +---+---+----------------------------------------------+
+ | N | N | FALSE |
+ +---+---+----------------------------------------------+
+
+ A VALARM component is said to overlap a given time range if the
+ following condition holds:
+
+ (start <= trigger-time) AND (end > trigger-time)
+
+
+
+
+Daboo, et al. Standards Track [Page 93]
+
+RFC 4791 CalDAV March 2007
+
+
+ A VALARM component can be defined such that it triggers repeatedly.
+ Such a VALARM component is said to overlap a given time range if at
+ least one of its triggers overlaps the time range.
+
+ The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP,
+ DTSTART, DUE, and LAST-MODIFIED overlap a given time range if the
+ following condition holds:
+
+ (start <= date-time) AND (end > date-time)
+
+ Note that if DTEND is not present in a VEVENT, but DURATION is, then
+ the test should instead operate on the 'effective' DTEND, i.e.,
+ DTSTART+DURATION. Similarly, if DUE is not present in a VTODO, but
+ DTSTART and DURATION are, then the test should instead operate on the
+ 'effective' DUE, i.e., DTSTART+DURATION.
+
+ The semantic of CALDAV:time-range is not defined for any other
+ calendar components and properties.
+
+ Definition:
+
+ <!ELEMENT time-range EMPTY>
+
+ <!ATTLIST time-range start CDATA #IMPLIED
+ end CDATA #IMPLIED>
+ start value: an iCalendar "date with UTC time"
+ end value: an iCalendar "date with UTC time"
+
+9.10. CALDAV:calendar-multiget XML Element
+
+ Name: calendar-multiget
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: CalDAV report used to retrieve specific calendar object
+ resources.
+
+ Description: See Section 7.9.
+
+ Definition:
+
+ <!ELEMENT calendar-multiget ((DAV:allprop |
+ DAV:propname |
+ DAV:prop)?, DAV:href+)>
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 94]
+
+RFC 4791 CalDAV March 2007
+
+
+9.11. CALDAV:free-busy-query XML Element
+
+ Name: free-busy-query
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: CalDAV report used to generate a VFREEBUSY to determine
+ busy time over a specific time range.
+
+ Description: See Section 7.10.
+
+ Definition:
+
+ <!ELEMENT free-busy-query (time-range)>
+
+10. Internationalization Considerations
+
+ CalDAV allows internationalized strings to be stored and retrieved
+ for the description of calendar collections (see Section 5.2.1).
+
+ The CALDAV:calendar-query REPORT (Section 7.8) includes a text
+ searching option controlled by the CALDAV:text-match element, and
+ details of character handling are covered in the description of that
+ element (see Section 9.7.5).
+
+11. Security Considerations
+
+ HTTP protocol transactions are sent in the clear over the network
+ unless protection from snooping is negotiated. This can be
+ accomplished by use of TLS, as defined in [RFC2818]. In particular,
+ HTTP Basic authentication MUST NOT be used unless TLS is in effect.
+
+ Servers MUST take adequate precautions to ensure that malicious
+ clients cannot consume excessive server resources (CPU, memory, disk,
+ etc.) through carefully crafted reports. For example, a client could
+ upload an event with a recurrence rule that specifies a recurring
+ event occurring every second for the next 100 years, which would
+ result in approximately 3 x 10^9 instances! A report that asks for
+ recurrences to be expanded over that range would likely constitute a
+ denial-of-service attack on the server.
+
+ When creating new resources (including calendar collections), clients
+ MUST ensure that the resource name (the last path segment of the
+ resource URI) assigned to the new resource does not expose any data
+ from within the iCalendar resource itself or information about the
+ nature of a calendar collection. This is required to ensure that the
+ presence of a specific iCalendar component or nature of components in
+ a collection cannot be inferred based on the name of a resource.
+
+
+
+Daboo, et al. Standards Track [Page 95]
+
+RFC 4791 CalDAV March 2007
+
+
+ When rolling up free-busy information, more information about a
+ user's events is exposed if busy periods overlap or are adjacent
+ (this tells the client requesting the free-busy information that the
+ calendar owner has at least two events, rather than knowing only that
+ the calendar owner has one or more events during the busy period).
+ Thus, a conservative approach to calendar data privacy would have
+ servers always coalesce such busy periods when they are the same
+ type.
+
+ Procedure alarms are a known security risk for either clients or
+ servers to handle, particularly when the alarm was created by another
+ agent. Clients and servers are not required to execute such
+ procedure alarms.
+
+ Security considerations described in iCalendar [RFC2445] and iTIP
+ [RFC2446] are also applicable to CalDAV.
+
+ Beyond these, CalDAV does not raise any security considerations that
+ are not present in HTTP [RFC2616] and WebDAV [RFC2518], [RFC3253],
+ [RFC3744].
+
+12. IANA Considerations
+
+ This document uses one new URN to identify a new XML namespace. The
+ URN conforms to a registry mechanism described in [RFC3688].
+
+12.1. Namespace Registration
+
+ Registration request for the CalDAV namespace:
+
+ URI: urn:ietf:params:xml:ns:caldav
+
+ Registrant Contact: See the "Authors' Addresses" section of this
+ document.
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+13. Acknowledgements
+
+ The authors would like to thank the following individuals for
+ contributing their ideas and support for writing this specification:
+ Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Andre
+ Courtemanche, Mike Douglass, Ted Hardie, Marten den Haring, Jeffrey
+ Harris, Sam Hartman, Helge Hess, Jeff McCullough, Alexey Melnikov,
+ Dan Mosedale, Brian Moseley, Francois Perrault, Kervin L. Pierre,
+ Julian F. Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari
+ Urpalainen, Simon Vaillancourt, and Jim Whitehead.
+
+
+
+
+Daboo, et al. Standards Track [Page 96]
+
+RFC 4791 CalDAV March 2007
+
+
+ The authors would also like to thank the Calendaring and Scheduling
+ Consortium for advice with this specification, and for organizing
+ interoperability testing events to help refine it.
+
+14. References
+
+14.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14,
+ RFC 2119, March 1997.
+
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol
+ Version 1.0", RFC 2246, January 1999.
+
+ [RFC2445] Dawson, F. and Stenerson, D., "Internet
+ Calendaring and Scheduling Core Object
+ Specification (iCalendar)", RFC 2445,
+ November 1998.
+
+ [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and
+ R. Hopson, "iCalendar Transport-Independent
+ Interoperability Protocol (iTIP) Scheduling
+ Events, BusyTime, To-dos and Journal
+ Entries", RFC 2446, November 1998.
+
+ [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter,
+ S., and D. Jensen, "HTTP Extensions for
+ Distributed Authoring -- WEBDAV", RFC 2518,
+ February 1999.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk,
+ H., Masinter, L., Leach, P., and T. Berners-
+ Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
+ May 2000.
+
+ [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler,
+ C., and J. Whitehead, "Versioning Extensions
+ to WebDAV (Web Distributed Authoring and
+ Versioning)", RFC 3253, March 2002.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry",
+ BCP 81, RFC 3688, January 2004.
+
+
+
+
+
+Daboo, et al. Standards Track [Page 97]
+
+RFC 4791 CalDAV March 2007
+
+
+ [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
+ Whitehead, "Web Distributed Authoring and
+ Versioning (WebDAV) Access Control Protocol",
+ RFC 3744, May 2004.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport
+ Layer Security (TLS) Protocol Version 1.1",
+ RFC 4346, April 2006.
+
+ [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen,
+ "Internet Application Protocol Collation
+ Registry", RFC 4790, March 2007.
+
+ [W3C.REC-xml-20060816] Paoli, J., Maler, E., Yergeau, F., Sperberg-
+ McQueen, C., and T. Bray, "Extensible Markup
+ Language (XML) 1.0 (Fourth Edition)", World
+ Wide Web Consortium Recommendation REC-xml-
+ 20060816, August 2006,
+ <http://www.w3.org/TR/2006/REC-xml-20060816>.
+
+14.2. Informative References
+
+ [RFC2426] Dawson, F. and T. Howes, "vCard MIME
+ Directory Profile", RFC 2426, September 1998.
+
+ [RFC2739] Small, T., Hennessy, D., and F. Dawson,
+ "Calendar Attributes for vCard and LDAP",
+ RFC 2739, January 2000.
+
+ [RFC4331] Korver, B. and L. Dusseault, "Quota and Size
+ Properties for Distributed Authoring and
+ Versioning (DAV) Collections", RFC 4331,
+ February 2006.
+
+ [RFC4511] Sermersheim, J., "Lightweight Directory
+ Access Protocol (LDAP): The Protocol",
+ RFC 4511, June 2006.
+
+ [rfc2518bis] Dusseault, L., "HTTP Extensions for
+ Distributed Authoring - WebDAV", Work
+ in Progress, December 2006.
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 98]
+
+RFC 4791 CalDAV March 2007
+
+
+Appendix A. CalDAV Method Privilege Table (Normative)
+
+ The following table extends the WebDAV Method Privilege Table
+ specified in Appendix B of [RFC3744].
+
+ +------------+------------------------------------------------------+
+ | METHOD | PRIVILEGES |
+ +------------+------------------------------------------------------+
+ | MKCALENDAR | DAV:bind |
+ | REPORT | DAV:read or CALDAV:read-free-busy (on all referenced |
+ | | resources) |
+ +------------+------------------------------------------------------+
+
+Appendix B. Calendar Collections Used in the Examples
+
+ This appendix shows the calendar object resources contained in the
+ calendar collection queried in the examples throughout this document.
+
+ The content of the calendar collection is being shown as if it were
+ returned by a CALDAV:calendar-query REPORT request designed to return
+ all the calendar data in the collection:
+
+ >> Request <<
+
+ REPORT /bernard/work/ HTTP/1.1
+ Host: cal.example.com
+ Depth: 1
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:calendar-query xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:prop>
+ <D:getetag/>
+ <C:calendar-data/>
+ </D:prop>
+ <C:filter>
+ <C:comp-filter name="VCALENDAR"/>
+ </C:filter>
+ </C:calendar-query>
+
+ >> Response <<
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+
+
+
+Daboo, et al. Standards Track [Page 99]
+
+RFC 4791 CalDAV March 2007
+
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd1"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001102Z
+ DTSTART;TZID=US/Eastern:20060102T100000
+ DURATION:PT1H
+ SUMMARY:Event #1
+ Description:Go Steelers!
+ UID:74855313FA803DA593CD579A@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+ <D:propstat>
+
+
+
+Daboo, et al. Standards Track [Page 100]
+
+RFC 4791 CalDAV March 2007
+
+
+ <D:prop>
+ <D:getetag>"fffff-abcd2"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060102T120000
+ DURATION:PT1H
+ RRULE:FREQ=DAILY;COUNT=5
+ SUMMARY:Event #2
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART;TZID=US/Eastern:20060104T140000
+ DURATION:PT1H
+ RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+
+
+
+Daboo, et al. Standards Track [Page 101]
+
+RFC 4791 CalDAV March 2007
+
+
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd3"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTIMEZONE
+ LAST-MODIFIED:20040110T032845Z
+ TZID:US/Eastern
+ BEGIN:DAYLIGHT
+ DTSTART:20000404T020000
+ RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+ TZNAME:EDT
+ TZOFFSETFROM:-0500
+ TZOFFSETTO:-0400
+ END:DAYLIGHT
+ BEGIN:STANDARD
+ DTSTART:20001026T020000
+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+ TZNAME:EST
+ TZOFFSETFROM:-0400
+ TZOFFSETTO:-0500
+ END:STANDARD
+ END:VTIMEZONE
+ BEGIN:VEVENT
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus@example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD@example.com
+ END:VEVENT
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+ <D:propstat>
+ <D:prop>
+
+
+
+Daboo, et al. Standards Track [Page 102]
+
+RFC 4791 CalDAV March 2007
+
+
+ <D:getetag>"fffff-abcd4"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ DTSTAMP:20060205T235335Z
+ DUE;VALUE=DATE:20060104
+ STATUS:NEEDS-ACTION
+ SUMMARY:Task #1
+ UID:DDDEEB7915FA61233B861457@example.com
+ BEGIN:VALARM
+ ACTION:AUDIO
+ TRIGGER;RELATED=START:-PT10M
+ END:VALARM
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd5"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ DTSTAMP:20060205T235300Z
+ DUE;VALUE=DATE:20060106
+ LAST-MODIFIED:20060205T235308Z
+ SEQUENCE:1
+ STATUS:NEEDS-ACTION
+ SUMMARY:Task #2
+ UID:E10BA47467C5C69BB74E8720@example.com
+ BEGIN:VALARM
+ ACTION:AUDIO
+ TRIGGER;RELATED=START:-PT10M
+ END:VALARM
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+
+
+
+Daboo, et al. Standards Track [Page 103]
+
+RFC 4791 CalDAV March 2007
+
+
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd6"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ COMPLETED:20051223T122322Z
+ DTSTAMP:20060205T235400Z
+ DUE;VALUE=DATE:20051225
+ LAST-MODIFIED:20060205T235308Z
+ SEQUENCE:1
+ STATUS:COMPLETED
+ SUMMARY:Task #3
+ UID:E10BA47467C5C69BB74E8722@example.com
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd7.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd7"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VTODO
+ DTSTAMP:20060205T235600Z
+ DUE;VALUE=DATE:20060101
+ LAST-MODIFIED:20060205T235308Z
+ SEQUENCE:1
+ STATUS:CANCELLED
+ SUMMARY:Task #4
+ UID:E10BA47467C5C69BB74E8725@example.com
+ END:VTODO
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+
+
+
+Daboo, et al. Standards Track [Page 104]
+
+RFC 4791 CalDAV March 2007
+
+
+ </D:propstat>
+ </D:response>
+
+ <D:response>
+ <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"fffff-abcd8"</D:getetag>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ BEGIN:VFREEBUSY
+ ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
+ UID:76ef34-54a3d2@example.com
+ DTSTAMP:20050530T123421Z
+ DTSTART:20060101T000000Z
+ DTEND:20060108T000000Z
+ FREEBUSY:20050531T230000Z/20050601T010000Z
+ FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
+ FREEBUSY:20060103T100000Z/20060103T120000Z
+ FREEBUSY:20060104T100000Z/20060104T120000Z
+ FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
+ FREEBUSY:20060106T100000Z/20060106T120000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+ </C:calendar-data>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:response>
+
+ </D:multistatus>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 105]
+
+RFC 4791 CalDAV March 2007
+
+
+Authors' Addresses
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus@daboo.name
+ URI: http://www.apple.com/
+
+
+ Bernard Desruisseaux
+ Oracle Corporation
+ 600 Blvd. de Maisonneuve West
+ Suite 1900
+ Montreal, QC H3A 3J2
+ CANADA
+
+ EMail: bernard.desruisseaux@oracle.com
+ URI: http://www.oracle.com/
+
+
+ Lisa Dusseault
+ CommerceNet
+ 169 University Ave.
+ Palo Alto, CA 94301
+ USA
+
+ EMail: ldusseault@commerce.net
+ URI: http://commerce.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 106]
+
+RFC 4791 CalDAV March 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 107]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 23:38:15 +0000