[CalendarServer-changes] [1400] CalendarServer/trunk/doc/RFC
source_changes at macosforge.org
source_changes at macosforge.org
Thu Mar 15 20:10:55 PDT 2007
Revision: 1400
http://trac.macosforge.org/projects/calendarserver/changeset/1400
Author: wsanchez at apple.com
Date: 2007-03-15 20:10:54 -0700 (Thu, 15 Mar 2007)
Log Message:
-----------
draft-dusseault-caldav -> rfc4791
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/rfc4791-CalDAV.txt
Removed Paths:
-------------
CalendarServer/trunk/doc/RFC/draft-dusseault-caldav.txt
Deleted: CalendarServer/trunk/doc/RFC/draft-dusseault-caldav.txt
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-dusseault-caldav.txt 2007-03-16 01:06:55 UTC (rev 1399)
+++ CalendarServer/trunk/doc/RFC/draft-dusseault-caldav.txt 2007-03-16 03:10:54 UTC (rev 1400)
@@ -1,6440 +0,0 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple Computer
-Expires: March 17, 2007 B. Desruisseaux
- Oracle
- L. Dusseault
- OSAF
- September 13, 2006
-
-
- Calendaring Extensions to WebDAV (CalDAV)
- draft-dusseault-caldav-15
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 17, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document specifies a set of methods, headers, message bodies,
- properties, and reports that define calendar access extensions to the
- WebDAV protocol. The new protocol elements are intended to make
- WebDAV-based calendaring and scheduling an interoperable standard
- that supports calendar access, calendar management, calendar sharing,
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 1]
-
-Internet-Draft CalDAV September 2006
-
-
- and calendar publishing.
-
-
-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 . . . . . . . . . . . . 18
- 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 2]
-
-Internet-Draft CalDAV September 2006
-
-
- 7.4. Time range filtering . . . . . . . . . . . . . . . . . . 32
- 7.5. Searching Text: Collations . . . . . . . . . . . . . . . 33
- 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 . . . . . . . . . . . . . . 35
- 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 . . . . . . . . . . . . . . . . . . . . . 47
- 7.8.5. Example: Retrieval of to-dos by alarm time range . . 49
- 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 . . . . . . . . . . . . . . . . . . . . . . . . . 68
- 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 . . . . . . . . . . . . 69
- 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 . . . . . . . . . 77
- 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 . . . . . . . . . . . . . 80
- 9.6.3. CALDAV:allprop XML Element . . . . . . . . . . . . . 81
- 9.6.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 81
- 9.6.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 82
- 9.6.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 83
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 3]
-
-Internet-Draft CalDAV September 2006
-
-
- 9.6.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 84
- 9.7. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 84
- 9.7.1. CALDAV:comp-filter XML Element . . . . . . . . . . . 85
- 9.7.2. CALDAV:prop-filter XML Element . . . . . . . . . . . 85
- 9.7.3. CALDAV:param-filter XML Element . . . . . . . . . . . 86
- 9.7.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 87
- 9.7.5. CALDAV:text-match XML Element . . . . . . . . . . . . 87
- 9.8. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 88
- 9.9. CALDAV:time-range XML Element . . . . . . . . . . . . . . 88
- 9.10. CALDAV:calendar-multiget XML Element . . . . . . . . . . 93
- 9.11. CALDAV:free-busy-query XML Element . . . . . . . . . . . 94
- 10. Internationalization Considerations . . . . . . . . . . . . . 94
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 94
- 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 95
- 12.1. Namespace Registration . . . . . . . . . . . . . . . . . 95
- 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
- 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
- 14.1. Normative References . . . . . . . . . . . . . . . . . . 96
- 14.2. Informative References . . . . . . . . . . . . . . . . . 97
- Appendix A. CalDAV Method Privilege Table (Normative) . . . . . 97
- Appendix B. Calendar collections used in the examples . . . . . 98
- Appendix C. Changes (to be removed prior to publication as an
- RFC) . . . . . . . . . . . . . . . . . . . . . . . . 104
- C.1. Changes in -15 . . . . . . . . . . . . . . . . . . . . . 104
- C.2. Changes in -14 . . . . . . . . . . . . . . . . . . . . . 105
- C.3. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 105
- C.4. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 106
- C.5. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 106
- C.6. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 107
- C.7. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 108
- C.8. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 109
- C.9. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 110
- C.10. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 111
- C.11. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 111
- C.12. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 112
- C.13. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 113
- C.14. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 113
- C.15. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 113
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
- Intellectual Property and Copyright Statements . . . . . . . . . 115
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 4]
-
-Internet-Draft CalDAV September 2006
-
-
-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 type. 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. Expires March 17, 2007 [Page 5]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 Appendices 3
- and 4 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 be either 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 calendar
- object resource format;
-
- o MUST support WebDAV Class 1 [RFC2518] (note that [I-D.ietf-webdav-
- 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]);
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 6]
-
-Internet-Draft CalDAV September 2006
-
-
- o MUST support ETags [RFC2616] with additional requirements
- specified in Section 5.3.4 of this document;
-
- 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 which 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 or to-do, or 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 7]
-
-Internet-Draft CalDAV September 2006
-
-
- 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
- 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.
- So 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 easier 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. Expires March 17, 2007 [Page 8]
-
-Internet-Draft CalDAV September 2006
-
-
-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 two VEVENT components 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 which 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).
-
- For example, given the following iCalendar object:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 9]
-
-Internet-Draft CalDAV September 2006
-
-
- BEGIN:VCALENDAR
- PRODID:-//Example Corp.//CalDAV Client//EN
- VERSION:2.0
- BEGIN:VEVENT
- UID:1 at example.com
- SUMMARY:One-off Meeting
- DTSTAMP:20041210T183904Z
- DTSTART:20041207T120000Z
- DTEND:20041207T130000Z
- END:VEVENT
- BEGIN:VEVENT
- UID:2 at example.com
- SUMMARY:Weekly Meeting
- DTSTAMP:20041210T183838Z
- DTSTART:20041206T120000Z
- DTEND:20041206T130000Z
- RRULE:FREQ=WEEKLY
- END:VEVENT
- BEGIN:VEVENT
- UID:2 at 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 at example.com", would be
- stored in its own calendar object resource. The two VEVENT
- components with the UID value "2 at 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>
-
- A calendar collection can be created through provisioning (e.g.,
- automatically created when a user's account is provisioned), or it
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 10]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 room). Note however that this document doesn't define
- what extra calendar collections are for. 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. Expires March 17, 2007 [Page 11]
-
-Internet-Draft CalDAV September 2006
-
-
-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, 3, access-control, calendar-access
- Date: Fri, 11 Nov 2005 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, methods,
- or privileges defined in this specification.
-
-5.2. Calendar Collection Properties
-
- This section defines properties that MAY be defined on 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. Expires March 17, 2007 [Page 12]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 <, >, & 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-timezone (#PCDATA)>
- PCDATA value: an iCalendar object with exactly one VTIMEZONE
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 13]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 & 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>
-
-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]).
-
- 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 14]
-
-Internet-Draft CalDAV September 2006
-
-
- 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.
-
- 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
- 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 15]
-
-Internet-Draft CalDAV September 2006
-
-
- "text/calendar" and iCalendar version 2.0, and clients can assume
- that.
-
- 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
- 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. Expires March 17, 2007 [Page 16]
-
-Internet-Draft CalDAV September 2006
-
-
- 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
- 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 time
- value in a calendar object resource stored in a calendar
- collection. Any attempt to store a calendar object resource using
- a date or 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. Expires March 17, 2007 [Page 17]
-
-Internet-Draft CalDAV September 2006
-
-
-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
- 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 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>
-
-5.2.8. CALDAV:max-instances Property
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 18]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 returned by a
- PROPFIND DAV:allprop request (as defined in Section 12.14.1 of
- [RFC2518]).
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 19]
-
-Internet-Draft CalDAV September 2006
-
-
- 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
-
- The creation of calendar collections and calendar object resources
- may be initiated by either a CalDAV client or by the CalDAV server.
- For example, a server might come pre-configured with a user's
- calendar collection, or the CalDAV client might request the server to
- create a new calendar collection for a given user. Servers might
- populate events as calendar objects inside a calendar collection, or
- clients might request the server to create events. Either way, both
- client and server MUST comply with the requirements in this document,
- and MUST understand objects appearing in calendar collections or
- according to the data model defined here.
-
-5.3.1. MKCALENDAR Method
-
- An HTTP request using the MKCALENDAR method creates a new calendar
- collection resource. A server MAY restrict calendar collection
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 20]
-
-Internet-Draft CalDAV September 2006
-
-
- creation to particular collections.
-
- 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 better help organize their data.
-
- 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:
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 21]
-
-Internet-Draft CalDAV September 2006
-
-
- (DAV:resource-must-be-null): A resource MUST NOT exist at the
- Request-URI;
-
- (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;
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 22]
-
-Internet-Draft CalDAV September 2006
-
-
- 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
-
- 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. Expires March 17, 2007 [Page 23]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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. Expires March 17, 2007 [Page 24]
-
-Internet-Draft CalDAV September 2006
-
-
- >> Response <<
-
- HTTP/1.1 201 Created
- Cache-Control: no-cache
- Date: Fri, 11 Nov 2005 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. Expires March 17, 2007 [Page 25]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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 at 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: Fri, 11 Nov 2005 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.
-
- When a COPY or MOVE operation of a calendar object resource into a
- calendar collection occurs.
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 26]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 time property values (for each recurring
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 27]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 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. Expires March 17, 2007 [Page 28]
-
-Internet-Draft CalDAV September 2006
-
-
- 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. Expires March 17, 2007 [Page 29]
-
-Internet-Draft CalDAV September 2006
-
-
- 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, this does not imply access
- to GET, HEAD, OPTIONS and PROPFIND on the resource -- 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 either are 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. Expires March 17, 2007 [Page 30]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 based on the value of the
- Depth request header.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 31]
-
-Internet-Draft CalDAV September 2006
-
-
-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 11th, 2005 in no specific
- time zone, while the DATE-TIME value "20051111T111100" represents
- November 11th, 2005 at 11:11 AM 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, 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. Expires March 17, 2007 [Page 32]
-
-Internet-Draft CalDAV September 2006
-
-
- When such time range filtering is used, special consideration must be
- given to recurring calendar components such as VEVENT and VTODO
- components. 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 compared to stored
- calendar data. Since iCalendar data is by default encoded in the
- UTF-8 charset and may include characters outside of 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 [I-D.newman-i18n-comparator] 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
- [I-D.newman-i18n-comparator] 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 [I-D.newman-i18n-comparator],
- 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 [I-D.newman-i18n-comparator] Section 3.1), the server MUST
- default to using "i;ascii-casemap" as the collation.
-
- Wildcards (as defined in [I-D.newman-i18n-comparator] 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. Expires March 17, 2007 [Page 33]
-
-Internet-Draft CalDAV September 2006
-
-
-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 whether all calendar components and properties should
- be returned or only particular ones. See CALDAV:calendar-data in
- Section 9.6.
-
- 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 34]
-
-Internet-Draft CalDAV September 2006
-
-
- recurrence set, referred to as the "overridden components".
-
- A CalDAV client 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.
-
- A CalDAV client with no support for recurrence properties (i.e.,
- EXDATE, EXRULE, RDATE and RRULE) and possibly VTIMEZONE components,
- or a client not willing 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 which the server
- does not support queries on.
-
-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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 35]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 which does not exist is
- an error and MUST be noted with a response XML element which 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
- 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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 36]
-
-Internet-Draft CalDAV September 2006
-
-
- instance, a CALDAV:filter cannot nest a <C:comp name="VEVENT">
- element in a <C:comp name="VTODO"> element, or 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 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;
-
- (CALDAV:max-date-time): Any XML element specifying a range of time
- MUST have its start or end date or 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;
-
- (CALDAV:supported-collation): Any XML attribute specifying a
- collation MUST specify a collation supported by the server as
- described in Section 7.5.
-
- 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.
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 37]
-
-Internet-Draft CalDAV September 2006
-
-
-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 4th, 2006 at 00:00:00 AM UTC to January 5th,
- 2006 at 00:00:00 AM 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 of 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. Expires March 17, 2007 [Page 38]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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: Fri, 11 Nov 2005 09:32:12 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 39]
-
-Internet-Draft CalDAV September 2006
-
-
- <?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 at 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 at 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 at example.com
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 40]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at 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. Expires March 17, 2007 [Page 41]
-
-Internet-Draft CalDAV September 2006
-
-
-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 3rd, 2006 at 00:
- 00:00 AM UTC to January 5th, 2006 at 00:00:00 AM 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: Fri, 11 Nov 2006 09:32:12 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 42]
-
-Internet-Draft CalDAV September 2006
-
-
- <?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 at 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 at example.com
- END:VEVENT
- END:VCALENDAR
- </C:calendar-data>
- </D:prop>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 43]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART;TZID=US/Eastern:20060104T100000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at example.com
- X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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. Expires March 17, 2007 [Page 44]
-
-Internet-Draft CalDAV September 2006
-
-
- </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 2nd, 2006 at 00:
- 00:00 AM UTC to January 5th, 2006 at 00:00:00 AM 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: Fri, 11 Nov 2006 09:32:12 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 45]
-
-Internet-Draft CalDAV September 2006
-
-
- <?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 at example.com
- END:VEVENT
- BEGIN:VEVENT
- DTSTAMP:20060206T001121Z
- DTSTART:20060104T190000
- DURATION:PT1H
- RECURRENCE-ID:20060104T170000
- SUMMARY:Event #2 bis
- UID:00959BC664CA650E933C892C at 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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART:20060104T150000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 46]
-
-Internet-Draft CalDAV September 2006
-
-
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at example.com
- X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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.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 2nd, 2006 at 00:00:00 AM UTC (inclusively) to
- January 3rd, 2006 at 00:00:00 AM 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 47]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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. Expires March 17, 2007 [Page 48]
-
-Internet-Draft CalDAV September 2006
-
-
- >> Response <<
-
- HTTP/1.1 207 Multi-Status
- Date: Fri, 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 at example.com
- UID:76ef34-54a3d2 at 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>
-
-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.
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 49]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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. Expires March 17, 2007 [Page 50]
-
-Internet-Draft CalDAV September 2006
-
-
- >> Response <<
-
- HTTP/1.1 207 Multi-Status
- Date: Fri, 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 at 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 at example.com".
-
- See Appendix B for the calendar data being targeted by this example.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 51]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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 at 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: Fri, 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. Expires March 17, 2007 [Page 52]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART;TZID=US/Eastern:20060104T100000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at example.com
- X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at 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. Expires March 17, 2007 [Page 53]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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 at 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: Fri, 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. Expires March 17, 2007 [Page 54]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART;TZID=US/Eastern:20060104T100000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at example.com
- X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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. Expires March 17, 2007 [Page 55]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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: Fri, 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. Expires March 17, 2007 [Page 56]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at 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. Expires March 17, 2007 [Page 57]
-
-Internet-Draft CalDAV September 2006
-
-
- END:VTIMEZONE
- BEGIN:VEVENT
- DTSTAMP:20060206T001121Z
- DTSTART;TZID=US/Eastern:20060102T120000
- DURATION:PT1H
- RRULE:FREQ=DAILY;COUNT=5
- SUMMARY:Event #2
- UID:00959BC664CA650E933C892C at 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 at 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 at 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. Expires March 17, 2007 [Page 58]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART;TZID=US/Eastern:20060104T100000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at example.com
- X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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. Expires March 17, 2007 [Page 59]
-
-Internet-Draft CalDAV September 2006
-
-
- >> 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: Fri, 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. Expires March 17, 2007 [Page 60]
-
-Internet-Draft CalDAV September 2006
-
-
- DTSTAMP:20060205T235335Z
- DUE;VALUE=DATE:20060104
- STATUS:NEEDS-ACTION
- SUMMARY:Task #1
- UID:DDDEEB7915FA61233B861457 at 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 at 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. Expires March 17, 2007 [Page 61]
-
-Internet-Draft CalDAV September 2006
-
-
-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 and 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: Fri, 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. Expires March 17, 2007 [Page 62]
-
-Internet-Draft CalDAV September 2006
-
-
-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 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 time values greater than or
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 63]
-
-Internet-Draft CalDAV September 2006
-
-
- 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;
-
- (CALDAV:max-date-time): Any XML element specifying a range of time
- MUST have its start or end date or 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;
-
- 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: Fri, 11 Nov 2006 09:32:12 GMT
- Content-Type: application/xml; charset="utf-8"
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 64]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 at 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. Expires March 17, 2007 [Page 65]
-
-Internet-Draft CalDAV September 2006
-
-
- </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 which 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 to generate 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 period 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. Expires March 17, 2007 [Page 66]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 calendar object resources to be considered to compute the
- response.
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 67]
-
-Internet-Draft CalDAV September 2006
-
-
-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
- AM and 5:00 PM EST (2:00 PM and 10:00 PM UTC) on the 4th January
- 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: Fri, 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
-
-
-8. Guidelines
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 68]
-
-Internet-Draft CalDAV September 2006
-
-
-8.1. Client-to-client Interoperability
-
- There are a number of actions clients can take which will be legal
- (the server will not return errors) but which 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, make changes offline, and 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.
-
-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
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 69]
-
-Internet-Draft CalDAV September 2006
-
-
- 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
- of 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, it 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. Expires March 17, 2007 [Page 70]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 their 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. Expires March 17, 2007 [Page 71]
-
-Internet-Draft CalDAV September 2006
-
-
-8.2.2. Restrict the Properties Returned
-
- Clients 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)
- clients 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 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 when 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. E.g., 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 which is a calendar collection. The client may
- also be able to browse WebDAV collections to find calendar
- collections.
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 72]
-
-Internet-Draft CalDAV September 2006
-
-
- 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. Expires March 17, 2007 [Page 73]
-
-Internet-Draft CalDAV September 2006
-
-
- <?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" all as matching DAV:displayname
- values, and 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 on
- 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 do that 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 attachment
- requires the entire attachment to be re-uploaded.
-
- o Clients synchronizing a changed calendar object resource have to
- download the entire calendar object resource even if the
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 74]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 which 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
- which 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
- storage of attachments within child collections of calendar
- collections is that ACL inheritance might make it easier to grant the
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 75]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 which 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 which
- 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 either 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 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.
- Clients MAY execute alarms that are downloaded in this fashion,
- possibly based on user preference. If a client is only doing read
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 76]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 who an alarm is intended for.
- Addressing those issues might require extensions to iCalendar, for
- example to store alarms per-user or indicate which user a VALARM was
- intended for. 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)>
-
-9.3. CALDAV:mkcalendar-response XML Element
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 77]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 [I-D.newman-i18n-comparator].
-
- 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. Expires March 17, 2007 [Page 78]
-
-Internet-Draft CalDAV September 2006
-
-
-9.6. CALDAV:calendar-data XML Element
-
- Name: calendar-data
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Used to (1) specify a supported media type for calendar
- object resources when nested in the CALDAV:supported-calendar-data
- property; (2) specify which parts of a calendar object resource
- should be returned by a given calendaring REPORT; and (3) specify
- 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 it is not returned in PROPFIND
- responses nor used in PROPPATCH requests.
-
- Note: The iCalendar data embedded within the CALDAV:calendar-data XML
- element MUST follow the standard XML character data encoding
- rules, including use of <, >, & etc entity encoding or
- the use of a <![CDATA[ ... ]]> construct. In the later case the
- iCalendar data cannot contain the character sequence "]]>" which
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 79]
-
-Internet-Draft CalDAV September 2006
-
-
- is the end delimiter for the CDATA section.
-
- Definition:
-
- <!ELEMENT calendar-data ((comp?, (expand |
- limit-recurrence-set)?,
- limit-freebusy-set?) |
- #PCDATA)?>
- PCDATA value: iCalendar object
-
- <!ATTLIST calendar-data content-type CDATA "text/calendar">
- version CDATA "2.0">
- content-type value: a MIME media type
- version value: a version string
-
-9.6.1. CALDAV:comp XML Element
-
- Name: comp
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Defines which component types to return.
-
- 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 element 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
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 80]
-
-Internet-Draft CalDAV September 2006
-
-
- 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>
-
- 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.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 81]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 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:
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 82]
-
-Internet-Draft CalDAV September 2006
-
-
- <!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
- 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 intersect
- 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"
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 83]
-
-Internet-Draft CalDAV September 2006
-
-
-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
- 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 FREEBUSY property value
- intersect 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)>
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 84]
-
-Internet-Draft CalDAV September 2006
-
-
-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 the queried
- calendar component type (e.g., "VEVENT"). A calendar object
- resource is said to match a CALDAV:comp-filter if:
-
- * A component of the type specified by the "name" attribute
- exists, and the CALDAV:comp-filter is empty, or it contains at
- least one recurrence instance scheduled to overlap a given time
- range if a CALDAV:time-range XML element is specified, and that
- any CALDAV:prop-filter and CALDAV:comp-filter child elements
- also match.
-
- or:
-
- * A component of the type specified by the "name" attribute does
- not exist, and the CALDAV:is-not-defined element is specified.
-
- Definition:
-
- <!ELEMENT comp-filter (is-not-defined | (time-range?,
- prop-filter*, comp-filter*))>
-
- <!ATTLIST comp-filter name CDATA #REQUIRED>
- name value: a calendar component name (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 search
- criteria on a specific calendar property (e.g., CATEGORIES) in the
- scope of a given CALDAV:comp-filter. A calendar component is said
- to match a CALDAV:prop-filter if:
-
- * A property of the type specified by the "name" attribute
- exists, and the CALDAV:prop-filter is empty, or it matches the
- CALDAV:time-range XML element or CALDAV:text-match conditions
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 85]
-
-Internet-Draft CalDAV September 2006
-
-
- if specified, and that any CALDAV:param-filter child elements
- also match.
-
- or:
-
- * A property of the type specified by the "name" attribute does
- not exist, and the CALDAV:is-not-defined element is specified.
-
- 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 search
- criteria on a specific calendar property parameter (e.g.,
- PARTSTAT) in the scope of a given CALDAV:prop-filter. A calendar
- property is said to match a CALDAV:param-filter if:
-
- * A parameter of the type specified by the "name" attribute
- exists, and the CALDAV:param-filter is empty, or it matches the
- CALDAV:text-match conditions if specified.
-
- or:
-
- * A parameter of the type specified by the "name" attribute does
- not exist, and the CALDAV:is-not-defined element is specified.
-
- Definition:
-
- <!ELEMENT param-filter (is-not-defined | text-match)?>
-
- <!ATTLIST param-filter name CDATA #REQUIRED>
- name value: a property parameter name (e.g., "PARTSTAT")
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 86]
-
-Internet-Draft CalDAV September 2006
-
-
-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.
-
- 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:
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 87]
-
-Internet-Draft CalDAV September 2006
-
-
- <!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 intersect 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 <, >, & 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 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.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 88]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 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 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
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 89]
-
-Internet-Draft CalDAV September 2006
-
-
- +---------------------------------------------------------------+
- | 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. Expires March 17, 2007 [Page 90]
-
-Internet-Draft CalDAV September 2006
-
-
- +-------------------------------------------------------------------+
- | 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. Expires March 17, 2007 [Page 91]
-
-Internet-Draft CalDAV September 2006
-
-
- +----------------------------------------------------+
- | 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 |
- +---+---+----------------------------------------------+
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 92]
-
-Internet-Draft CalDAV September 2006
-
-
- A VALARM component is said to overlap a given time range if the
- following condition holds:
-
- (start <= trigger-time) AND (end > trigger-time)
-
- 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 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.
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 93]
-
-Internet-Draft CalDAV September 2006
-
-
- Definition:
-
- <!ELEMENT calendar-multiget ((DAV:allprop |
- DAV:propname |
- DAV:prop)?, DAV:href+)>
-
-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 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.
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 94]
-
-Internet-Draft CalDAV September 2006
-
-
- 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 and 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.
-
- 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], as discussed in those documents.
-
-
-12. IANA Consideration
-
- 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 "Author's Address" section of this
- document.
-
- XML: None. Namespace URIs do not represent an XML specification.
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 95]
-
-Internet-Draft CalDAV September 2006
-
-
-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, Mike Douglass,
- Ted Hardie, Sam Hartman, Helge Hess, Jeff McCullough, Alexey
- Melnikov, Dan Mosedale, Brian Moseley, Kervin L. Pierre, Julian F.
- Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon
- Vaillancourt, Jim Whitehead.
-
- 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
-
- [I-D.newman-i18n-comparator]
- Newman, C., "Internet Application Protocol Collation
- Registry", draft-newman-i18n-comparator-13 (work in
- progress), August 2006.
-
- [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.
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 96]
-
-Internet-Draft CalDAV September 2006
-
-
- [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.
-
- [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.
-
- [W3C.REC-xml-20060816]
- Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C.,
- and E. Maler, "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
-
- [I-D.ietf-webdav-rfc2518bis]
- Dusseault, L., "HTTP Extensions for Distributed Authoring
- - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in
- progress), May 2006.
-
- [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.
-
-
-Appendix A. CalDAV Method Privilege Table (Normative)
-
- The following table extends the WebDAV Method Privilege Table
- specified in Appendix B of [RFC3744].
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 97]
-
-Internet-Draft CalDAV September 2006
-
-
- +------------+------------------------------------------------------+
- | 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 it would be
- 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:allprop/>
- <C:allcomp/>
- </C:comp-filter>
- </C:filter>
- </C:calendar-query>
-
- >> Response <<
-
- HTTP/1.1 207 Multi-Status
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 98]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at 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>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 99]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at 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 at 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>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 100]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at example.com
- ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
- DTSTAMP:20060206T001220Z
- DTSTART;TZID=US/Eastern:20060104T100000
- DURATION:PT1H
- LAST-MODIFIED:20060206T001330Z
- ORGANIZER:mailto:cyrus at example.com
- SEQUENCE:1
- STATUS:TENTATIVE
- SUMMARY:Event #3
- UID:DC6C50A017428C5216A2F1CD at 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>
- <D:getetag>"fffff-abcd4"</D:getetag>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 101]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at 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 at 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>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 102]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at 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 at example.com
- END:VTODO
- END:VCALENDAR
- </C:calendar-data>
- </D:prop>
- <D:status>HTTP/1.1 200 OK</D:status>
- </D:propstat>
- </D:response>
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 103]
-
-Internet-Draft CalDAV September 2006
-
-
- <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 at example.com
- UID:76ef34-54a3d2 at 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>
-
-
-Appendix C. Changes (to be removed prior to publication as an RFC)
-
-C.1. Changes in -15
-
- a. Switched to using collations for text-match element in calendar-
- query report.
-
- b. Removed caseless attribute from text-match element.
-
- c. Removed UNICODE4 reference.
-
- d. Removed mailing list comment.
-
- e. Made calendar-home-set property a SHOULD as it was in previous
- drafts.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 104]
-
-Internet-Draft CalDAV September 2006
-
-
- f. Now require https download of external attachments.
-
- g. Changed some improper uses of 2119 terms to lowercase.
-
- h. Updated some references to latest specs.
-
-C.2. Changes in -14
-
- a. Reverted to normative reference to 2518 and added informative
- reference to 2518bis.
-
- b. Reinserted section describing preconditions/postconditions.
-
- c. Removed redundant compliance statement in last paragraph of
- Section 3.
-
- d. Clarify that only text/calendar is allowed if supported-calendar-
- data property is not present.
-
- e. Removed redundant compliance statement in Conformance paragraph
- of Section 6.2.1.
-
- f. Removed redundant compliance statement in first paragraph of
- Section 7.5.
-
- g. Fixed incorrect whitespace in elements in example in Section
- 7.7.6.
-
- h. Fixed incorrect CDATA descriptions in various places.
-
-C.3. Changes in -13
-
- a. Changed mailing list draft description.
-
- b. Added security review suggested text to Security Considerations.
-
- c. Changed external attachment support to require http URI
- downloads, and optionally others.
-
- d. Added reference to text-match element in Internationalization
- Considerations section.
-
- e. Changed 'undefined' to 'not specified here' in ETag behavior
- section.
-
- f. Added reference to RFC4346 with note that it obsoletes RFC2246
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 105]
-
-Internet-Draft CalDAV September 2006
-
-
-C.4. Changes in -12
-
- a. Changed requirements for ETags on PUT to better reflect the needs
- of CalDAV clients wrt synchronization and reflect what other
- standards define or do not define.
-
- b. Changed CALDAV:read-free-busy privilege so that it is also
- defined on regular collections.
-
-C.5. Changes in -11
-
- a. Added statement that calendar-query Depth defaults to zero if
- header is not present. Fixed one multiget example's Depth
- header.
-
- b. Fixed reference to WebDAV Quota RFC.
-
- c. Changed DAV:resource to DAV:href in CALDAV:no-uid-conflict
- element.
-
- d. Added CALDAV:calendar-collection-location-ok pre-condition for
- COPY and MOVE.
-
- e. Added CALDAV:max-resource-size, CALDAV:min-date-time, CALDAV:max-
- date-time, CALDAV:max-instances, CALDAV:max-attendees-per-
- instance properties and preconditions.
-
- f. Changed to 2518bis reference.
-
- g. Now require 2518bis Class 3 behaviour.
-
- h. Fixed indentation in examples and removed bogus whitespace before
- </C:calendar-data> tags.
-
- i. Fixed </C:calendar-data/> typo.
-
- j. Added text to <C:calendar-data> element definition as a reminder
- about the need to do XML character data encoding on any iCalendar
- data within that element.
-
- k. Major reworking of CALDAV:time-range element description to
- better cover all possibilities for each type of component based
- on which properties are present.
-
- l. Added is-not-defined and negate-condition options to reports and
- a new example to illustrate use of those.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 106]
-
-Internet-Draft CalDAV September 2006
-
-
- m. Fixed descriptions of some calendar collection properties.
-
- n. Removed section describing preconditions/postconditions as this
- is incorporated into 2518bis.
-
- o. Clarified issue about separate component types in separate
- resources.
-
- p. Reworded section on servers being allowed to reject changes to
- their own private use iCal values.
-
- q. Clarified overridden component 'current' and 'original' time
- range overlap.
-
- r. Added more section references for XML element definitions.
-
- s. Reworded limit-recurrence-set definition to try and make it clear
- that mast component is always returned, but only some overridden
- one are returned.
-
- t. Clarified dependence on UNICODE reference for caseless matching.
-
-C.6. Changes in -10
-
- a. Added new section about support for X- items when storing data.
-
- b. Added new precondition to allow servers to reject queries on
- unsupported X- items, and a new example.
-
- c. Added new text about always supporting X- in calendar-data.
-
- d. Created new section for PUT, COPY and MOVE preconditions.
-
- e. Report examples re-done with full listing of calendar data in
- Appendix.
-
- f. Removed description of using UID, SUMMARY etc as resource name.
-
- g. Indicate that calendar object resource may contain only
- overridden components.
-
- h. Add security consideration about not expose details in resource
- names.
-
- i. Add constraint that free-busy-query can only be run on a
- collection.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 107]
-
-Internet-Draft CalDAV September 2006
-
-
- j. Add preconditions for calendar-timezone property/elements in
- MKCALENDAR, PROPPATCH and calendar-query REPORT.
-
- k. Fix principal-match example.
-
-C.7. Changes in -09
-
- a. Numerous editorial changes.
-
- b. Removed the CALDAV:is-defined XML element.
-
- c. Removed section on privilege aggregation.
-
- d. Renamed the CALDAV:expand-recurrence-set XML element to CALDAV:
- expand and clarified the server behavior.
-
- e. Renamed the CALDAV:calendar-component-restriction-set XML
- element to CALDAV:supported-calendar-component-set.
-
- f. Renamed the CALDAV:calendar-restrictions XML element to CALDAV:
- supported-calendar-data.
-
- g. Renamed some preconditions as "success conditions" instead of
- "failure causes". For instance, the precondition CALDAV:
- calendar-collection-location-bad has been renamed to CALDAV:
- calendar-collection-location-ok.
-
- h. Reordered some sections.
-
- i. Clarified the definition of CALDAV:time-range to specify that a
- repeating VALARM component is said to intersect a given time
- range if at least one of its trigger intersect the time range.
-
- j. Clarified that calendar object resources stored in calendar
- collections MUST NOT specify the iCalendar METHOD property.
-
- k. Clarified that CALDAV:calendar-data XML element is not a WebDAV
- property even though it is specified in the DAV:prop XML element
- in both calendaring REPORT requests and responses.
-
- l. Clarified CALDAV:limit-recurrence-set with respect to the RANGE
- parameter on the RECURRENCE-ID property.
-
- m. Changed the CALDAV:free-busy-query XML element to contain
- exactly one CALDAV:time-range XML element.
-
- n. Changed many ELEMENT and ATTLIST declarations to comply with DTD
- syntax.
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 108]
-
-Internet-Draft CalDAV September 2006
-
-
- o. Changed XML element CALDAV:calendar-query to allow new XML
- element CALDAV:timezone.
-
- p. Changed the XML elements CALDAV:time-range, CALDAV:expand and
- CALDAV:limit-recurrence-set to only allow DATE-TIME with UTC
- time values for the "start" and "end" attributes.
-
- q. Changed description of CALDAV:limit-recurrence-set to specify
- that re-scheduled "overridden" recurrence instances whose
- original scheduled time used to overlap the time range specified
- by the "start" and "end" attribute should always be returned in
- a REPORT response.
-
- r. Changed the description of the value of CALDAV:calendar-data XML
- element to specify that the CR character (US-ASCII decimal 13)
- MAY be omitted in the iCalendar object specified in this XML
- element.
-
- s. Added specific requirements for entity tags support.
-
- t. Added more preconditions.
-
- u. Added further guidelines about finding calendars.
-
- v. Added XML element CALDAV:limit-freebusy-set to limit the set of
- FREEBUSY property values returned in VFREEBUSY components.
-
- w. Added property CALDAV:calendar-timezone on calendar collections.
-
- x. Added XML element CALDAV:timezone to override the CALDAV:
- calendar-timezone property for a given CALDAV:calendar-query
- REPORT request.
-
- y. Added text on the conversion of "floating date" and "floating
- time" values to date with UTC time values.
-
- z. Completed internationalization considerations section.
-
- aa. Completed security considerations section.
-
-C.8. Changes in -08
-
- a. Removed statement that said that client SHOULD always request
- DAV:getetag in calendar REPORTs.
-
- b. Removed redefiniton of DAV:response.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 109]
-
-Internet-Draft CalDAV September 2006
-
-
- c. Removed XML elements CALDAV:calendar-data-only.
-
- d. Removed resource type CALDAV:calendar-home.
-
- e. Moved the CALDAV:calendar-data element in the DAV:prop element in
- requests, and in the DAV:propstat element in responses.
-
- f. Further defined the request body of MKCALENDAR to allow clients
- to set properties at calendar collection creation time.
-
- g. Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set
-
- h. Clarified the fact that calendar collections may only contain
- calendar object resources and ordinary collections.
-
- i. Clarified that calendar REPORTs should only be applied to
- calendar object resources contained in calendar collections.
-
- j. Changed the CALDAV:calendar-component-restriction-set and CALDAV:
- calendar-restriction properties to always be protected.
-
- k. Changed to use existing postcondition DAV:needs-privileges
- instead of a new CALDAV:insufficient-privilege postcondition.
-
- l. Added example for limit-recurrence-set.
-
- m. Added example for expand-recurrence-set.
-
- n. Moved CALDAV:calendar-address-set in the calendar-schedule draft
- and renamed it to CALDAV:calendar-user-address-set.
-
- o. Added guidelines on attachments and alarms.
-
-C.9. Changes in -07
-
- a. Various editorial changes.
-
- b. Added properties calendar-restrictions and calendar-component-
- restriction-set on calendar collections.
-
- c. Added properties calendar-home-URL and calendar-address-set on
- principal resources.
-
- d. Removed property calendar-URL on principal resources.
-
- e. Added pre- and postconditions to reports.
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 110]
-
-Internet-Draft CalDAV September 2006
-
-
- f. Added new XML elements calendar-data-only and limit-recurrent-
- set.
-
- g. Modified calendar-data XML element to support the attributes
- content-type and version.
-
- h. Reorganised sections 3, 4, 5 & 6 into two sections and re-ordered
- sub-sections.
-
- i. Added comment about client not setting a duplicate displayname.
-
- j. Removed three CalDAV OPTIONS requests.
-
- k. Changed "authenticated user" to "user" in various places.
-
- l. Rewrote section on calendar object resource restrictions for
- better clarity.
-
-C.10. Changes in -06
-
- a. Reworded section "Recurrence and the Data Model".
-
- b. Removed timezone collection feature.
-
- c. Removed ability for a server to return the Location header on a
- successful PUT request.
-
- d. Clarified restrictions on calendar object resources contained in
- calendar collections.
-
- e. Added preconditions on PUT in calendar collections.
-
- f. Added informative "Guidelines" section, with information on
- locking and how to find calendar collections.
-
- g. Moved "Sychronization Operations" section in the "Guidelines"
- section.
-
-C.11. Changes in -05
-
- a. Removed a lot of non-normative text.
-
- b. Removed property promotion/demotion requirements.
-
- c. Removed calendar-owner and cal-scale properties.
-
- d. Removed 'ical' prefix/text from element names.
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 111]
-
-Internet-Draft CalDAV September 2006
-
-
- e. Relaxed WebDAV Class 2 (locking) requirement to a MAY.
-
- f. Relaxed MKCALENDAR requirement to a SHOULD.
-
- g. Moved the XML Namespace section in the Introduction.
-
- h. Added CALDAV: prefix to CalDAV XML elements in the text.
-
- i. Added CALDAV:calendar-multiget report.
-
- j. Added CALDAV:free-busy-query report.
-
- k. Added CALDAV:calendar-description property.
-
- l. Changed CALDAV:calendar-query-result element name to CALDAV:
- calendar-data
-
- m. Added description and examples of handling timezones.
-
- n. Added mandatory "start" and "end" attributes to the CALDAV:
- expand-recurrence-set element.
-
- o. Added three CalDAV OPTIONS requests.
-
- p. Grouped XML Element declarations in a separate section.
-
-C.12. Changes in -04
-
- a. Added a note about the HTTP Location response header.
-
- b. Added report calendar-query.
-
- c. Removed reports calendar-property-search and calendar-time-range.
-
- d. Removed section on CalDAV and timezones.
-
- e. Added requirement to return ETag on creation.
-
- f. Revised data model to remove sub-collections from calendar
- collection.
-
- g. Added informative references section.
-
- h. Removed dependencies on DASL.
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 112]
-
-Internet-Draft CalDAV September 2006
-
-
-C.13. Changes in -03
-
- a. Removed Calendar Containers (simplification that doesn't seem to
- remove much functionality)
-
- b. Added MKCALENDAR to create calendars and all sub-collections
-
- c. Added cal-scale property to calendars
-
-C.14. Changes in -02
-
- Basically still adding major sections of content:
-
- a. Defined new field values to the OPTIONS "DAV:" response header
-
- b. Added new resource properties
-
- c. Added new principal properties
-
- d. Added new SCHEDULE method and related headers
-
- e. Added new privileges for scheduling
-
-C.15. Changes in -01
-
- a. Added section on privileges for calendaring, extending WebDAV ACL
- privilege set
-
- b. Defined what to do with unrecognized properties in the bodies of
- iCalendar events, with respect to property promotion/demotion
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 113]
-
-Internet-Draft CalDAV September 2006
-
-
-Authors' Addresses
-
- Cyrus Daboo
- Apple Computer, Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus at daboo.name
- URI: http://www.apple.com/
-
-
- Bernard Desruisseaux
- Oracle Corporation
- 600 Blvd. de Maisonneuve West
- Suite 1900
- Montreal, QC H3A 3J2
- CA
-
- Email: bernard.desruisseaux at oracle.com
- URI: http://www.oracle.com/
-
-
- Lisa Dusseault
- Open Source Application Foundation
- 2064 Edgewood Dr.
- Palo Alto, CA 94303
- US
-
- Email: lisa at osafoundation.org
- URI: http://www.osafoundation.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 114]
-
-Internet-Draft CalDAV September 2006
-
-
-Intellectual Property Statement
-
- 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 at ietf.org.
-
-
-Disclaimer of Validity
-
- 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 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.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). 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.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Daboo, et al. Expires March 17, 2007 [Page 115]
-
Copied: CalendarServer/trunk/doc/RFC/rfc4791-CalDAV.txt (from rev 1399, CalendarServer/trunk/doc/RFC/draft-dusseault-caldav.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/rfc4791-CalDAV.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/rfc4791-CalDAV.txt 2007-03-16 03:10:54 UTC (rev 1400)
@@ -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 at example.com
+ SUMMARY:One-off Meeting
+ DTSTAMP:20041210T183904Z
+ DTSTART:20041207T120000Z
+ DTEND:20041207T130000Z
+ END:VEVENT
+ BEGIN:VEVENT
+ UID:2 at example.com
+ SUMMARY:Weekly Meeting
+ DTSTAMP:20041210T183838Z
+ DTSTART:20041206T120000Z
+ DTEND:20041206T130000Z
+ RRULE:FREQ=WEEKLY
+ END:VEVENT
+ BEGIN:VEVENT
+ UID:2 at 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 at example.com" would be
+ stored in its own calendar object resource. The two VEVENT
+ components with the UID value "2 at 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 <, >, & 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 & 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>
+
+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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at example.com
+ END:VEVENT
+ BEGIN:VEVENT
+ DTSTAMP:20060206T001121Z
+ DTSTART:20060104T190000
+ DURATION:PT1H
+ RECURRENCE-ID:20060104T170000
+ SUMMARY:Event #2 bis
+ UID:00959BC664CA650E933C892C at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at 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 at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at example.com
+ UID:76ef34-54a3d2 at 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 at 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 at 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 at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at 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 at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at 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 at 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 at 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 at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at example.com
+ X-ABC-GUID:E1CX5Dr-0007ym-Hz at 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 at 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 at 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 at 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 <, >, & 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 <, >, & 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 at 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 at 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 at 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 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa at example.com
+ DTSTAMP:20060206T001220Z
+ DTSTART;TZID=US/Eastern:20060104T100000
+ DURATION:PT1H
+ LAST-MODIFIED:20060206T001330Z
+ ORGANIZER:mailto:cyrus at example.com
+ SEQUENCE:1
+ STATUS:TENTATIVE
+ SUMMARY:Event #3
+ UID:DC6C50A017428C5216A2F1CD at 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 at 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 at 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 at 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 at 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 at example.com
+ UID:76ef34-54a3d2 at 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 at 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 at oracle.com
+ URI: http://www.oracle.com/
+
+
+ Lisa Dusseault
+ CommerceNet
+ 169 University Ave.
+ Palo Alto, CA 94301
+ USA
+
+ EMail: ldusseault at 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 at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Daboo, et al. Standards Track [Page 107]
+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20070315/66660234/attachment.html
More information about the calendarserver-changes
mailing list