WDIFF

draft-dusseault-caldav-04.txt --> draft-dusseault-caldav-05.txt

Network Working Group C. Daboo
Internet-Draft ISAMET
Expires: June 13, August 14, 2005 B. Desruisseaux
Oracle
L. Dusseault
OSAF
December 13, 2004
February 10, 2005

Calendaring and Scheduling Extensions to WebDAV (CalDAV)
draft-dusseault-caldav-04
draft-dusseault-caldav-05

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.

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 June 13, August 14, 2005.

Abstract

This document specifies a set of methods, headers headers, message bodies,
properties, and resource types reports that define the calendaring and scheduling extension calendar access extensions to the
WebDAV protocol. The new protocol elements are intended to make
WebDAV-based calendaring an intereropable standard that supports

Daboo, et al. Expires June 13, August 14, 2005 [Page 1]

Internet-Draft CalDAV December 2004 February 2005

WebDAV-based calendaring and scheduling an interoperable standard
that supports single-user calendar access, calendar sharing, and
calendar publishing.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Advantages of WebDAV for Calendar Access XML Namespaces . . . . . . . . . . 5
1.1.1 HTTP URLs for Calendar Objects . . . . . . . . . . . . 5
1.1.2 Web Services and Web Interfaces
1.2 Notational Conventions . . . . . . . . . . . 6
1.1.3 Client Implementations from Simple to Rich . . . . . . 6
1.1.4 Support for lock feature . 5
1.3 Method Preconditions and Postconditions . . . . . . . . . 6
2. Required CalDAV features . . . . . 7
1.1.5 Support for access control . . . . . . . . . . . . . . 7
1.1.6 Security, Implementations and Deployed Base
3. Calendaring Data Model . . . . . 8
1.1.7 Migration, Synchronization and Offline
Functionality . . . . . . . . . . . . . . . 8
3.1 Calendar Server . . . . . 8
1.1.8 Clear extensibility model . . . . . . . . . . . . . . 8
2. Required CalDAV features . . 8
3.2 Recurrence and the Data Model . . . . . . . . . . . . . . 9
3.3 Timezones . . . 10
3. CalDAV Support Discovery . . . . . . . . . . . . . . . . . . . 11
3.1 Example: Using OPTIONS for the Discovery of Support
for CalDAV . . 9
4. New Resource Types . . . . . . . . . . . . . . . . . . . . . . 11
4. Calendaring Data Model .
4.1 Calendar Collection . . . . . . . . . . . . . . . . . . . 12
4.1 11
4.2 iCalendar Components within the Calendar Repository or Server Collection . . . 11
5. Creating Resources . . . . . . . . . . . 12
4.2 Recurrence and the Data Model . . . . . . . . . . . 13
5.1 MKCALENDAR Method . . . . 13
4.3 Scheduling, Fanout and the Data model . . . . . . . . . . 13
5. New Resource Types . . . . . . 13
5.1.1 Status Codes . . . . . . . . . . . . . . . . 16
5.1 Calendar Collection . . . . . 14
5.1.2 Example - MKCALENDAR . . . . . . . . . . . . . . 16
5.1.1 iCalendar Components within the Calendar Collection . 16 . . 15
5.2 iTIP Inbox Collection Additional OPTIONS Semantics . . . . . . . . . . . . . . . 15
5.2.1 Capability Discovery . . . . 17
5.3 iTIP Outbox Collection . . . . . . . . . . . . . 15
5.2.1.1 Example: Using OPTIONS for the Discovery of
Support for CalDAV . . . . . 18
6. Creating Resources . . . . . . . . . . . 15
5.2.2 CALDAV:calendar-collection-set OPTIONS request . . . . 16
5.2.3 CALDAV:current-user-calendar-collection-set
OPTIONS request . . . . . . . 19
6.1 MKCALENDAR for creating calendars . . . . . . . . . . . . 19
6.1.1 MKCALENDAR 16
5.2.4 CALDAV:timezone-collection-set OPTIONS request . . . . 17
5.2.5 Example - OPTIONS . . . . . . . . . . . . . . . . . . 20
6.2 18
5.3 Creating component calendar resources . . . . . . . . . . . . . . . 20
7. Users and Groups 18
6. Calendaring Properties . . . . . . . . . . . . . . . . . . . . 21
6.1 CALDAV:calendar-description Property . . . 22
8. Property Promotion and Demotion . . . . . . . . 21
7. Calendaring Access Control . . . . . . . 23
9. Scheduling and Fanout . . . . . . . . . . . 22
7.1 Calendaring Privileges . . . . . . . . . 24
9.1 SCHEDULE Method for WebDAV . . . . . . . . . 22
7.1.1 CALDAV:view-free-busy Privilege . . . . . . . 25
9.1.1 Status Codes for use with 207 (Multi-Status) . . . . 22
7.1.2 Privilege aggregation and the
DAV:supported-privilege-set property . 26
9.1.2 Example - Simple appointment invitation . . . . . . . 28
9.2 Retrieving incoming iTIP Messages . 22
7.1.2.1 Partial example of DAV:supported-privilege-set
property . . . . . . . . . . . 29
9.2.1 Example - Retrieve incoming iTIP Message . . . . . . . 29
9.3 Acting on incoming iTIP messages . . . 23
7.2 Additional Principal Properties . . . . . . . . . . 30
10. HTTP Headers for CalDAV . . . 24
7.2.1 CALDAV:calendar-URL Property . . . . . . . . . . . . . 24
8. Calendaring Reports . . 31
10.1 Originator Header . . . . . . . . . . . . . . . . . . . 25
8.1 REPORT Method . 31
10.2 Recipient Header . . . . . . . . . . . . . . . . . . . . . 31
11. Properties from iCalendar 25
8.2 Reports on collections containing calendars . . . . . . . 25
8.3 CALDAV:calendar-query Report . . . . . . . . . . 32
11.1 has-recurrence Property . . . . . 25
8.3.1 Example: Partial retrieval of events by time range . . 26

Daboo, et al. Expires August 14, 2005 [Page 2]

Internet-Draft CalDAV February 2005

8.3.2 Example: Retrieval of todos by alarm time range . . . 29
8.3.3 Example: Retrieval of event by UID . . . . . . . 34
11.2 has-alarm Property . . . 29
8.3.4 Example: Retrieval of events by participation
status . . . . . . . . . . . . . . . . . 34

Daboo, et al. Expires June 13, 2005 [Page 2]

Internet-Draft CalDAV December 2004

11.3 has-attachment Property . . . . . . . 30
8.3.5 Example: Retrieval of events only . . . . . . . . . . 34
12. CalDAV Resource Properties 31
8.3.6 Timezone Examples . . . . . . . . . . . . . . . . . 35
12.1 Calendar-owner Property . 32
8.3.6.1 Example: List all available timezones on the
server . . . . . . . . . . . . . . . . 35
12.2 Cal-scale Property . . . . . . 32
8.4 CALDAV:calendar-multiget Report . . . . . . . . . . . . . 34
8.4.1 Example: CALDAV:calendar-multiget Report . 35
13. CalDAV Principal Properties . . . . . . 35
8.5 CALDAV:free-busy-query Report . . . . . . . . . . 37
13.1 alternate-calendar-URI Property . . . . 37
8.5.1 Example: CALDAV:free-busy-query Report . . . . . . . . 38
9. Synchronization Operations . 37
13.2 calendar-URL Property . . . . . . . . . . . . . . . . . 40
9.1 Use of Reports . 37
13.3 itip-inbox-URL Property . . . . . . . . . . . . . . . . . 37
13.4 itip-outbox-URL Property . . . . 40
9.1.1 Restrict the Time Range . . . . . . . . . . . . . 38
13.5 primary-itip-inbox-URL Property . . 40
9.1.2 Synchronize by Time Range . . . . . . . . . . . 38
13.6 primary-itip-outbox-URL Property . . . 40
9.1.3 Synchronization Process . . . . . . . . . . 38
14. Calendaring Privileges . . . . . 40
9.2 Restrict the Properties Returned . . . . . . . . . . . . . 42
9.3 Use the Server Timezone Collection . 39
14.1 view-free-busy Privilege . . . . . . . . . . . 43
10. XML Element Definitions . . . . . . 39
14.2 schedule Privilege . . . . . . . . . . . . 44
10.1 CALDAV:calendar-query XML Element . . . . . . . . 39
14.3 calendar-bind Privilege . . . . 44
10.2 CALDAV:calendar-data XML Element . . . . . . . . . . . . . 40
14.4 Privilege aggregation and the
'supported-privilege-set' property . . . . . . . . . . . . 41
14.4.1 Partial example of 'supported-privilege-set'
property . . . . . . . 44
10.2.1 CALDAV:comp XML Element . . . . . . . . . . . . . . . 44
10.2.2 CALDAV:allcomp XML Element . 41
15. Calendaring Reports . . . . . . . . . . . . . 45
10.2.3 CALDAV:allprop XML Element . . . . . . . 44
15.1 Reports on collections containing Calendars . . . . . . . 45
15.2 calendar-query Report . . .
10.2.4 CALDAV:prop XML Element . . . . . . . . . . . . . . . 45
15.2.1 calendar-query
10.2.5 CALDAV:expand-recurrence-set XML Element . . . . . . . 46
10.3 CALDAV:filter XML Element . . . . . . . . . 45
15.2.2 icalcomp Element . . . . . . . 46
10.3.1 CALDAV:comp-filter XML Element . . . . . . . . . . . . 45
15.2.3 allicalcomp 46
10.3.2 CALDAV:prop-filter XML Element . . . . . . . . . . . . . . . . . 46
15.2.4 allicalprop 47
10.3.3 CALDAV:param-filter XML Element . . . . . . . . . . . 47
10.3.4 CALDAV:is-defined XML Element . . . . . . 46
15.2.5 icalprop Element . . . . . . . 48
10.3.5 CALDAV:text-match XML Element . . . . . . . . . . . . 46
15.2.6 expand-recurrence-set 48
10.4 CALDAV:time-range XML Element . . . . . . . . . . . . 46
15.2.7 filter Element . . . 49
10.5 DAV:response XML Element . . . . . . . . . . . . . . . . . 47
15.2.8 icalcomp-filter 49
10.6 CALDAV:calendar-multiget XML Element . . . . . . . . . . . . . . . 47
15.2.9 icalprop-filter 50
10.7 CALDAV:free-busy-query XML Element . . . . . . . . . . . . 50
11. Internationalization Considerations . . . 47
15.2.10 icalparam-filter Element . . . . . . . . . 51
12. Security Considerations . . . . . 48
15.2.11 is-defined Element . . . . . . . . . . . . . 52
12.1 Authentication of Clients . . . . 48
15.2.12 text-match Element . . . . . . . . . . . . 52
12.2 Denial of Service . . . . . 48
15.2.13 time-range Element . . . . . . . . . . . . . . . 52
13. IANA Consideration . . 49
15.2.14 Example: Partial retrieval of events by time
range . . . . . . . . . . . . . . . . . . . 53
13.1 Namespace Registration . . . . 49
15.2.15 Example: Retrieval of todos by alarm time range . . 52
15.2.16 Example: Retrieval of event by UID . . . . . . . . . 52
15.2.17 Example: Retrieval of events by participation
status . . . 53
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 53
15.2.18 Example: Retrieval of events only . . 54
15. Normative References . . . . . . . 54
16. Disconnected Operations . . . . . . . . . . . . . 54
Authors' Addresses . . . . . 56
17. Security Considerations . . . . . . . . . . . . . . . . . 55
A. CalDAV Method Privilege Table (Normative) . 57
18. IANA Consideration . . . . . . . . . 56
B. Changes . . . . . . . . . . . . 58
18.1 Namespace Registration . . . . . . . . . . . . . . . 57

Daboo, et al. Expires August 14, 2005 [Page 3]

Internet-Draft CalDAV February 2005

B.1 Changes in -05 . . . 58
19. References . . . . . . . . . . . . . . . . . . . 57
B.2 Changes in -04 . . . . . . 59
19.1 Normative References . . . . . . . . . . . . . . . . 57
B.3 Changes in -03 . . . . 59

Daboo, et al. Expires June 13, 2005 [Page 3]

Internet-Draft CalDAV December 2004

19.2 Informative References . . . . . . . . . . . . . . . . . . 57
B.4 Changes in -02 . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57
B.5 Changes in -01 . 60
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . 61
B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.1 Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 62
B.2 Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 62
B.3 Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 62
B.4 Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . 63 59

Daboo, et al. Expires June 13, August 14, 2005 [Page 4]

Internet-Draft CalDAV December 2004 February 2005

1. Introduction

The concept of using HTTP [4] and WebDAV [3] as a basis for a
calendaring server 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 calendaring servers using HTTP PUT/GET to
upload and download iCalendar [2] events, objects, and using WebDAV PROPFIND
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 and
properties, resources, as well as
how to implement required features that aren't already part of
WebDAV. This draft document is therefore intended to propose a standard
way of modeling calendar data in WebDAV, plus some additional
features to make calendaring calendar access work well.

WebDAV properties and other XML element names defined in

Discussion of this
specification all use Internet-Draft is being done on the "urn:ietf:params:xml:ns:caldav" namespace.
Implementors may find occasion to define new WebDAV properties and
other mailing list
<http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

1.1 XML Namespaces

Definitions of XML elements in implementing this specification, but this
namespace is not intended for document use XML element type
declarations (as found in custom extensions.

1.1 Advantages of WebDAV for Calendar Access

WebDAV offers a number XML Document Type Declarations), described
in Section 3.2 of advantages as a framework or basis [8].

The namespace "urn:ietf:params:xml:ns:caldav" is reserved for
calendar access. Most of these advantages boil down to a significant
reduction in design costs, implementation costs, interoperability
test costs, deployment costs, and the cost of mistakes. Every new
standard author XML
elements defined in this specification, or implementor finds certain small errors and the in other Standards Track
IETF spends considerable time and effort remediating these. Some of RFCs written to extend CalDAV. It MUST NOT be used for
proprietary extensions.

Note that the advantages XML declarations used in this document are contingent upon incomplete,
in that they do not include namespace information. Thus, the way WebDAV is used, which is
why this section exploring advantages is inseparable from reader
MUST NOT use these declarations as the rest only way to create valid
CalDAV properties or to validate CalDAV XML element type. Some of
this document for
the moment.

1.1.1 HTTP URLs for Calendar Objects

WebDAV is an extension declarations refer to XML elements defined by WebDAV which use
the HTTP/1.1 [4] protocol, therefore its
URLs "DAV:" namespace. Wherever such elements appear, they are HTTP URLs. If calendar access were an extension of WebDAV
then it could also share HTTP URLs. This can make a lot of sense
because it allows very simple calendar browsing clients
explicitly given the "DAV:" prefix to be written
for devices help avoid confusion.

Also note that already have a HTTP stack: the client merely needs some CalDAV XML element names are identiqual to download those calendar objects and WebDAV
XML element names, though their namespace differs. Care MUST be able
taken not to parse their
formats. Since confuse the iCalendar [2] formats are well-defined and
well-supported, there's a natural choice for what resource to
download for a granular calendar object. If HTTP GET can be two sets of names.

1.2 Notational Conventions

The augmented BNF used by this document to
represent a calendar object, then appointment references can be
easily downloaded, synchronized and shared.

Specifying new URL formats creates additional work for implementors describe protocol elements
is described in Section 2.1 of [4]. Because this augmented BNF uses
the basic production rules provided in Section 2.2 of [4], those
rules apply to this document as well.

Daboo, et al. Expires June 13, August 14, 2005 [Page 5]

Internet-Draft CalDAV December 2004

of clients, servers February 2005

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and related applications that might see those
URLs. Although new URL formats are appropriate "OPTIONAL" in many cases,
sometimes HTTP URLs may be appropriate -- particularly for an
application which extends HTTP and allows all the standard HTTP
methods to work correctly. Not only this
document are HTTP URLs appropriate for
Calendar objects, but they also eliminate the need to specify a new
URL schema and format and implement it.

1.1.2 Web Services and Web Interfaces

Calendar functionality is found extremely frequently on the Web.
Even calendaring systems designed primarily for access by smart
clients (smart clients are those which have application logic, be interpreted as
opposed to thin clients or Web browsers) typically also have a Web
interface accessible by thin clients. Some calendaring applications described in [1].

When XML element types in the namespaces "DAV:" and
"urn:ietf:params:xml:ns:caldav" are available only via Web interfaces, for example those found on
systems such as Yahoo! Groups.

Because referenced in this document
outside of the frequent use context of Web interfaces, an XML fragment, the string "DAV:" and
"CALDAV:" will be prefixed to the possibility element types respectively.

1.3 Method Preconditions and Postconditions

A "precondition" of
supporting Web services, WebDAV is a particularly suitable framework method describes the state of the server that
must be true for calendar data. HTTP URLs that method to calendar objects can be used
natively in these systems. WebDAV provides property information in
an XML format, easily consumed by Web services which usually import
XML data anyway. Web interfaces can use stylesheets to transform XML
data into HTML presentation. This approach is described in
<http://www.microsoft.com/technet/prodtechnol/exchange/exchange2000/d
eploy/confeat/e2kowa.asp>.

1.1.3 Client Implementations from Simple to Rich

The HTTP/WebDAV feature model encourages a wide range performed. A "postcondition" of clients,
from extremely simple to very rich. This is because servers must
support a wide range
method describes the state of features, but clients can pick and choose
which features to support. For example, even though a WebDAV the server that must support the 'lockdiscovery' property, there's no requirement be true after that
method has been completed. If a method precondition or postcondition
for a client to 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 parse this property value 409 (Conflict) if it has no need
to. Generally speaking, clients may pick and choose which methods
and properties to support, as long as the client has a reasonable
response to is expected that
the error conditions which user might be returned. A simple
client can merely download able to resolve the conflict and upload iCalendar objects resubmit the
request.

In order to allow better client handling of 403 and use very
little 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 advanced WebDAV functionality.

At a particular postcondition cannot be achieved, the other end of
appropriate XML element MUST be returned as the scale, child of a rich calendaring client using
WebDAV-based calendaring could choose to implement offline
functionality, free-busy searches crossing multiple servers, advanced
tasks and even some workflow, top-level
DAV:error element in the response body, unless otherwise negotiated
by using more of the features and
possibly defining its own dead properties. (Note: WebDAV's 'dead'
properties are those which request. In a 207 Multi-Status response, the server allows clients to set but DAV:error
element would appear in the appropriate DAV:responsedescription
element.

Daboo, et al. Expires June 13, August 14, 2005 [Page 6]

Internet-Draft CalDAV December 2004

server has no special behavior regarding those properties. Other
clients may query and use these dead properties.)

1.1.4 Support February 2005

2. Required CalDAV features

This section lists what functionality is required of a CalDAV server.
To advertise support for lock feature CalDAV, a server:
o MUST support WebDAV includes locking support. Locks are indispensable when
multiple authors may modify or create Class 1.
o MUST support WebDAV ACL [7] with the same resources. Locks not
only prevent authors from accidentally overwriting each others work
(as privilege defined in
Section 7.1 of this document.
o MUST support SSL.
o MUST support strong ETags do), they also help authors coordinate that work by seeing
when to wait for another author to finish. Calendar users benefit
slightly from support disconnected operations.
o MUST support all required calendaring REPORTs defined in this functionality, more so when group calendars or
shared calendars allow booking of large groups of people or
broadly-used resources such
document.
o MUST advertise calendaring REPORTs via the
DAV:supported-report-set property as conference rooms or equipment.

1.1.5 Support for access control

The WebDAV ACL specification [8] is now a standard, and several
implementations have already demonstrated interoperability. Any
shared or group calendar application benefits from interoperable
access control. Access control can help define who can schedule defined in DeltaV [5].

In addition, a
user for new appointments without having server:
o SHOULD support MKCALENDAR.
o MAY support WebDAV Class 2 (i.e., locking).
o [[Comment.1: CalDAV should provide some guidelines to make email requests, who
can view free/busy time, and who can see use locking
in the details context of certain
appointments. calendaring applications. --desruisseaux]]
o MAY support WebDAV ACLs provide a flexible and extensible list DeltaV [5] or some of its components.

Daboo, et al. Expires August 14, 2005 [Page 7]

Internet-Draft CalDAV February 2005

3. Calendaring Data Model

One of privileges, the features which is both good and bad for calendaring. It's good because it
allows a calendaring-over-WebDAV standard to define additional
privileges that may not be used in normal has made WebDAV use cases (for
example, the privilege to view a calendar's free-busy information).
However the bad part successful protocol is that
its firm data model. This makes it a flexible and extensible list of
privileges is hard useful framework for clients to display and explain to users. other
applications such as calendaring. This
draft specification attempts to minimize
follow the difficulty same pattern by more closely defining
the list of privileges that developing all new features based on a
well-described data model.

In the CalDAV server must support, including
calendaring-specific privileges.

Implementors should note that data model, every iCalendar VEVENT, VJOURNAL, VTODO and
VFREEBUSY component is stored as an individual HTTP/WebDAV resource.
That means each calendar resource may be individually locked and have
individual WebDAV ACLs are not designed to limit
access to specific properties. For example, These resources are placed into WebDAV
collections with a calendaring
application may wish to choose which mostly-fixed structure.

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 users can view WebDAV resources, within a unified URL namespace.
For example, the
start/end times of appointments, repository "http://example.org/webdav/" may contain
WebDAV collections and separately choose which users
can also see the location resources, all of appointments. However, as a standard
and framework, WebDAV ACL provides a valuable base from which to
work. Furthermore, this proposal recommends that advanced access
control work for calendaring be relegated to another document, so have URLs beginning
with "http://example.org/webdav/". Note that standard calendaring systems can the root URL
"http://example.org/" may not itself be built using existing WebDAV
ACL support.

Daboo, et al. Expires June 13, 2005 [Page 7]

Internet-Draft CalDAV December 2004

1.1.6 Security, Implementations and Deployed Base

Many WebDAV client applications, servers and APIs already exist. a WebDAV clients exist for modern Microsoft, Unix and Apple platforms.
Open source solutions are common and powerful. This can
significantly improve early interoperability and reduce development
and test time.

Much security integration work has already been done for WebDAV.
Today's Web and repository (for
example, if the WebDAV servers all support TLS, providing at is implemented through a
minimum single-hop privacy and servlet or
other Web server authentication. HTTP Digest extension).

A WebDAV repository may include calendar data in some areas, and Basic authentication
non-calendaring data in other areas.

A WebDAV repository may provide adequate client authentication
(Basic essentially uses advertise itself as a clear-text password but this may be
appropriate CalDAV server if it
supports the connection functionality defined in this specification at any point
within the root of the repository. That might mean that calendaring
data is secured spread throughout the repository and mixed with TLS). If not, work is
under way to support SASL with HTTP. As that work nears completion,
HTTP/WebDAV implementations will add SASL support so that work will non-calendar
data in nearby collections (e.g., calendar data may be done already for a calendaring system. It seems the HTTP/SASL
work is nearing last call (currently draft-nystrom-http-sasl-09.txt).

1.1.7 Migration, Synchronization and Offline Functionality

Synchronization and offline functionality are useful features found in
Calendaring systems. Luckily, these are already
/lisa/calendar/ as well understood for
HTTP/WebDAV technology. HTTP ETags provide a reliable way to
determine whether a document as in an offline cache needs to be
synchronized. At least two WebDAV clients supporting synchronization
have already been created: sitecopy (http://www.lyra.org/sitecopy/)
and Xythos WebFile Client
(http://www.xythos.com/home/xythos/wfc_features.html).

Many WebDAV working group members are discussing more work to improve
the performance of synchronization between WebDAV clients /bernard/calendar/, and WebDAV
repositories. This ongoing work can benefit the calendaring
community at the same time, provided that the calendaring non-calendar
data model
fits easily in the WebDAV /lisa/contacts/). Or, it might mean that calendar data model. The model proposed can
be found only in this
document is one with which new WebDAV synchronization certain sections of the repository (e.g.,
/calendars/user/). Calendaring features are
likely to be equally applicable to calendaring data.

Data migration is almost only required in the same problem as synchronization. One
use of
repository sections that are or contain calendaring objects. So a WebDAV tool like sitecopy is to move
repository confining calendar data to a new server. the /caldav/ collection would
only need to support the CalDAV required features within that
collection.

The move CalDAV server or repository is performed by doing a new synchronization. Once the
initial synchronization is complete canonical location for
calendar data and state information. Both CalDAV servers and verified, clients
MUST ensure that the data on the old
system can be removed or archived. Data portability is a convenient
feature consistent and compliant. Clients may
submit requests to administrators, particularly when deploying a new system.

1.1.8 Clear extensibility model

WebDAV has a clear change data or download data. Clients may store
calendar objects offline and proven extensibility model. The major way

Daboo, et al. Expires June 13, attempt to synchronize at a later time.

Daboo, et al. Expires August 14, 2005 [Page 8]

Internet-Draft CalDAV December 2004

functionality is extended is by defining new properties. Servers can
extend functionality by creating new live properties in custom
namespaces.

Clients can also extend functionality by creating new dead properties
in custom namespaces. For example, a client might wish to add a
"source-device" property in a custom namespace to record which device
created the calendar item. Dead properties are client-controlled
properties, where the namespace, name and value are entirely
controlled by the client. February 2005

However, clients MUST be prepared for calendar data on the server is required to store
these properties and return them, if requested, in PROPFIND queries
for individual resources or in listings of collection contents. Some
servers support text searching on all dead properties through
change between the
DASL extensions (a work in progress) [TODO: REF]. Dead properties
can also time of last synchronization and when attempting
an update, as calendars may be used in reports.

Other proven HTTP/WebDAV extensibility mechanisms include the ability
to define shared and advertise special WebDAV reports, new accessible via multiple
clients. HTTP headers, ETags and
for ultimate flexibility, new HTTP methods.

Daboo, et al. Expires June 13, 2005 [Page 9]

Internet-Draft CalDAV December 2004

2. Required CalDAV features

This section lists what functionality other tools help this work.

3.2 Recurrence and the Data Model

Recurrence is required an important part of a CalDAV server.
To advertise support for the 'calendar-access' features data model because it governs
how many resources are expected to exist.

Consider the outcome if recurrence were handled through the creation
of CalDAV, a
server:
o MUST support many nearly-identical WebDAV Class 1 and 2 (all resources. With this model, it
becomes hard to keep synchronized data consistent. Even worse, some
features like LOCK become difficult -- it's hard to lock the right
set of RFC2518 [5] including
locking).
o MUST support WebDAV ACLs [8] with resources so that the privilege set defined in
Section 14.
o MUST support SSL.
o MUST support strong ETags user can change the title of all
recurrences of an appointment. Due to support disconnected operations.
o MUST support property promotion as described in these considerations, this document.
o MUST support calendaring REPORTs
proposal does not model recurrences as described in separate resources.

Instead, this document.
o MUST support MKCALENDAR.

To advertise support for the 'calendar-schedule' features proposal models recurrence patterns as properties of CalDAV,
a server:
o MUST support all the 'calendar-access' features
o MUST support the 'schedule' and 'calendar-bind' privileges.
o MUST support the 'itip-inbox' and 'itip-outbox' collections.
o MUST support the SCHEDULE method and the Recipient
calendar resources. This makes for much less data to synchronize,
and Originator
headers.

In addition, a server:
o MAY support WebDAV DeltaV [11] makes it easier to make changes to all recurrences or some to a
recurrence pattern. It makes it easier to create a recurring
component, and easier to delete all recurrences.

The drawback of its components.

Daboo, et al. Expires June 13, 2005 [Page 10]

Internet-Draft CalDAV December 2004

3. CalDAV Support Discovery

If the server supports the recurrence-is-a-property approach is that it
becomes harder to see what events occur in a given time interval.
It's a very common function for calendar access features described views to display all events
happening between midnight yesterday and midnight tonight, or all
events happening within one week. In these views, each recurrence
appears as if it were an individual appointment. The
CALDAV:calendar-query REPORT defined in this document it make these
views possible.

Because of this choice, clients 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, or privileges.

If the server supports the calendar scheduling features described in
this document it MUST include "calendar-schedule" as NOT create separate resources to
represent a field in the
DAV response header from an OPTIONS request on any resource that
supports the SCHEDULE method.

3.1 Example: Using OPTIONS for recurring event when the Discovery of Support recurrence pattern is known.
Otherwise, it makes it more difficult for CalDAV

>> Request <<

OPTIONS /lisa/calendar/outbox/ HTTP/1.1
Host: cal.example.com

>> Response <<

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, SCHEDULE
DAV: 1, 2, calendar-access, calendar-schedule
Content-Length: 0

In this example, other clients to
interoperate and modify the OPTIONS response indicates that recurring event. Most importantly,
clients MUST NOT duplicate events represented through recurrence
patterns with manually created events, which would appear as
duplicates to the server
supports both calendar access and scheduling functionality and that
/lisa/calendar/outbox/ can to other clients.

3.3 Timezones

Calendar resources in CalDAV MUST be valid iCalendar objects. As
such, an individual VTIMEZONE calendar component MUST be specified as a Request-URI to
for each unique TZID parameter value specified in an iCalendar
object. Unfortunately this mean that the
SCHEDULE method. same VTIMEZONE component
will get sent or retrieved multiple times for each iCalendar object

Daboo, et al. Expires June 13, August 14, 2005 [Page 11] 9]

Internet-Draft CalDAV December 2004

4. Calendaring Data Model

One of February 2005

that uses the features which has made WebDAV a successful protocol is
its firm data model. timezone. This makes it a useful framework for other
applications such as calendaring. In this proposal, we attempt is not efficient in terms of bandwidth
usage.

[[Comment.2: Not clear how big an issue that really is. CalDAV
already allows clients to
follow retrieve iCalendar objects without their
VTIMEZONE component with the same pattern by developing all new features based CALDAV:calendar-query REPORT. It is
still not clear whether a client could rely only on the value of the
TZID parameter, or should it always requests a
well-described data model.

In VTIMEZONE component
with at least the CalDAV data model, every iCalendar VEVENT, VJOURNAL, VTODO TZID and
VFREEBUSY is stored TZURL properties and rely on the TZURL as
a regular HTTP/WebDAV resource. That means
each calendar resource may be individually locked and unique identifier for a given time zone. CalDAV servers have individual
properties. These resources are sorted into WebDAV collections no
choice but to return complete VTIMEZONE components in iCalendar
object retrieve with
a mostly-fixed structure.

4.1 Calendar Repository or Server

A CalDav repository, or server, the GET method as their is no way to know if the
client is a calendaring-aware engine
combined with CalDAV client or a WebDAV repository. A WebDAV repository is simple HTTP client. On a set of
WebDAV collections, containing other WebDAV resources, within PUT request
perhaps a
unified URL namespace. For example, the repository
"http://example.org/webdav/" may contain WebDAV collections and
resources, all of which have URLs beginning CalDAV server could accept an iCalendar object with
"http://example.org/webdav/". Note a
VTIMEZONE object that the root URL
"http://example.org/" may not itself be has at least TZURL that points to a WebDAV repository (for
example, if calendar
resource that defines a time zone on the WebDAV support server. --desruisseaux]]

The timezone collection is implemented through a servlet or
other Web server extension).

A WebDAV repository may include calendar data in some areas, and
non-calendaring data in other areas. Calendar data will be indicated
through specific container relationships and resource types discussed
in the next sections.

A WebDAV repository may 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 collection 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
/lisa/calendar/ as well contains only
VTIMEZONE components as in /nborenstein/calendar/, and
non-calendar data in /lisa/contacts/). Or, it might mean separate resources within that
calendar data can collection.
There MUST be found only one VTIMEZONE component per calendar resource in certain sections of
the repository
(e.g. /caldav/usercals/*). Calendaring features are only required
in timezone collection. Clients can discover the repository sections that are or contain calendaring objects.
So a repository confining calendar data to location of the /caldav/
timezone collection
would only need to support with the CalDAV required features within that
collection.

The CalDAV server or repository is CALDAV:timezone-collection-set OPTIONS
request (see Section 5.2.4) and can list the canonical location for
calendar data, state information supported timezones and semantics. The CalDAV server
retrieve specific timezone component data by using the
CALDAV:calendar-query REPORT defined in Section 8.3.

Daboo, et al. Expires June 13, August 14, 2005 [Page 12] 10]

Internet-Draft CalDAV December 2004

has significant responsibility to ensure that the data is consistent
and compliant. Clients may submit requests to change data or
download data. Clients may store the calendar offline and attempt to
synchronize when reconnected, but changes to February 2005

4. New Resource Types

CalDAV defines the repository occurring following new resource types for use in between WebDAV
repositories holding calendar data.

4.1 Calendar Collection

Calendar collections are not considered manifested to be automatically disposable and clients should consider the repository to be the first authority on
state. HTTP Etags and other tools help this work.

4.2 Recurrence as a WebDAV resource
collection, identified by a URL. A calendar collection MUST have a
non-empty DAV:displayname property (defined in Section 13.2 of
RFC2518 [3]), and the Data Model

Recurrence is an important part a DAV:resourcetype property (defined in Section
13.9 of RFC2518 [3]). Additionally, a calendar collection MUST
report the data model because it governs
how many resources are expected to exist.

Consider the outcome if recurrence were handled through DAV:collection and CALDAV:calendar XML elements in the creation
value of many nearly-identical WebDAV resources. With this model, it
becomes hard to keep synchronized data consistent. Even worse, some
features like LOCK become difficult -- it's hard to lock the right
set of DAV:resourcetype property. The element type declaration
for CALDAV:calendar is:

<!ELEMENT calendar EMPTY>

A calendar collection contains resources so that represent the user can change the title of all
recurrences of an appointment. Due to these considerations, this
proposal does not model recurrences as separate resources.

Instead, this proposal models recurrence patterns as properties of
event resources. iCalendar
objects within a calendar. A calendar collection may be created
through provisioning (e.g., automatically created when a user's
account is created), or it may be created through MKCALENDAR. This makes
can be useful for much less data to synchronize, and
makes it easier to make changes to all recurrences or to a recurrence
pattern. It makes it easier user to create a recurring event, and easier
to delete all recurrences.

The drawback of the recurrence-is-a-property approach is that it
becomes harder second calendar (e.g., soccer
schedule) or for users to see what events occur in a given time period. It's share a very common function for calendar views to display all (e.g., team events
happening between midnight yesterday and midnight tonight, or all
events happening within one week. In these views, each recurrence
appears as if it were an individual appointment. To make these views
possible,
conference room). Note however that this proposal defines a REPORT specifically document doesn't define
what extra calendars are for, users must rely on non-standard cues to view events
find out what a calendar is for, or use the
CALDAV:calendar-description property defined in Section 6.1 to
provide such a time period [TODO - ref section].

Because of this choice, clients cue.

Calendar collections MUST NOT create separate resources to
represent a recurring event when the recurrence pattern is known.
Otherwise, it makes it more difficult for contain other clients to
interoperate and modify calendar collections.
Multiple calendars MAY be children of the recurring event. Most importantly,
clients same WebDAV collection.

A calendar collection MAY contain additional collections and
non-collection resources of types not defined here. How such items
are used is not defined by this specification. However, additional
collections contained in a calendar collection MUST NOT duplicate events contain
calendar collections.

4.2 iCalendar Components within the Calendar Collection

Each top-level iCalendar component within the VCALENDAR component is
represented through recurrence
patterns with manually created events, which would appear as
duplicates to the server and to other clients.

4.3 Scheduling, Fanout and a separate WebDAV resource, with the Data model

One following
exceptions
o sets of recurring items (i.e., components with the key workflows same UID
iCalendar property value, but differing RECURRENCE-ID values) are
all stored in calendaring and scheduling is when a
meeting organizer creates an invitation and sends it to a number of the same resource. That is, each WebDAV resource
MUST only contain iCalendar components with the same iCalendar UID

Daboo, et al. Expires June 13, August 14, 2005 [Page 13] 11]

Internet-Draft CalDAV December 2004

attendees. Each of those attendees wants the event to appear on
their own calendar (if they accept it) February 2005

property value, and have their status
reflected back to all iCalendar components with the organizer. This section is same
iCalendar UID property value MUST be stored in the same WebDAV
resource.
o any top-level component that references a brief overview of
how this workflow relates timezone via a "TZID"
property MUST include the VTIMEZONE component corresponding to
that timezone id, as required by iCalendar, unless the data model of CalDAV, which only
applies if timezone is
one included in the server supports server's timezone collection, as described in
Section 3.3.

For example, given the 'calendar-schedule' following iCalendar object:

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Example, Inc.\, Inc.//Example App//EN
VERSION:2.0
BEGIN:VEVENT
UID:1@example.com
SUMMARY:One-off Meeting
DTSTAMP:20041210T183904Z
DTSTART:20041207T120000Z
DTEND:20041207T130000Z
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
SUMMARY:Weekly Meeting
DTSTAMP:20041210T183838Z
DTSTART:20041206T120000Z
DTEND:20041206T130000Z
RRULE:FREQ=WEEKLY
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
RECURRENCE-ID:20041213T120000Z
DTSTAMP:20041210T183838Z
DTSTART:20041213T130000Z
END:VEVENT
END:VCALENDAR

The VEVENT with UID value "1@example.com", would be stored in its own
unique WebDAV resource. The two VEVENTs with UID value
"2@example.com", which represent a set of
features.

An invitation is not yet an accepted event. Thus, invitations should
appear outside the main part recurring events where one
instance has been overridden, would be stored in a single unique
WebDAV resource.

Daboo, et al. Expires August 14, 2005 [Page 12]

Internet-Draft CalDAV February 2005

5. Creating Resources

The creation of the calendar, calendar collections and not calendar resources may be included in
free-busy rollup
initiated by either a CalDAV client or by the CalDAV server. For
example, a server might come preconfigured with a user's calendar REPORT requests. To handle this in
collection, or the
data model, CalDAV defines an iTIP Inbox collection to contain
incoming invitations. Similarly, client might request the Inbox folder can handle
incoming replies and other iTIP methods. The Inbox contains inbound
iTIP messages long after they are handled/seen by the user, because
this serves server to create a
new calendar collection for a given user. Servers might populate
events as calendar objects inside a track record and to help synchronize between
multiple clients.

Outbound iTIP messages are very similar, and need to be tracked both
to help synchronize between multiple calendar collection, or clients and to support
delegation use cases. CalDAV defines an iTIP Outbox collection
might request the server to
contain outbound invitations create events. Either way, both client
and other iTIP methods. A single user server MUST comply with multiple clients can use the requirements in this collection document, and
MUST understand objects appearing in calendars or according to synchronize the
outbound
data model defined here.

5.1 MKCALENDAR Method

A MKCALENDAR request history. Two users coordinating scheduling with one
calendar (e.g. creates a new calendar user and her assistant) can see what
scheduling messages the other user has sent. (The collection resource. A
server MAY restrict calendar owner
would then typically have permission collection creation to DELETE the scheduling
messages particular
collections, but a client can determine the assistant need not.)

Thus, location of these
collections from a CALDAV:calendar-collection-set OPTIONS request
(see Section 5.2.2).

Support for every scheduling request, we would like to see one copy in MKCALENDAR on the organizer's iTIP Outbox, as well as server is OPTIONAL because some
calendar stores only support one copy in calendar per user (or principal) and
those are typically pre-created for each attendee's
iTIP Inbox. Rather than require that many PUT requests, CalDAV
defines the SCHEDULE method account. However, servers
and clients are strongly encouraged to request that support MKCALENDAR whenever
possible to allow users to create multiple calendars to better help
organize their data.

Clients SHOULD use the server place DAV:displayname property for a copy human-readable
name of an iTIP message in the calendar. This requires the clients to issue a given iTIP Outbox, and do its best PROPPATCH
request to fan out change the iTIP message DAV:displayname property to the recipients' iTIP Inboxes.

The server may support fanout to other domains, and appropriate
value immediately after issuing the client may
attempt MKCALENDAR request. When
displaying calendars to get users, clients SHOULD check the server to do this by specifying remote addresses
for
DAV:displayname property and use that value as the fanout recipients, but name of the server is not bound to support or
complete remote fanout operations even if it advertises support for
'calendar-schedule' features. Note
calendar. In the event that fanout mechanisms are not
defined in CalDAV -- there is no server-to-server or server-to-client
protocol defined for delivering an iTIP message. Implementations may
do this in a proprietary way, with iMIP, or with iTIP bindings as yet
unspecified.

After the fanout DAV:displayname property is completed, CalDAV clients will see empty,
the iTIP
messages client MAY use the next time they synchronize or query last part of the iTIP Inbox
collection. To reply to an iTIP invitation, calendar-collection URI as
the client uses name.

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.

<!ELEMENT mkcalendar ANY>

Daboo, et al. Expires June 13, August 14, 2005 [Page 14] 13]

Internet-Draft CalDAV December 2004

SCHEDULE method to send another iTIP message (this time, a reply). February 2005

If the user has decided to accept the invitation, the client also
uses PUT (or some other method) to create a VEVENT 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
(text/calendar) in MUST NOT exist at the appropriate calendar, and with
Request-URI.
(CALDAV:calendar-collection-location-ok): The Request-URI MUST
identify a location where a calendar collection can be created.
(CALDAV:insufficient-privilege): The DAV:bind privilege MUST be
granted to the appropriate
details. Typically, current authenticated user.

Postconditions:
(CALDAV:initialize-calendar-collection): A new calendar collection
exists at the step Request-URI. The DAV:resourcetype of putting the event in the calendar is
left up to
collection MUST be DAV:collection. Additionally, a calendar
collection MUST report the client, so that CALDAV:calendar XML element in the client can make appropriate
choices about where to put
value of the event, and with what alarms, etc.
However, DAV:resourcetype property.

5.1.1 Status Codes

201 (Created) - The calendar collection resource was created in its
entirety.

403 (Forbidden) - This indicates at least one of two conditions: 1)
the server MAY be configured (how is does not defined here) to
auto-accept allow the creation of calendar collections at the
given location in its namespace, or auto-reject invitations, and if 2) the server
auto-accepts invitations then parent collection of the
Request-URI exists but cannot accept members.

405 (Method Not Allowed) - MKCALENDAR can only be executed on a null
resource.

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 is responsible for creating
iCalendar components in does not support the user's calendar. request
type of the body.

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

Daboo, et al. Expires June 13, August 14, 2005 [Page 15] 14]

Internet-Draft CalDAV December February 2005

5.1.2 Example - MKCALENDAR

>> Request <<

MKCALENDAR /calendars/user/lisa/ HTTP/1.1
Host: cal.example.com
Content-Length: 0

>> Response <<

HTTP/1.1 201 Created
Date: Fri, 22 Oct 2004

5. New Resource Types

CalDAV defines the following 12:17:08 GMT
Content-Length: 0
Cache-Control: no-cache

In this example, a new resource types for use in calendar
repositories.

5.1 Calendar Collection

A WebDAV collection which corresponds to a single calendar or
VCALENDAR is created at
http://cal.example.com/calendars/user/lisa/

5.2 Additional OPTIONS Semantics

5.2.1 Capability Discovery

If the server supports the calendar-access feature, it MUST include
"calendar-access" as a Calendar. It has a new field in the DAV response header from an
OPTIONS request on any resource type:

The calendar collection contains resources that represent supports any calendar
properties, reports, or methods. A value of "calendar-access" in the
iCalendar objects within
DAV header MUST indicate that the calendar. It also has certain
properties which are required to be present on calendars (see XML
section). A Calendar server supports all MUST level
requirements and REQUIRED features specified in this document.

5.2.1.1 Example: Using OPTIONS for the Discovery of Support for CalDAV

>> Request <<

OPTIONS /calendars/users/ HTTP/1.1
Host: cal.example.com

>> Response <<

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT
Allow: MKCALENDAR, ACL
DAV: 1, 2, access-control, calendar-access
Content-Length: 0

In this example, the OPTIONS response indicates that the server
supports CalDAV in this namespace, therefore the '/calendars/users/'
collection may be created through provisioning
(e.g. automatically created when used as a user's account is created), or it
may be created through MKCALENDAR. This can be useful parent for a user to
create a second calendar (e.g. soccer schedule) or collections as the

Daboo, et al. Expires August 14, 2005 [Page 15]

Internet-Draft CalDAV February 2005

MKCALENDAR method is available, and as a possible target for users REPORT
requests for calendaring reports.

5.2.2 CALDAV:calendar-collection-set OPTIONS request

A CALDAV:calendar-collection-set element MAY be included in the
request body to
share a calendar (e.g. team events or conference room). Note
however identify collections that this proposal doesn't define what extra calendars are
for, users must rely on non-standard cues to find out what a may contain calendar
collection resources.

Additional Marshalling:
If an XML request body is for.

Calendars included, it MUST NOT contain other calendars. Multiple calendars MAY be children of the same WebDAV collection. a DAV:options XML
element.

<!ELEMENT options ANY>
ANY value: A Calendar collection MAY contain additional collections and
non-collection resources sequence of types not defined here. How such items
are used elements with at most one
calendar-collection-set element.

If an XML response body for a successful request is not defined by this specification.

5.1.1 iCalendar Components within the Calendar Collection

Each top-level iCalendar component within the VCALENDAR component is
represented as included, it
MUST be a seperate WebDAV resource, with the exception that
sets DAV:options-response XML element.

<!ELEMENT options-response ANY>
ANY value: A sequence of recurring items (i.e. components elements with the same UID iCalendar
property value, but differing RECURRENCE-ID values) are all stored at most one
calendar-collection-set element.

<!ELEMENT calendar-collection-set (href*)>

If CALDAV:calendar-collection-set is included in the same resource. i.e. each WebDAV resource request body,
the response body for a successful request MUST only contain
iCalendar components with a
CALDAV:calendar-collection-set element identifying collections
that may contain calendar collections. An identified collection
MAY be the same iCalendar UID property value, and root collection of a tree of collections, all iCalendar components with of which
may contain calendar collections. Since different servers can
control different parts of the URL namespace, different resources
on the same iCalendar UID property value
MUST host MAY have different CALDAV:calendar-collection-set
values. The identified collections MAY be stored in located on different
hosts from the same WebDAV resource.

For example, given

5.2.3 CALDAV:current-user-calendar-collection-set OPTIONS request

A CALDAV:current-user-calendar-collection-set element MAY be included
in the following iCalendar object: request body to identify the calendar collections owned by the
current authenticated user.

Additional Marshalling:
If an XML request body is included, it MUST be a DAV:options XML
element.

<!ELEMENT options ANY>

Daboo, et al. Expires June 13, August 14, 2005 [Page 16]

Internet-Draft CalDAV December 2004

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Example, Inc.\, Inc.//Example App//EN
VERSION:2.0
BEGIN:VEVENT
UID:1@example.com
SUMMARY:One-off Meeting
DTSTAMP:20041210T183904Z
DTSTART:20041207T120000Z
DTEND:20041207T130000Z
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
SUMMARY:Weekly Meeting
DTSTAMP:20041210T183838Z
DTSTART:20041206T120000Z
DTEND:20041206T130000Z
RRULE:FREQ=WEEKLY
END:VEVENT
BEGIN:VEVENT
UID:2@example.com
RECURRENCE-ID:20041213T120000Z
SUMMARY:Weekly Meeting
DTSTAMP:20041210T183838Z
DTSTART:20041213T130000Z
RRULE:FREQ=WEEKLY
END:VEVENT
END:VCALENDAR

The VEVENT February 2005

ANY value: A sequence of elements with UID value "1@example.com", would at most one
current-user-calendar-collection-set element.

If an XML response body for a successful request is included, it
MUST be stored in its own
unique WebDAV resource. The two VEVENTs with UID value
"2@example.com", which represent a set DAV:options-response XML element.

<!ELEMENT options-response ANY>
ANY value: A sequence of recurring events where elements with at most one
instance has been overridden, would be stored
current-user-calendar-collection-set element.

<!ELEMENT current-user-calendar-collection-set (href*)>

If CALDAV:current-user-calendar-collection-set is included in the
request body, the response body for a single unique
WebDAV resource.

5.2 iTIP Inbox Collection

On a server supporting 'calendar-schedule' features, every Calendar successful request MUST have an associated iTIP Inbox collection to
contain incoming
iTIP messages. The iTIP Inbox a CALDAV:current-user-calendar-collection-set element
identifying calendar collections owned by the current
authenticated user.

[[Comment.3: We should probably put a note that one needs to be
authenticated before issuing this OPTIONS request. Obviously.
--desruisseaux]]

5.2.4 CALDAV:timezone-collection-set OPTIONS request

A CALDAV:timezone-collection-set element MAY be inside included in the
request body to identify the calendar or
elsewhere on collections that contains the
set of calendar resources that defines the timezone supported by the server, possibly even on another
server.

Every non-collection resource

Additional Marshalling:
If an XML request body is included, it MUST be a DAV:options XML
element.

<!ELEMENT options ANY>
ANY value: A sequence of elements with at most one
timezone-collection-set element.

If an XML response body for a successful request is included, it
MUST be a DAV:options-response XML element.

<!ELEMENT options-response ANY>
ANY value: A sequence of elements with at most one
timezone-collection-set element.

<!ELEMENT timezone-collection-set (href*)>

If CALDAV:timezone-collection-set is included in the iTIP Inbox collection is request body,
the response body for a successful request MUST contain a

Daboo, et al. Expires June 13, August 14, 2005 [Page 17]

Internet-Draft CalDAV December 2004

considered to be an iTIP message. Every resource MUST have February 2005

CALDAV:timezone-collection-set element identifying calendar
collections containing the media
type text/calendar, and contain set of calendar resources that defines
the iCalendar METHOD property.

5.3 iTIP Outbox Collection

On a server supporting 'calendar-schedule' features, every Calendar
MUST have a child collection to contain fanout requests and responses
for appointments scheduled timezone supported by the calendar owner (or other users of
this calendar). This collection is to store REQUESTs initiated by
this calendar server for server.

5.2.5 Example - OPTIONS

>> Request <<

OPTIONS /caldav-root/ HTTP/1.1
Host: cal.example.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:options xmlns:D="DAV:">
<C:calendar-collection-set
xmlns:C="urn:ietf:params:xml:ns:caldav"/>
</D:options>

>> Response <<

HTTP/1.1 200 OK
DAV: 1, calendar-access
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:options-response xmlns:D="DAV:">
<C:calendar-collection-set
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:href>http://cal.example.com/calendars/user/</D:href>
<D:href>http://cal.example.com/calendars/public/</D:href>
</C:calendar-collection-set>
</D:options-response>

In this calendar, as well as REPLY items
received in reply. This collection is only for review because example, the
CalDAV server is responsible for parsing incoming REPLY messages indicates that it provides Class 1 DAV
support and
adding attendee information to events.

Every non-collection resource in calendar-access support. In addition, the scheduling server
indicates the requested locations of the calendar collection
resources.

5.3 Creating calendar resources

Clients typically populate calendars with calendar resources. The
URL for each calendar resource is
considered entirely arbitrary, and does not
need to be bear a REQUEST specific relationship (but might) to the calendar
resource's subject, scheduled time, UID or REPLY. Every other metadata. A new
calendar resource MUST must have the
default MIME type text/calendar, and contains exactly one REQUEST or
exactly one REPLY. When the client sends the HTTP SCHEDULE method to
an iTIP outbox, the server is responsible for putting a copy of of
the iTIP message in that iTIP outbox. This then serves as a record
of outgoing scheduling messages.

The server MAY auto-delete messages in new URL, otherwise the outbox after a suitably
long period or new component
would instead be an update to keep within a quota. The server SHOULD allow the an existing calendar owner to DELETE resources in the outbox. resource.

Daboo, et al. Expires June 13, August 14, 2005 [Page 18]

Internet-Draft CalDAV December 2004

6. Creating Resources

Calendars and individual calendar objects may all be created by
either the CalDAV client or by February 2005

When servers create new resources, it's not hard for the CalDAV server. For example, a server might come preconfigured with a user's calendar, or the CalDAV
client might create to
choose a new calendar collection. Servers might
populate events as calendar objects inside unique URL. It's slightly tougher for clients, because a calendar collection, or
(more typically) clients might create events. Either way, both
client and server MUST comply with the requirements might not want to examine all resources in this document, the collection, and MUST understand objects appearing in calendars or according
might not want to lock the data model defined here.

6.1 MKCALENDAR for creating calendars

The entire collection to ensure that a new MKCALENDAR method is defined for the client one
isn't created with a name collision. However, there are tools to tell
mitigate this. If the
server client intends to create a new calendar and populate it with the default
property values. If non-collection
resource, such as a resource already exists at new VEVENT, the Request-URI, or
if client SHOULD use the HTTP header
"If-None-Match: *" on the PUT request. The Request-URI is contained within a calendar collection, on the
server PUT
request MUST fail include the request with a 409 (Conflict) error. Permission
to use target collection, where the MKCALENDAR method SHOULD resource is to
be governed by the 'bind'
privilege on created, plus the parent collection name of the Request-URI. Permission to
DELETE resource in the last path segment.
The last path segment could be a calendar collection SHOULD likewise random number, or it could be governed by a
sequence number, or a string related to the
'unbind' privilege on object's 'summary'
property. No matter how the parent collection.

If there name is no resource at the Request-URI, and chosen, the server is capable
of creating and supporting a calendar at "If-None-Match"
header ensures that location, then the
server creates the calendar collection. The server MUST also
populate the new collection with the appropriate default property
values, particularly for the resourcetype property and calendar-owner
property. The successful response to MKCALENDAR is typically 201
(Created).

Note that there is no semantic value in any other part of a calendar
name (or a client cannot overwrite an existing resource name, other than possibly the file extension).
Thus,
even if it has accidentally chosen a calendar collection may be called "calendar", "cal",
"Calendario" and so on. It's duplicate resource name.

Servers SHOULD return an ETag header containing the properties actual ETag of
the newly created resource that
define what it is, not the name.

Daboo, et al. Expires June 13, 2005 [Page 19]

Internet-Draft CalDAV December 2004

6.1.1 MKCALENDAR Example on a successful creation.

>> Request

MKCALENDAR /lisa/calendar/ <<

PUT /lisa/calendar/newevent.ics HTTP/1.1
If-None-Match: *
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:20010712T182145Z-123401@example.com
DTSTART:20010714T170000Z
DTEND:20010715T035959Z
SUMMARY:Bastille Day Party
END:VEVENT
END:VCALENDAR

>> Response <<

HTTP/1.1 201 Created
Date: Fri, 22 Oct Thu, 02 Sep 2004 12:17:08 16:53:32 GMT
Location: http://cal.example.com/lisa/calendar/ev1234.ics
Content-Length: 0

6.2 Creating component resources

Clients typically populate new calendars with components.
ETag: "123456789-000-111"

The URL
for each component resource is entirely arbitrary, and does not need
to bear a specific relationship (but might) to the component's
subject, scheduled time, UID or other metadata. A brand-new
component must obviously have a new URL, otherwise the new component
would instead be an update request to change an existing component.

When servers create new resources, it's not hard for event is the server to
choose a unique URL. It's slightly tougher for clients, because same, but with a
client might not want to examine all resources
specific ETag in the collection, and
might not want to lock "If-Match" header, rather than the entire collection to ensure that a new one
isn't created with a name collision. However, there are tools to
mitigate this. If

Daboo, et al. Expires August 14, 2005 [Page 19]

Internet-Draft CalDAV February 2005

"If-None-Match" header.

As mentionned in Section 3.10 of RFC 2445 [2], the client intends to create a new non-collection
resource, such as a new VEVENT, URI of calendar
resources containing (an arbitrary set of) calendaring and scheduling
information may be suffixed by ".ics", and the client SHOULD use URI of calendar
resources containing free or busy time information may be suffixed by
".ifb".

A CalDAV server MAY return the HTTP Location header
"If-None-Match: *" on the PUT request. The Request-URI on the in a 201 (Created)
response to a PUT request MUST include the target collection, where the resource is to
be created, plus if the name of server created the resource in the last path segment.
The last path segment could be at a random number, or it could
different URI than the Request-URI. CalDAV clients MUST be a
sequence number, or a string related able to
handle the object's 'summary'
property. No matter how the name is chosen, URI returned by the "If-None-Match"
header ensures that server in the client cannot overwrite an existing resource
even if it has accidentally chosen a duplicate Location header, by
adjusting their original resource name.

Servers SHOULD return an ETag header containing URI to the actual ETag of new one returned by the newly created resource on a succesful creation.
server.

Daboo, et al. Expires June 13, August 14, 2005 [Page 20]

Internet-Draft CalDAV December 2004

>> Request <<

PUT /lisa/calendar/newevent.ics HTTP/1.1
If-None-Match: *
Host: cal.example.com
Content-Type: text/calendar
Content-Length: xxx

>> Response <<

HTTP/1.1 201 Created
Date: Thu, 02 Sep 2004 16:53:32 GMT
Location: http://cal.example.com/lisa/calendar/ev1234.ics
Content-Length: 0
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.

For optimum interoperability with existing HTTP clients, CalDAV
clients and servers MUST use the file extension ".ics" as well as the
"text/calendar" MIME type, whenever creating February 2005

6. Calendaring Properties

This specification defines new properties for WebDAV resources.
Calendar objects of that
MIME type.

A CalDAV server MAY return access properties may be retrieved just like other WebDAV
properties, using the Location header in a 201 (Created)
response to PROPFIND method.

6.1 CALDAV:calendar-description Property

Name: calendar-description
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Provides a PUT request if the server created description for the resource at that is suitable for
presentation to a
different URI than the Request-URI. CalDAV clients MUST user.
Description: The CALDAV:calendar-description property MAY be able to
handle the URI returned by defined
on all calendar collection resources. If present, the server in property
contains a description of the Location header, by
adjusting their original resource URI to the new one returned by the
server. that is suitable for
presentation layer.

<!ELEMENT calendar-description (#PCDATA) >

Daboo, et al. Expires June 13, August 14, 2005 [Page 21]

Internet-Draft CalDAV December 2004 February 2005

7. Users and Groups

The Calendaring Access Control

7.1 Calendaring Privileges

A CalDAV server MUST support WebDAV ACL specification requires that any principal to whom
permissions can be granted is represented via a special resource that
has a HTTP URL as well as [7]. WebDAV properties. Thus, both users may be
represented (for example, as /principals/users/lisa) and groups (for
example, as /principals/groups/dev-team). This feature offers an
excellent ACL provides a
framework for linking users to calendars in a fashion not
otherwise easily implemented.

Note that the WebDAV principal resources may not be modifiable
through WebDAV. This is an important consideration because it allows
the principal directory to be merely a WebDAV representation extensible list of data
which is canonically stored in an outside system. For example, an
enterprise might use an LDAP server to store and administer all user
and group properties. This LDAP server could be linked into the
WebDAV repository through configuration information. WebDAV server
implementations exist which offer principal resources, but when the
principal resources are queried the server actually makes a LDAP
request to get the principal information from its official source.
This saves privileges on WebDAV clients from having to implement LDAP collections
and provides
a single URL format for principals regardless of whether the user
directory is stored in LDAP or some other system. ordinary resources. A server supporting CalDAV server MUST also support additional properties on
principal resources if these principals are associated with
calendars. In addition, certain properties are required on calendars
to link to principal resources. These properties are the
calendaring privilege defined in the
properties this section.

Daboo, et al. Expires June 13, 2005 [Page 22]

Internet-Draft CalDAV December 2004

8. Property Promotion and Demotion

Property promotion and demotion (hereafter called simply "property
promotion") is

7.1.1 CALDAV:view-free-busy Privilege

Calendar users often wish to allow other users to see their free-busy
time intervals, without viewing the name for other details of the functionality by which a server
ensures that a resource's internal data and its externally-visible
metadata remain consistent. In WebDAV, a collection listing
(PROPFIND) selects calendar
components (location, subject, attendees). This allows a set significant
amount of property names privacy while still allowing those other users to retrieve. For a
collection listing schedule
meetings at times when the calendar user is likely to be useful free.

The CALDAV:view-free-busy privilege controls access to browse calendars, certain
calendaring information must be exposed as WebDAV properties (this
also makes WebDAV SEARCH useful, and makes view the definition start
times and end times of REPORTs
easier). Since a free and busy time intervals. This privilege
may be granted on an entire calendar resource of type text/calendar has
properties which duplicate some of its internal state, it's collection. It may also make
sense to grant this privilege on individual calendar resources (in
which case the
server's responsibility time allocated to keep those consistent somehow.

The server has some leeway in how it makes properties and bodies
consistent, as long calendar resources would show
up as free in the response free-busy rollup to an unauthorized viewer), but a GET shows information
consistent with
server MAY forbid the response to a PROPFIND in CALDAV:view-free-busy privilege from being used
on individual calendar resources. A CalDAV server MUST support the interval in which a
CALDAV:view-free-busy privilege on calendar object has not been altered. Thus, collections.

<!ELEMENT view-free-busy EMPTY>

The CALDAV:view-free-busy privilege is aggregated in the server MAY change DAV:read
privilege. Clients can discover support for various privileges using
the DAV:supported-privilege-set property values when a PUT is performed that alters data exposed as
properties, defined in RFC3744 [7].

7.1.2 Privilege aggregation and also change the body when a PROPPATCH is performed
that alters calendar properties. Alternatively, a server could
implement "lazy promotion" DAV:supported-privilege-set
property

In the WebDAV ACL standard, servers MUST support the
DAV:supported-privilege-set property to show which privileges are
abstract, which privileges are supported, how the privileges relate
to another, and apply consistency changes only when to provide text descriptions (particularly useful for
custom privileges). The relationships between privileges involves
showing which privilege is a
GET, PROPFIND, SEARCH subset or REPORT is issued. Finally, a server might
decompose property data and non-property data into separate locations
and recompose superset of another
privilege. For example, because reading the information only when ACL property is
considered a GET requests more specific privilege than the entire
resource. Any DAV:read privilege (a
subset of these approaches MUST be transparent to the client,
in that operations behave consistently, with complete round-trip
fidelity total set of all actions are allowed), it is aggregated
under the data originally provided. Thus, a server DAV:read privilege. Although the list of supported
privileges MAY
canonicalize its resource bodies (e.g. eliminate meaningless spaces)
but MUST preserve all data.

Not all properties need to be promoted, only those properties most
useful for clients vary somewhat from server to do property value searching or listings of
calendar events either through PROPFIND or through the recurrence
report. All unrecognized properties can be left in the resource body
(such as those beginning with x-).

TODO: This section needs further definition and details. Clients can
upload iCalendar files with syntactic or semantic errors, so helpful
error codes must be chosen for these cases:
o Property is set which can't be demoted without making the
iCalendar body invalid
o iCalendar body provided isn't valid server (the WebDAV ACL

Daboo, et al. Expires June 13, August 14, 2005 [Page 23] 22]

Internet-Draft CalDAV December 2004

9. Scheduling and Fanout

Scheduling and fanout is a valuable function provided by advanced
calendaring servers. Simple clients clearly benefit from having the
logic handled by the server. Rich clients also benefit from having
to upload less data to various servers (including messaging servers
to send invitations via messages) to accomplish the same things.
Servers can sometimes provide more advanced scheduling functionality
than clients - February 2005

specification leaves room for example, a fair amount of diversity in server providing fanout could create
"unconfirmed" VEVENT resources within invitees' calendars.

However, rich calendaring clients may prefer to do fanout. Clients
can perform special functionality during scheduling (for example,
implementations), some relationships MUST hold for a
client may be configured to be able to directly put events on others'
calendars if the user has sufficient permissions). Thus, it is
proposed that CalDAV allow server:
o The server MUST support the client to either perform fanout CALDAV:view-free-busy privilege. The
CALDAV:view-free-busy privilege MUST be non-abstract, and
merely create MUST be
aggregated under the event (complete with attendee information) OR
request that DAV:read privilege.

7.1.2.1 Partial example of DAV:supported-privilege-set property

This is a partial example of how the DAV:supported-privilege-set
property could look on a server perform fanout.

CalDAV servers supporting CalDAV. Note that return the value "calendar-schedule"
aggregation is shown in the DAV
response header MUST support iTIP to send and receive scheduling
requests as well as reply to scheduling request. These servers MUST
handle outgoing iTIP messages submitted to an iTIP Outbox collection,
and MUST deliver incoming iTIP messages to an iTIP Inbox collection.

TODO: We need to clarify if outgoing iTIP messages that have not yet
been delivered to all specified calendars should be accessible as
calendar structure of the DAV:supported-privilege
elements containing each other.

<D:supported-privilege-set xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:supported-privilege>
<D:privilege><D:all/></D:privilege>
<D:abstract/>
<D:description xml:lang="en">Any operation
</D:description>
<D:supported-privilege>
<D:privilege><D:read/></D:privilege>
<D:description xml:lang="en">Read any object
</D:description>
<D:supported-privilege>
<D:privilege><D:read-acl/></D:privilege>
<D:description xml:lang="en">Read ACL
</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:read-current-user-privilege-set/>
</D:privilege>
<D:description xml:lang="en">Read current user privilege
set</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege>
<C:view-free-busy/>
</D:privilege>
<D:description xml:lang="en">View free-busy rollup
</D:description>
</D:supported-privilege>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege><D:write/></D:privilege>
<D:description xml:lang="en">Write any object</D:description>
...
</D:supported-privilege>

Daboo, et al. Expires August 14, 2005 [Page 23]

Internet-Draft CalDAV February 2005

</D:supported-privilege-set>

7.2 Additional Principal Properties

This section defines a new property for WebDAV principal resources as
defined in RFC3744 [7].

7.2.1 CALDAV:calendar-URL Property

Name: calendar-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the iTIP Outbox collection.

Incoming iTIP messages may remain in URL of any calendar collections owned by the iTIP Inbox collection until
a client deletes them.
associated principal resource.
Description:

<!ELEMENT calendar-URL (DAV:href*) >

Support for this property is RECOMMENDED.

Daboo, et al. Expires August 14, 2005 [Page 24]

Internet-Draft CalDAV servers MUST parse incoming REPLY
messages and update February 2005

8. Calendaring Reports

This section defines the appropriate event with attendee information.
Thus, it's not necessary for clients to review REPLY messages,
although they may.

When reports which a CalDAV server receives an iTIP message, it MUST store the
object in an iTIP Inbox collection support
on calendar collections and calendar resources.

CalDAV servers MUST advertise support for those reports with the client
DAV:supported-report-set property defined in DeltaV [5].

Some of these reports allow calendar data (from possibly multiple
resources) to handle. The
message will have properties indicating whether it is new, has been
accepted, has been rejected, and whether it is an obsolete REQUEST
(the event has passed). Note that when a calendar server receives
iTIP messages it MAY auto-accept based on user configured
preferences. How these preferences are configured is out of be returned. Clients SHOULD request the
scope of this specification, but one could imagine DAV:getetag
property whenever executing reports that a CalDAV
server could host auto-accept configuration Web pages. A CalDAV
server is NOT REQUIRED return calendar data, to do
ensure that any auto-accepting, it MAY simply store
the requests local cache used for the next time the client synchronization is online.

Servers SHOULD NOT delete messages before or after a client has

Daboo, et al. Expires June 13, 2005 [Page 24]

Internet-Draft CalDAV December 2004

retrieved the messages in the inbox; instead the server SHOULD leave
Inbox cleanup kept up to
date with the latest changes on the client. A server MAY apply

8.1 REPORT Method

The REPORT method (defined in Section 3.6 of RFC3253 [5]) provides an
extensible mechanism for obtaining information about a quota to resource.
Unlike the iTIP
Inbox (limiting PROPFIND method, which returns the number value of messages, the total size, one or some other
measurable) and MAY bounce incoming messages if more
named properties, the iTIP inbox REPORT method can involve more complex
processing. REPORT is
full or some other repository or account problem valuable in cases where the server has occurred.

Exact mechanisms for triggering fanout requests must be determined
and input is welcome. There are several ways fanout could be
accomplished: (a) A PUT access
to all of the resource triggers fanout, so the body
must contain the fanout information (text and flags), (b) a PROPPATCH
triggers fanout if certain properties are set, (c) a new method
requests fanout of a resource that has already been uploaded. These
three approaches are the most obvious to this author and there is
surprisingly little needed to choose between. More input is needed, for
example input on whether perform the fanout should be synchronous or
asynchronous. An asynchronous fanout mechanism using PUT or
PROPPATCH complex request (such
as a query), and where it would mean that require multiple requests for the
client would synchronously handle to retrieve the
PUT or PROPPATCH itself, but send invitations at some later time. A
synchronous fanout mechanism would probably use a new method with a
name like SCHEDULE, because adding new synchronous behavior information needed to
existing methods might require more complicated server implementation
work.

When perform the same
request.

A server does fanout, that supports calendar-access MUST support the
DAV:expand-property report (defined in Section 3.8 of RFC3253 [5]).

8.2 Reports on collections containing calendars

A WebDAV collection which contains one or more calendar collections
is not a new type of resource, but it may send requests and receive
replies. Probably support these requests and responses should be stored as
WebDAV resources so that new REPORT.
If so, then the client can examine REPORT is expected to have the details if
desired. This could be a separate collection within semantics of including
information from all the calendar
collection.

To achieve these goals, data contained in the collection,
and its children, recursively. These collections may contain more
than only calendar related resources. It's up to the server, if it
supports this section specifies REPORT on a normal WebDAV binding for
the iCalendar Transport-independent Interoperability Protocol (iTIP
[3]). It provides the necessary information collection, to convey iTIP over
WebDAV.

9.1 SCHEDULE Method for WebDAV

The SCHEDULE method submits an iTIP message specified find calendar
resources and decide what to do with non-calendar resources and
whether those may also appear in the request
body to collection or its children.

If these reports are supported on ordinary collections the location specified by server
advertises the Request-URI. capability with the DAV:supported-report-set property
as already described.

8.3 CALDAV:calendar-query Report

The request body
of CALDAV:calendar-query REPORT performs a SCHEDULE method MUST contain an search for all calendar

Daboo, et al. Expires August 14, 2005 [Page 25]

Internet-Draft CalDAV February 2005

resources (e.g., iCalendar object objects) that obey the
restrictions match a specified in iTIP [3]. search
filter. The resource identified by the
Request-URI MUST be a resource collection response of type "itip-outbox"
(Section 5.3).

The submitted iTIP message this report will be delivered to contain all the WebDAV
properties and calendar
addresses resource data specified in the Recipient header.

The calendar address of request. In
the originator case of the iTIP message MUST CALDAV:calendar-data XML element, one can explicitly
specify the calendar components and properties that should be
specified
returned in the Originator header. This calendar address MUST

Daboo, et al. Expires June 13, 2005 [Page 25]

Internet-Draft CalDAV December 2004

identify a resource collection of type "itip-inbox" (Section 5.2). data that is owned by the currently authenticated user.

The calendar address of the recipient(s) of the iTIP message MUST be
specified in matches the Recipient header. There MUST be at least one
Recipient per SCHEDULE request. search
filter.

The body format of the SCHEDULE request this report is a complete iCalendar component
(content type text/calendar), and MUST have an iTIP modeled on the PROPFIND method. The list
of attendees and the organizer information in this
request body might
well be redundant with the values and response bodies of the Recipient and Originator
headers. This is intentional, so CALDAV:calendar-query report use
XML elements that are also used by PROPFIND. In particular the client
request can have more
control over who receives invitations and who sends them:
o The client may send invitations to calendar users not on the
attendee list (for example, to an assistant, caterer, observer,
etc).
o The client may choose not include XML elements to send invitations request WebDAV properties to calendar users
who are on the attendee list (for example, attendees who have been
scheduled through an out-of-band mechanism).
o The originator may be different than
returned. When that occurs the organizer, for example an
assistant who has calendar-bind privileges on response should follow the organizer's
calendar.

The SCHEDULE request is intended to be independent same
behavior as PROPFIND with respect to the PUT DAV:multistatus response
elements used to return specific property results. For instance, a
request that stores an event on to retrieve the value of a particular calendar. This
independence gives greater flexibility property which does not exist is
an error and control to MUST be noted with a response XML element which contains
a 404 (Not Found) status value.

Support for the client. calendar-query REPORT is REQUIRED.

Marshalling:
The request body MUST be a CALDAV:calendar-query XML element as
defined in Section 10.1.
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 event that returned multistatus XML element is sent with SCHEDULE corresponds to an
event stored in
empty.
The response body for a calendar, the client SHOULD submit the PUT successful calendar-query REPORT request
first. That means
MUST contain a DAV:response element for each iCalendar object that when
matched the SCHEDULE request is sent and replies
are returned, search filter. The declaration of the server is more likely DAV:response
element from Section 12.9.1 of RFC2518 [3] has been modified as
follow to have an event on allow the
calendar on which CALDAV:calendar-data element within the
DAV:response element, see Section 10.5

[[Comment.4: We need to collate responses and show attendance.

9.1.1 Status Codes for use with 207 (Multi-Status)

The following are examples define the role of response codes one would expect the Depth request header
when applied to be
used in a 207 (Multi-Status) response for collection resource. We need to specify
preconditions and postconditions. (e.g.,
DAV:number-of-matches-within-limits). --desruisseaux]]

8.3.1 Example: Partial retrieval of events by time range

In this method. Note,
however, that unless explicitly prohibited any 2/3/4/5xx series
response code may be used in a 207 (Multi-Status) response.

200 (OK) - The command succeeded.

202 (Accepted) - The request was accepted, but example, the server has not
performed any action with it yet.

400 (Bad Request) - The client has provided an invalid iTIP message.

403 (Forbidden) - The client, for reasons requests the server chooses not to
specify, cannot submit an iTIP message to return specific
components and properties of the specified Request-URI.

Daboo, et al. Expires June 13, 2005 [Page 26]

Internet-Draft CalDAV December 2004

404 (Not Found) - The URL in the Request-URI, the Originator, or VEVENT components that overlap the
Recipient headers could not be found.

423 (Locked) - The specified resource is locked and
time range from September 2nd, 2004 at 00:00:00 am UTC to September
2nd, 2004 at 11:59:59 pm UTC. In addition the client either DAV:getetag property
is not a lock owner or the lock type requires a lock token to be
submitted also requested and the client did not submit it.

502 (Bad Gateway) - The Recipient header contained a URL which the
server considers to be in another domain, which it cannot forward
iTIP messages to.

507 (Insufficient Storage) - The server did not have sufficient space
to record the iTIP message in a recipient's iTIP inbox.

Also, many errors would be appropriate returned as top-level errors rather
than return a 207 (Multi-Status) response. For example, if the
server did not have sufficient space to record the iTIP message in
the originator's outbox, part of the server could send a 507 (Insufficient
Storage) response with no body. response.

Daboo, et al. Expires June 13, August 14, 2005 [Page 27] 26]

Internet-Draft CalDAV December 2004

9.1.2 Example - Simple appointment invitation February 2005

>> Request <<

SCHEDULE /lisa/calendar/outbox/

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Originator: http://cal.example.com/lisa/inbox/
Recipient: http://cal.example.com/bernard/inbox/
Recipient: http://cal.example.com/cyrus/inbox/
Depth: 1
Content-Type: text/calendar text/xml
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20040901T200200Z
CATEGORIES:APPOINTMENT
ORGANIZER:http://cal.example.com/lisa/inbox/
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:Design meeting
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
IVIDUAL;CN=Lisa Dusseault:http://cal.example.co
m/lisa/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:h
ttp://cal.example.com/bernard/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:http://cal
.example.com/cyrus/inbox/
END:VEVENT
END:VCALENDAR

<?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:calendar-data>
<C:comp name="VCALENDAR">
<C:allprop/>
<C:comp name="VEVENT">
<C:prop name="X-ABC-GUID"/>
<C:prop name="UID"/>
<C:prop name="DTSTART"/>
<C:prop name="DTEND"/>
<C:prop name="DURATION"/>
<C:prop name="EXDATE"/>
<C:prop name="EXRULE"/>
<C:prop name="RDATE"/>
<C:prop name="RRULE"/>
<C:prop name="LOCATION"/>
<C:prop name="SUMMARY"/>
</C:comp>
<C:comp name="VTIMEZONE">
<C:allprop/>
<C:allcomp/>
</C:comp>
</C:comp>
</C:calendar-data>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:time-range start="20040902T000000Z"
end="20040902T235959Z"/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

>> Response <<

Daboo, et al. Expires June 13, August 14, 2005 [Page 28] 27]

Internet-Draft CalDAV December 2004

>> Response << February 2005

HTTP/1.1 207 Multi-Status
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: text/xml text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"> xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:response>
<D:href>http://cal.example.com/bernard/inbox/</D:href>
<D:href
>http://cal.example.com/bernard/calendar/ev102.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"23ba4d-ff11fb"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTART:20040902T100000Z
DTEND:20040902T120000Z
SUMMARY:Design meeting
UID:34222-232@example.com
X-ABC-GUID:E1CX4zp-0005Ld-21@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
</D:response>
<D:response>
<D:href>http://cal.example.com/cyrus/inbox/</D:href>
<D:href
>http://cal.example.com/bernard/calendar/mtg103.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"ff11fb-23ba4d"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTART:20040902T130000Z
DTEND:20040902T150000Z
SUMMARY:Design meeting - Part II
UID:63409-868@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT

Daboo, et al. Expires August 14, 2005 [Page 28]

Internet-Draft CalDAV February 2005

END:VCALENDAR
</C:calendar-data>
</D:response>
</D:multistatus>

8.3.2 Example: Retrieval of todos by alarm time range

In this example, the client requests the server to deliver return the VTODO
components that have an
appointment invitation (iTIP REQUEST) in Bernard's and Cyrus's iTIP
Inbox collections.

9.2 Retrieving incoming iTIP Messages

Incoming iTIP messages will be stored alarm trigger scheduled in resource collection of type
"itip-inbox". The originator of the iTIP message will be specified
in the Originator response header. The same rules for property
promotion apply to incoming iTIP messages, so a client can also use
PROPFIND and REPORT to get some of the most important information on
iTIP messages in the iTIP inbox.

9.2.1 Example - Retrieve incoming iTIP Message time
range.

>> Request <<

GET /bernard/calendar/inbox/mtg456.ics

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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/>
</D:prop>
<C:calendar-data/>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VTODO">
<C:comp-filter name="VALARM">
<C:time-range start="20041121T000000Z"
end="20041121T235959Z"/>
</C:comp-filter>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

8.3.3 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
"20041121-FEEBDAED@foo.org".

Daboo, et al. Expires June 13, August 14, 2005 [Page 29]

Internet-Draft CalDAV December 2004 February 2005

>> Response Request <<

REPORT /bernard/calendar/ HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 17:05:23 GMT
Originator: http://cal.example.com/lisa/inbox/
Host: cal.example.com
Depth: 1
Content-Type: text/calendar text/xml
Content-Length: xxxx

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Server//EN
METHOD:REQUEST
BEGIN:VEVENT
DTSTAMP:20040901T200200Z
CATEGORIES:APPOINTMENT
ORGANIZER:http://cal.example.com/lisa/inbox/
DTSTART:20040902T130000Z
DTEND:20040902T140000Z
SUMMARY:CalDAV draft review
UID:34222-232@example.com
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
IVIDUAL;CN=Lisa Dusseault:http://cal.example.co
m/lisa/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:h
ttp://cal.example.com/bernard/inbox/
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:http://cal
.example.com/cyrus/inbox/
END:VEVENT
END:VCALENDAR

9.3 Acting on incoming iTIP messages

TODO: Need to explain here how to handle incoming iTIP messages. If

<?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/>
</D:prop>
<C:calendar-data/>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:prop-filter name="UID">
<C:text-match
caseless="no">20041121-FEEBDAED@foo.org</C:text-match>
</C:prop-filter>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

8.3.4 Example: Retrieval of events by participation status

In this example, the client wants to accept a message, it needs requests the server to create an event and
mark return the inbox resource as "accepted". If VEVENT
components that have the client wants to reject
it, it simply changes a property. Need to define that property.
Also recommend locking the Inbox resource to avoid race conditions ATTENDEE property with other clients -- or use ETags the value
"mailto:jsmith@example.org" and for which the PARTSTAT parameter is
set to verify. "NEEDS-ACTION".

Daboo, et al. Expires June 13, August 14, 2005 [Page 30]

Internet-Draft CalDAV December 2004

10. HTTP Headers for CalDAV

10.1 Originator Header

Originator = "Originator" ":" absoluteURI

The Originator header value is a URL which identifies an iTIP Inbox
collection owned by the originator February 2005

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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/>
</D:prop>
<C:calendar-data/>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VEVENT">
<C:prop-filter name="ATTENDEE"/>
<C:text-match
caseless="yes">mailto:jsmith@foo.org</C:text-match>
<C:param-filter name="PARTSTAT"/>
<C:text-match caseless="no">NEEDS-ACTION</C:text-match>
</C:param-filter>
</C:prop-filter>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

8.3.5 Example: Retrieval of an iTIP message submitted with events only

In this example, the SCHEDULE method. Note that client requests the absoluteURI production is defined
in RFC2396 [1].

10.2 Recipient Header

Recipient = "Recipient" ":" 1#absoluteURI

The Recipient header value is a URL which identifies one or more iTIP
Inbox collections server to which the SCHEDULE method should delivered a
submitted iTIP message. Note that the absoluteURI production is
defined in RFC2396 [1] return all VEVENT
components.

Daboo, et al. Expires June 13, August 14, 2005 [Page 31]

Internet-Draft CalDAV December 2004

11. Properties from iCalendar February 2005

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

8.3.6 Timezone Examples

The W3C RDF Calendar group has already defined following examples illustrate two common operations a namespace
("http://www.w3.org/2002/12/cal/ical#") and XML element names for
many calendaring properties, and these are completely consistent with
iCalendar. This standard reuses those namespaces, names and
definitions, as much as is consistent with the WebDAV data model.
Additional properties are needed client may
want to describe calendars because perform on the
W3C RDF Calendar group defines properties CalDAV server's timezone collection. These
examples assume that the client has already got the URI for the iCalendar-defined
objects only.

When used as a WebDAV
server's timezone calendar collection.

8.3.6.1 Example: List all available timezones on the server

In this example, the client requests the server to return all
VTIMEZONE components, with just their TZID property, each property name/namespace can
appear only once because and without the property name
embedded DAYLIGHT and namespace is used STANDARD components.

[[Comment.5: A client might also want to
identify get a human-readable display
name for the VTIMEZONE components. Unfortunately, there is no such
property defined in requests like PROPFIND and PROPPATCH.
Multi-valued elements could either be promoted to properties by using
a container (e.g. an 'attendees' iCalendar. The TZNAME property could hold each 'attendee'
element), or multi-valued elements can remain is defined in the iCalendar body,
and not be promoted as WebDAV properties. That means clients must
download the event body to learn the values for those pieces of
metadata.

TODO: Need to reference RFC3339
DAYLIGHT and put date/time values in that
format, STANDARD components and note where that format differs from that would have a value such as "US
Eastern Standard Time" or "US Eastern Daylight Time". What a client
would need here, is a time zone name irrespective of the iCalendar
RFC values.

If any "Standard"
or "Daylight" observance, e.g., "US Eastern Time". Perhaps we should
recommend the use of these properties appear in an iCalendar body stored in a
CalDAV repository they MUST be promoted. All these properties are in the "http://www.w3.org/2002/12/cal/ical#" namespace. DAV:displayname property on timezone
resources. --desruisseaux]]

Daboo, et al. Expires June 13, August 14, 2005 [Page 32]

Internet-Draft CalDAV December 2004

REQUIRED properties for promotion from iCalendar

The "has-xxxx" properties listed above do not correspond to
properties in iCalendar components. Instead they are synthesised by
the WebDAV server based on the component's properties as described in
the following sections. These WebDAV properties are available to
allow clients to provide hints about component state to the user
without the need to explicitly inspect the component data. February 2005

>> Request <<

REPORT /calendar/timezones/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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/>
</D:prop>
<C:calendar-data>
<C:comp name="VCALENDAR">
<C:allprop/>
<C:comp name="VTIMEZONE">
<C:prop name="TZID"/>
</C:comp>
</C:comp>
</C:calendar-data>
<C:filter>
<C:comp-filter name="VCALENDAR">
<C:comp-filter name="VTIMEZONE">
<C:is-defined/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

>> Response <<

HTTP/1.1 207 Multi-Status
Content-Type: text/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/calendar/timezones/tz1.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"tz1-20050125"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>

Daboo, et al. Expires June 13, August 14, 2005 [Page 33]

Internet-Draft CalDAV December 2004

11.1 has-recurrence Property February 2005

<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
TZID:America/New_York
END:VTIMEZONE
END:VCALENDAR
</C:calendar-data>
</D:response>
<D:response>
<D:href
>http://cal.example.com/calendar/timezones/tz2.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"tz2-20050125"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
END:VTIMEZONE
END:VCALENDAR
</C:calendar-data>
</D:response>
</D:multistatus>

8.4 CALDAV:calendar-multiget Report

The "has-recurrence" property indicates whether CALDAV:calendar-multiget REPORT is used to retrieve specific
calendar resources from within a collection, if the corresponding
component contains one or more RRULE, RDATE, EXRULE Request-URI is a
collection, or EXDATE
properties. i.e. to retrieve a specific calendar resource, if the component
Request-URI is recurring. The integer value '1'
indicates that at least one of the recurrence properties a calendar resource. This report is present,
the integer value '0' indicates that no recurrence properties are
present.

11.2 has-alarm Property

The "has-alarm" property indicates whether the corresponding
component contains one or more embedded VALARM components. The
integer value '1' indicates that at least one embedded VALARM
component is present, similar to the integer value '0' indicates
CALDAV:calendar-query REPORT (see Section 8.3), except that no
embedded VALARM components are present.

11.3 has-attachment Property

The "has-attachment" property indicates whether it takes
a list of DAV:href elements instead of a CALDAV:filter element to
determine which calendar resources to return.

Support for the corresponding
component contains one or more ATTACH properties. calendar-multiget REPORT is REQUIRED.

Marshalling:
The integer value
'1' indicates that request body MUST be a CALDAV:calendar-multiget XML element
(see Section 10.6, which MUST contain at least one ATTACH property DAV:href XML
element, and one optional CALDAV:calendar-data element as defined
in Section 10.2. If the Request-URI is present, a collection resource,
then the
integer value '0' indicates DAV:href elements MUST refer to resources within that no ATTACH properties are present.

Daboo, et al. Expires June 13, August 14, 2005 [Page 34]

Internet-Draft CalDAV December 2004

12. CalDAV Resource Properties

The namespace "urn:ietf:params:xml:ns:caldav" is reserved for this
specification, or standards-track specifications written February 2005

collection, and they MAY refer to extend
CalDAV. It resources at any depth within
the collection. As a result the "Depth" header MUST be ignored by
the server and SHOULD NOT be used for custom extensions. It is sent by the
namespace for every new property defined in this section (and every
XML client. If the
Request-URI refers to a non-collection resource, then there MUST
be a single DAV:href element defined in this document).

Note that is equal to the Request-URI.
The response body for a successful request MUST be a
DAV:multistatus XML Schema declarations used in this document element. In the case where there are
incomplete, in that they do not include namespace information. Thus, no
response elements, the reader returned multistatus XML element is empty.
The response body for a successful CALDAV:calendar-multiget REPORT
request MUST NOT use these declarations as the only way to create
valid CalDAV properties or to validate CalDAV-related XML. Some of
the declarations refer to XML elements defined by WebDAV which use
the "DAV:" namespace. Those WebDAV elements are not redefined in
this document.

12.1 Calendar-owner Property

Name: calendar-owner
Location: MUST appear on a calendar if there is contain a principal
resources (user or group) with which it is associated.
Purpose: This property is used for browsing clients to find out the
user, group or resource DAV:response element for which the each calendar events are
scheduled. Sometimes
resource referenced by the calendar provided set of DAV:href elements. The
DAV:response element is a user's calendar, as defined in which
case the value SHOULD be Section 10.5.
In the user's principal URL from WebDAV ACL.
(In this case of an error accessing any of the DAV:owner property probably has provided DAV:href
resources, the same
principal URL value.)
If server MUST return the calendar is a group calendar appropriate error status
code in the value SHOULD be DAV:status element of the
group's principal URL. (In corresponding DAV:response
element.

8.4.1 Example: CALDAV:calendar-multiget Report

In this case example, the DAV:owner property
probably specifies one user who manages this group calendar.)
If client requests the calendar server to return specific
properties of the VEVENT components references by specific URIs. In
addition the DAV:getetag property is a resource calendar (e.g. for a room, or a
projector) there won't be a principal URL, so some other URL
SHOULD be used. A LDAP URL could be useful also requested and returned as
part of the response. Note that in this case.
This property contains one 'href' element in example, the "DAV:" namespace.
Declaration: <!ELEMENT calendar-owner (href) >
Extensibility: MAY contain additional elements, which MUST be
ignored if resource at
http://cal.example.com/bernard/calendar/mtg1.ics does not understood.

12.2 Cal-scale Property

Name: cal-scale
Location: MAY appear on a calendar.
Purpose: This property's value is a string in the same
syntax/values as the CALSCALE property exist,
resulting in iCalendar. Only
Gregorian calendars are defined so far, so if this property is
missing or empty, the calendar is assumed to be a Gregorian
calendar. an error status response.

Daboo, et al. Expires June 13, August 14, 2005 [Page 35]

Internet-Draft CalDAV December 2004

Declaration: <!ELEMENT cal-scale (#PCDATA) >
Extensibility: None February 2005

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Content-Type: text/xml
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/>
</D:prop>
<C:calendar-data>
<C:comp name="VCALENDAR">
<C:allprop/>
<C:comp name="VEVENT">
<C:prop name="UID"/>
<C:prop name="DTSTART"/>
<C:prop name="DTEND"/>
<C:prop name="DURATION"/>
<C:prop name="EXDATE"/>
<C:prop name="EXRULE"/>
<C:prop name="RDATE"/>
<C:prop name="RRULE"/>
<C:prop name="LOCATION"/>
<C:prop name="SUMMARY"/>
</C:comp>
<C:comp name="VTIMEZONE">
<C:allprop/>
<C:allcomp/>
</C:comp>
</C:comp>
</C:calendar-data>
<D:href>http://cal.example.com/bernard/calendar/ev102.ics</D:href>
<D:href>http://cal.example.com/bernard/calendar/mtg1.ics</D:href>
</C:calendar-multiget>

Daboo, et al. Expires June 13, August 14, 2005 [Page 36]

Internet-Draft CalDAV December 2004

13. CalDAV Principal Properties

This section defines new properties February 2005

>> Response <<

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

8.5 CALDAV:free-busy-query Report

The CALDAV:free-busy-query REPORT generates an iCalendar VFREEBUSY
component containing free busy information for WebDAV principal resources as
defined in RFC3744 [8]. All these properties SHOULD exist on every
principal if all relevant
components within calendar collections which have the server supports CalDAV anywhere in its namespace.
Generally, if no appropriate value is known
CALDAV:view-free-busy or DAV:read privilege granted for these properties, the
properties SHOULD exist but be blank. Generally these properties are
likely to be protected but the server MAY allow them to be written by
appropriate users.

13.1 alternate-calendar-URI Property

Name: alternate-calendar-URI
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify current
authenticated user.

Only the URI of an alternate calendar or scheduling
resource for VEVENT components, with the associated principal resource.
Description: The alternate-calendar-URI TRANSP property is used set to provide a
resource address or identifier, such as a mailto URL [10] calendar
address, that can value
different from "TRANSPARENT", and the VFREEBUSY components will be used as an alternative
considered to generate the
primary-itip-inbox-URL of the associated resource in free busy time information.

Daboo, et al. Expires August 14, 2005 [Page 37]

Internet-Draft CalDAV February 2005

Support for the
Originator or Recipient headers. This property SHOULD CALDAV:free-busy-query REPORT is REQUIRED.

Marshalling:
The request body MUST be a CALDAV:free-busy-query XML element (see
Section 10.7, which MUST contain at least one CALDAV:time-range
XML element, as defined in Section 10.4.
The response body for a successful request MUST be a
DAV:multistatus XML element. In the
mailto URL if it case where there are no
response elements, the returned multistatus XML element is known to accept iMIP requests, because clients
generally need empty.
The response body for a way to find out if some successful CALDAV:free-busy-query REPORT
request MUST contains a DAV:response element for each calendar user
collection for whom
the iMIP address is known is which free-busy information has been computed.
Each DAV:response element contains a single CALDAV:calendar-data
XML element as defined in Section 10.2. The CALDAV:calendar-data
XML element MUST contain an iCalendar object with a single
VFREEBUSY component, with zero or more FREEBUSY property values
that describe the same calendar user busy time intervals for whom the
iTIP Inbox address is known, calendar resources
being targeted, and this property is the only
reliable way with other properties set according to link those addresses together.
Value: Zero or more URIs

<!ELEMENT alternate-calendar-URI (href*) >

13.2 calendar-URL Property

Name: calendar-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL
rules of any iCalendar. This report only returns busy time
information. Applications desiring free time information MUST
infer this from available busy time information.

When the Request-URI for a CALDAV:free-busy-query REPORT is a
calendar collections owned by collection, the
associated principal resource.
Value: Zero or more URLs

<!ELEMENT calendar-URL (href*) >

13.3 itip-inbox-URL Property

Name: itip-inbox-URL

Daboo, et al. Expires June 13, 2005 [Page 37]

Internet-Draft CalDAV December 2004

Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify free-busy data is implicitly determined from
the URL "text/calendar" VEVENT resources within the calendar collection,
irrespective of any iTIP Inbox collections owned by the
associated principal resource.
Value: Zero or more URLs

<!ELEMENT itip-inbox-URL (href*) >

13.4 itip-outbox-URL Property

Name: itip-outbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URLs value of any iTIP Outbox collections owned by Depth header included in the associated principal resource.
Value: Zero REPORT
request. Only calendar resources containing VEVENT or more URLs

<!ELEMENT itip-outbox-URL (href*) >

13.5 primary-itip-inbox-URL Property

Name: primary-itip-inbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify VFREEBUSY
components that have the URL CALDAV:view-free-busy privilege granted to
the current authenticated user will be computed in the response.

When the Request-URI for a CALDAV:free-busy-query REPORT is a
non-calendar collection, the scope of the principal iTIP Inbox collection
owned report is governed by the associated principal resource. A principal resource
may have many iTIP Inbox collection, but it must have one
"principal iTIP Inbox".
Value: URI

<!ELEMENT primary-itip-inbox-URL (href) >

13.6 primary-itip-outbox-URL Property

Name: primary-itip-outbox-URL
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify
value of the URL Depth header in the request as follows:

'Depth: 0' - an empty VFREEBUSY component will be returned as
there is no valid calendar data to be scanned on the collection.

'Depth: 1' - free-busy data for any calendar collections
immediately within the target collection is returned.

'Depth: infinity' - free-busy data for all calendar collections
within any sub-collections of the principal iTIP Outbox target collection
owned by is returned.

8.5.1 Example: CALDAV:free-busy-query Report

In this example, the associated principal resource. A principal resource
may have many iTIP Outbox collection, but it must have one
"principal iTIP Outbox".
Value: URI

<!ELEMENT primary-itip-outbox-URL (href) > client requests the server to return free-busy
information on the calendar collection /bernard/calendar/, between
9:00 AM and 5:00 PM on 2nd September 2004. The server responds

Daboo, et al. Expires June 13, August 14, 2005 [Page 38]

Internet-Draft CalDAV December 2004

14. Calendaring Privileges

A CalDAV server MUST support the WebDAV ACLs standard [8]. That
standard provides a framework for an extensible list February 2005

indicating three busy time intervals of privileges on
WebDAV collections one hour, two hours and ordinary resources. A CalDAV server MUST also
support the 30
minutes during the course of the time interval being examined.

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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="20040902T090000Z"
end="20040902T170000Z"/>
</C:free-busy-query>

>> Response <<

HTTP/1.1 207 Multi-Status
Content-Type: text/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/calendar/</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
<C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VFREEBUSY
DTSTAMP:20050125T090000Z
DTSTART:20040902T090000Z
DTEND:20040902T170000Z
FREEBUSY:20040902T090000Z/PT1H,
20040902T120000Z/PT2H,
20040902T160000Z/PT30M
END:VFREEBUSY
END:VCALENDAR
</C:calendar-data>
</D:response>
</D:multistatus>

Daboo, et al. Expires August 14, 2005 [Page 39]

Internet-Draft CalDAV February 2005

9. Synchronization Operations

WebDAV already provides functionality required to synchronize a
collection or set of calendar-specific privileges defined in collections, make changes offline, and a simple
way to resolve conflicts when reconnected. Strong ETags are the key
to making this
section.

14.1 view-free-busy Privilege work, but these are not required of all WebDAV
servers. Since offline functionality is more important to Calendar users often wish
applications than to allow other users WebDAV applications, CalDAV servers MUST
support strong ETags.

9.1 Use of Reports

9.1.1 Restrict the Time Range

The reports provided in CalDAV can be used by clients to see optimize
their free-busy
times, without viewing the other details performance in terms of network bandwidth usage, and resource
consumption on the calendar events
(location, subject, attendees). This allows a significant amount local client machine. Both of
privacy while still allowing those other users issues are
certainly major considerations for mobile or handheld devices with
limited capacity, but they are also relevant to schedule meetings
at times when desktop client
applications in cases where the calendars contain large amounts of
data.

Typically clients present calendar owner is likely data to be free.

The view-free-busy privilege users in views that span a
finite time interval, so whenever possible clients should only
retrieve calendar items from the "urn:ietf:params:xml:ns:caldav"
namespace controls access server using CALDAV:calendar-query
report combined with a time-range element to view limit the start times and end times of
free and busy blocks scope of time. This privilege may be granted on an
entire calendar. It may also make sense to grant this privilege on
individual events (in which case the time allocated
returned items to just those events
would show up as free in the free-busy rollup needed to an unauthorized
viewer), but a server MAY forbid the free-busy privilege from being
used on individual events or event collections. A CalDAV server MUST
support populate the free-busy privilege on a Calendar collection.

<!ELEMENT view-free-busy EMPTY>

The view-free-busy privilege is aggregated current view.

9.1.2 Synchronize by Time Range

Typically in a calendar, historical data (events, to-dos etc that
have completed prior to the standard WebDAV
'read' privilege. Clients current date) do not change, though they
may be deleted. As a result, a client can discover support for various
privileges using speed up the 'DAV:supported-privilege-set' property defined
in RFC3744 [8].

14.2 schedule Privilege

The schedule privilege controls
synchronization process by only considering data for the use of SCHEDULE to submit an iTIP
message via an iTIP Outbox collection. A calendar owner will
generally have schedule permission on their own outbox present time
and never
grant that permission the future up to anybody else. a reasonable limit (e.g., one week, one month).
If the privilege is granted user then tries to somebody other than examine a portion of the calendar owner, outside
of the range that person is called has been synchronized, the
delegate, somebody who client can issue invitations or replies perform
another synchronization operation on behalf of the calendar owner. Thus, if a server receives new time interval being
examined. This 'just-in-time' synchronization can minimize bandwidth
for common user interaction behaviors.

9.1.3 Synchronization Process

If a SCHEDULE request
where client wants to support calendar data synchronization, as
opposed to downloading calendar data each time it is needed, it needs
to cache the authenticated sender of component resources URI and ETag along with the SCHEDULE request does not have
schedule permission, actual
calendar data. Whilst the server MUST reject URI remains static for the request.

<!ELEMENT schedule EMPTY >

For example, lifetime of the
component, the ETag will change with each successive change to the following ACE, on Bernard's iTIP Outbox, would only

Daboo, et al. Expires June 13, August 14, 2005 [Page 39] 40]

Internet-Draft CalDAV December 2004

grant the privilege to Bernard to schedule on behalf of himself:

<D:ace xmlns:D="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav">
<D:principal>
<D:href>http://cal.example.com/users/bernard</D:href>
</D:principal>
<D:grant>
<D:privilege><C:schedule/></D:privilege>
</D:grant>
</D:ace>

14.3 calendar-bind Privilege

The calendar-bind privilege is used on a iTIP Inbox or on a calendar
collection, February 2005

component data. Thus to govern whether synchronize a user may cause new calendar resources
(MIME type text/calendar) to be created in local data cache with the collection. It is
similar to
server, the WebDAV 'bind' privilege but more restricted, because
it only allows client can first fetch the user to create new resources of certain types. It
doesn't, URI/ETag pairs for example, allow the privileged user to create new
collections.

Recall time
interval being considered, and compare those results with the cached
data. Any cached component whose ETag differs from that on the iTIP Inbox is used to receive iTIP messages. The
server automatically creates resources inside the iTIP Inbox when it
handles invitations for the inbox's owner. Thus, the calendar-bind
privilege determines whether an event organizer is allowed needs to send an
invitation be synchronized.

In order to an attendee and have it appear in their iTIP Inbox.

One way an invitation may appear in an iTIP inbox is with properly detect the
SCHEDULE request. If changes between the server receives a SCHEDULE request where and client
data, the client will need to keep a
calendar inbox is named in record of which items have been
created, changed or deleted since the Recipient header, last synchronization operation
so that it MUST check to see
whether can reconcile those changes with the 'calendar-bind' privilege is granted either to data on the
authenticated sender server.

An example of the request, OR how to the owner of the iTIP
Outbox do that would be the following:

The client issues a CALDAV:calendar-query REPORT request comes from (the Request-URI of the SCHEDULE
method). Thus, if user Alice grants Bob calendar-bind privilege on
Alice's inbox, for a
specific time range, and Bob grants Margaret (his assistant) schedule
privilege on Bob's outbox, then transitively, Margaret can send a
SCHEDULE request to Bob's outbox, where Alice's inbox is named in the
Recipient header. If the server's calendar-bind privilege check
fails asks for a given inbox, the rest of the SCHEDULE request may still
succeed, but a 403 Forbidden error would appear in only the Multi-status
response DAV:getetag property to the SCHEDULE request.
be returned:

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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="20040902T235959Z"/>
</C:comp-filter>
</C:comp-filter>
</C:filter>
</C:calendar-query>

The server SHOULD also attempt to apply client then uses the calendar-bind privilege
in other situations where it is requested results to add a resource determine which components
have changed, been created or deleted on the server and how those
relate to locally cached components that may have changed, been
created or deleted. If the
iTIP inbox. For example, if client determines that there are items
on the server handles invitations received
through some other iTIP binding, that need to be fetched, the server SHOULD try client issues a
CALDAV:calendar-multiget report to see if fetch the actual data:

Daboo, et al. Expires June 13, August 14, 2005 [Page 40] 41]

Internet-Draft CalDAV December 2004

invitation should be automatically rejected based on February 2005

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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/>
</D:prop>
<C:calendar-data>
<C:comp name="VCALENDAR">
<C:allprop/>
<C:comp name="VEVENT">
<C:prop name="UID"/>
<C:prop name="DTSTART"/>
<C:prop name="DTEND"/>
<C:prop name="DURATION"/>
<C:prop name="EXDATE"/>
<C:prop name="EXRULE"/>
<C:prop name="RDATE"/>
<C:prop name="RRULE"/>
<C:prop name="LOCATION"/>
<C:prop name="SUMMARY"/>
</C:comp>
<C:comp name="VTIMEZONE">
<C:allprop/>
<C:allcomp/>
</C:comp>
</C:comp>
</C:calendar-data>
<D:href>http://cal.example.com/bernard/calendar/evt1.ics</D:href>
<D:href>http://cal.example.com/bernard/calendar/mtg1.ics</D:href>
</C:calendar-multiget>

9.2 Restrict the access
control on Properties Returned

Clients may not need all the iTIP inbox.

Outside properties in a calendar component when
presenting information to the iTIP inbox, user. Since some property data can be
large (e.g., 'ATTACH' or 'ATTENDEE' lists) clients can choose to
ignore those by only requesting the same privilege has a slightly different
effect, but has specific items it knows it will
use, through use of the same meaning. If CALDAV:calendar-data XML element in the server receives any HTTP
request which would create a new resource inside
relevant reports.

However, if a calendar, the
server MUST check to see whether calendar-bind privilege is granted
on that calendar collection.

Typically, not many users will allow others to put events directly on
their calendar, instead preferring to see invitations and choose
whether client needs to accept. In the exceptional cases, users will allow make a
select few to directly put events on their calendar, and in these
cases, the 'calendar-bind' privilege will be granted change to those few.
On a component, it can

Daboo, et al. Expires August 14, 2005 [Page 42]

Internet-Draft CalDAV February 2005

only change the other hand, many users are happy entire component data via a PUT request. There is no
way to receive invitations from
anyone, so an iTIP inbox may grant 'calendar-bind' privilege incrementally make a change to all
users.

<!ELEMENT calendar-bind EMPTY >

14.4 Privilege aggregation and the 'supported-privilege-set' property

In the WebDAV ACL standard, servers MUST support a set of properties within a
calendar component resource. As a result the
'supported-privilege-set' property client will have to show which privileges are
abstract, which privileges are supported, how
cache the privileges relate
to another, and to provide text descriptions (particularly useful for
custom privileges). The relationships between privileges involves
showing which privilege is a subset or a superset entire set of another
privilege. For example, because reading the ACL property is
considered properties on a more specific privilege than resource that is being
changed.

9.3 Use the read privilege (a
subset of Server Timezone Collection

Clients should use the total set of actions are allowed), timezone components in the server's
timezone collection advertises in the namespace report, for any
timezones for calendar components that it is aggregated
under creates. This avoids the read privilege. Although
need for the list of supported privileges
MAY vary somewhat from client or server to server (the WebDAV ACL specification
leaves room for a fair amount of diversity in server
implementations), some relationships MUST hold for a CalDAV server:
o The server MUST support send the view-free-busy privilege. The
view-free-busy privilege MUST be non-abstract, timezone data along with
the component data and MUST thus reduces network bandwidth usage.

Daboo, et al. Expires August 14, 2005 [Page 43]

Internet-Draft CalDAV February 2005

10. XML Element Definitions

10.1 CALDAV:calendar-query XML Element

Name: calendar-query
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Defines a report for querying calendar data
Description See Section 8.3.

<!ELEMENT calendar-query (DAV:allprop | DAV:propname | DAV:prop)?
calendar-data? filter>

10.2 CALDAV:calendar-data XML Element

Name: calendar-data
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Used to define which parts of a calendar component object
should be
aggregated under the read privilege.
o If returned by the server supports scheduling, report that uses this element.
Description: When used in a request, the server MUST support CALDAV:calendar-data element
specifies the
schedule and calendar-bind privileges. Both these privileges MUST
be non-abstract, iCalendar components and MUST properties to be aggregated under returned
in the 'bind'
privilege.

14.4.1 Partial example of 'supported-privilege-set' property

This is a partial example iCalendar objects part of how the 'supported-privilege-set'
property could look on response. If this element
doesn't contain any CALDAV:comp element, iCalendar objects will be
returned with all their components and properties.
Value: When used inside a server supporting CalDAV. Note response, the CALDAV:calendar-data element
contains an iCalendar object that
aggregation matched the search filter
specified in the request.

<!ELEMENT calendar-data ((comp expand-recurrence-set?) |
#PCDATA)?>

<!ATTLIST calendar-data return-content-type CDATA
"text/calendar">

10.2.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 shown an iCalendar component name (e.g.,
"VEVENT")

NOTE: The CALDAV:prop and CALDAV:allprop elements used here have the
same name as elements defined in WebDAV. However, the structure of elements used
here have the 'supported-privilege' "urn:ietf:params:xml:ns:caldav" namespace, as opposed
to the "DAV:" namespace used for elements defined in WebDAV.

Daboo, et al. Expires June 13, August 14, 2005 [Page 41] 44]

Internet-Draft CalDAV December 2004

elements containing each other.

Daboo, et al. Expires June 13, 2005 [Page 42]

Internet-Draft CalDAV December 2004

outbox</D:description>
</D:supported-privilege>
...
</D:supported-privilege>
</D:supported-privilege-set>

Daboo, et al. Expires June 13, February 2005 [Page 43]

Internet-Draft CalDAV December 2004

15. Calendaring Reports

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

<!ATTLIST comp name CDATA #REQUIRED>

10.2.2 CALDAV:allcomp XML Element

Name: allcomp
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies that all components shall be returned
Description: This section defines element can be used when the reports which a CalDAV server MUST support
on Calendars. These client wants all provide special query functionality not
normally handled types
of components returned by the generic PROPFIND or SEARCH mechanisms. a report.

<!ELEMENT allcomp EMPTY>

10.2.3 CALDAV:allprop XML Element

Name: allprop
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies that all properties shall be returned.
Description: This element can be required used when the client wants all
properties of components returned by a PROPFIND or SEARCH cannot be written report.

NOTE: The 'allprop' element defined here has the same name as the
'allprop' element defined in WebDAV. However, the 'allprop' element
defined here uses the "urn:ietf:params:xml:ns:caldav" namespace, as
opposed to
request the data required for a common use case without an reasonable
amount of complex calculation or unnecessary data transmitted. See
DeltaV or ACL standards "DAV:" namespace used for some examples of reports required in
other situations.

As the 'allprop' element
defined in DeltaV, all REPORT requests include an WebDAV.

<!ELEMENT allprop EMPTY>

10.2.4 CALDAV:prop XML body naming Element

Name: prop
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Defines which properties to return in the type response.
Description: The "name" attribute specifies the name of report requested (only one) and some variables for how
that report is the iCalendar
property to return (e.g., "ATTENDEE"). The "novalue" attribute
can be compiled. Note used by clients to request that support for the REPORT
method does not imply support for all reports defined in all WebDAV
extensions. A CalDAV server is required to support all actual value of the reports
defined here and in
property not be returned (if the ACL standard, but "novalue" attribute is not expected set to support
DeltaV reports unless it advertises them. Reports are advertised
with
"yes"). In that case the 'supported-report-set' property defined in DeltaV so a
CalDAV server MUST provide a value for will return just the 'supported-report-set'
property.

Each report defined here comes with specialized errors. In addition,
some WebDAV status codes are applicable to any request or to iCalendar
property name and any
REPORT request. This includes redirect status codes, syntax errors
(400 Bad Request), permission errors or policy errors (401
Unauthorized iCalendar parameters and 403 Forbidden), 404 Not Found, or a request-body
that isn't XML or is invalid XML (422 Unprocessable Entity). When an
error is trailing ":"
without the subsequent value data.

NOTE: The 'prop' element defined in this document, it is used in an error response
body inside an XML document (this practice was established with
DeltaV and ACL in order to avoid status code collisions). For
example:

Sample error response

HTTP/1.1 409 Conflict
Date: Sun, 16 November 2003 18:40:01 GMT
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="UTF-8" ?>
<D:error xmlns:D="DAV:">
<range-invalid xnlns="urn:ietf:params:xml:ns:caldav"/>
</D:error> here has the same name as the 'prop'

Daboo, et al. Expires June 13, August 14, 2005 [Page 44] 45]

Internet-Draft CalDAV December 2004

15.1 Reports on collections containing Calendars

A WebDAV collection which contains one or more calendars is not a new
type of resource, but it may support these new REPORT types. If so,
then the REPORT is expected to have the semantics of including
information from all the calendar data contained February 2005

element defined in WebDAV. However, the collection,
and its children, recursively. These collections may contain more
than only calendar-related resources. It's up to 'prop' element defined here
uses the server, if it
supports this REPORT on a normal WebDAV collection, to find event and
free-busy data and decide what "urn:ietf:params:xml:ns:caldav" namespace, as opposed to do with non-calendaring resources
and whether those may also appear in the collection or its children.

If these reports are supported on ordinary collections the server
advertises
"DAV:" namespace used for the capability with 'prop' element defined in WebDAV.

<!ELEMENT prop EMPTY>

<!ATTLIST prop name CDATA #REQUIRED
novalue (yes|no) "no">

10.2.5 CALDAV:expand-recurrence-set XML Element

Name: expand-recurrence-set
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Forces the 'supported-report-set' property as
already described.

15.2 calendar-query Report server to expand recurring components into
separate instances.
Description: The calendar-query REPORT performs a search for all iCalendar objects expand-recurrence-set element specifies that match a specified search filter. The response of this report
will contain all the WebDAV
recurring components shall be returned as multiple components with
no recurrence properties (i.e., EXDATE, EXRULE, RDATE and RRULE).
The required "start" and "end" attributes contain iCalendar object data format
DATE-TIME (always specified in UTC) or DATE values that define the request. In
time interval over which the case of recurrence expansion should take
place. The start value is inclusive and the calendar-query-result,
one can explicitly specify end value is
exclusive of the interval as per iCalendar components DTSTART and properties
that should be returned in the iCalendar object data that matches the
search filter.

Support for the calendar-query REPORT is REQUIRED. DTEND
properties. The marshalling of server MUST return only those expanded components
whose time interval intersects the body of interval specified by the calendar-query REPORT request, as
well as modifications to the multi-status body used in the REPORT
response, are described in the following sections.

15.2.1 calendar-query Element

The request body MUST be a "calendar-query" XML element. start
and end attributes.

<!ELEMENT calendar-query (DAV:allprop | DAV:propname | DAV:prop)?
calendar-query-result? filter>

15.2.2 icalcomp expand-recurrence-set EMPTY>
<!ATTLIST expand-recurrence-set start CDATA #REQUIRED
end CDATA #REQUIRED>

10.3 CALDAV:filter XML Element

The "icalcomp" element defines

Name: filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Determines which matching components to return in are returned.
Description: The "filter" element specifies the
response. search filter used to
match components that should be returned by a report.

<!ELEMENT icalcomp ((allicalcomp, (allicalprop | icalprop*)) |
(icalcomp*, (allicalprop | icalprop*)))
expand-recurrence-set?> filter comp-filter>

10.3.1 CALDAV:comp-filter XML Element

Daboo, et al. Expires June 13, August 14, 2005 [Page 45] 46]

Internet-Draft CalDAV December 2004

<!ATTLIST icalcomp name CDATA #REQUIRED>

name value: February 2005

Name: comp-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Limits the search to only the chosen component types.
Description: The "name" attribute is an iCalendar component name type
(e.g., "VEVENT")

15.2.3 allicalcomp Element

The "allicalcomp" element appearing within "icalcomp" specifies that
all components shall be returned.

<!ELEMENT allicalcomp EMPTY>

15.2.4 allicalprop Element

The "allicalprop" element specifies that all properties shall be
returned.

<!ELEMENT allicalprop EMPTY>

15.2.5 icalprop Element

The 'icalprop' "VEVENT"). When this element defines which properties to is present, the server should
only return in a component if it matches the
response. filter, which is to say:

("no is-defined element" OR "is-defined matches") AND
("no time-range element" OR "time-range matches") AND
("no sub-component filter" OR "all sub-component filters match") AND
("no property filter elements" OR "all property filters match")

<!ELEMENT icalprop EMPTY> comp-filter (is-defined | time-range)?
comp-filter* prop-filter*>

<!ATTLIST icalprop comp-filter name CDATA #REQUIRED
novalue (yes|no) "no">

The value of #REQUIRED>

10.3.2 CALDAV:prop-filter XML Element

Name: prop-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Limits the search to specific properties.
Description: The "name" attribute MUST be contain an iCalendar property
name (e.g., "ATTENDEE")

15.2.6 expand-recurrence-set Element

The expand-recurrence-set element specifies that recurring components
shall be returned as multiple components with no recurrence
properties (i.e., EXDATE, EXRULE, RDATE and RRULE).

<!ELEMENT expand-recurrence-set EMPTY>

TODO: Need to specify how infinite recurrence should be handled. In
the case of VTIMEZONE, the expanded VTIMEZONE component should only
have to cover the time range covered by the components making
reference to the VTIMEZONE component.

ISSUE: Should we have another XML element to specify whether all
component instances of a recurring component should be returned, or

Daboo, et al. Expires June 13, 2005 [Page 46]

Internet-Draft CalDAV December 2004

only the specific instances that matched the specified filter? For
instance, if you search for all VEVENT components that are scheduled
today and you didn't specify the expand-recurrence-set element, then
you may receive recurring VEVENT components that will define
recurrence instances for other dates than today. On the other hand,
if you have specified the expand-recurrence-set element, the server
could return only the recurrence instances that are scheduled today
and omit the others.

15.2.7 filter Element

The 'filter' element specifies the search filter.

<!ELEMENT filter icalcomp-filter>

15.2.8 icalcomp-filter Element

The 'icalcomp-filter' limits the search result to the set of
resources containing components that meet the filter rules.

<!ELEMENT icalcomp-filter (is-defined | time-range)?
icalcomp-filter* icalprop-filter*>

<!ATTLIST icalcomp-filter name CDATA #REQUIRED> "ATTENDEE"). When this element is present, the server should only return 'prop-filter' executes, a
component if it
property matches the filter, which is to say: if:

("no is-defined element" OR "is-defined matches") AND
("no time-range element" OR "time-range matches") AND
("no sub-component filter" text match element" OR "all sub-component filters match") "text-match matches") AND
("no property parameter filter elements" OR "all property parameter filters match")

15.2.9 icalprop-filter Element

The 'icalprop-filter' limits the search result to the set of
resources containing components with properties that meet the
property filter rules.

<!ELEMENT icalprop-filter prop-filter (is-defined | time-range | text-match)?
icalparam-filter*>
param-filter*>

<!ATTLIST icalprop-filter prop-filter name CDATA #REQUIRED>

10.3.3 CALDAV:param-filter XML Element

Name: param-filter
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Limits the search to specific parameters.

Daboo, et al. Expires June 13, August 14, 2005 [Page 47]

Internet-Draft CalDAV December 2004

When February 2005

Description: The "param-filter" element limits the search result to
the set of resources containing properties with parameters that
meet the 'icalprop-filter' parameter filter rules. When this filter executes, a property
parameter matches if:

("no is-defined element"

("is-defined matches" OR "is-defined "text-match matches") AND
("no time-range element" OR "time-range matches") AND
("no text match element" OR "text-match matches") AND
("no parameter filter elements" OR "all parameter filters match")

15.2.10 icalparam-filter Element

The 'icalparam-filter' element limits the search result to the set of
resources containing properties with parameters that meet the
parameter filter rules.

<!ELEMENT icalparam-filter param-filter (is-defined | text-match) >

<!ATTLIST icalparam-filter param-filter name CDATA #REQUIRED>

When this filter executes,

10.3.4 CALDAV:is-defined XML Element

Name: is-defined
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Causes a search to match a resource if a component type,
property or parameter matches if:

("is-defined matches" OR "text-match matches")

15.2.11 is-defined Element name exists.
Description: The 'is-defined' CALDAV:is-defined XML element limits the filter to
resources where the named component, property or parameter is
defined.

<!ELEMENT is-defined EMPTY>

15.2.12 text-match

10.3.5 CALDAV:text-match XML Element

The

Name: text-match element allows for
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a substring matches in match on a property or parameter and
value.
Description: The specified text is used for a substring match against
the property values.

<!ELEMENT text-match #PCDATA>

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

TODO: We need to decide if we want to allow wildcards characters such
as '?' and '%'. or parameter value specified in a report. The
"caseless" attribute allows clients indicates whether the match is case-sensitive
(value set to specify caseless matching
behaviour instead of character-by-character matching for text-match.
The possible values for "caseless" are "yes" "no") or "no". case-insensitive (value set to "yes"). The
default value is server-specified. Caseless matching SHOULD be
implemented as defined in section 5.18 of the Unicode Standard ([UNICODE4]).

Daboo, et al. Expires June 13, 2005 [Page 48]

Internet-Draft CalDAV December 2004
([9]). Support for the "caseless" attribute is optional. A server should
respond with a status of 422 if it is used but cannot be supported.

15.2.13 time-range Element

The time-range element allows for a single time range to be defined,
in order to limit all the results of the search to the set of
resources that contain a component which falls into that time range.

<!ELEMENT time-range EMPTY>

<!ATTLIST time-range start CDATA
end CDATA>

The value of the "start" and "end" attributes MUST follow the syntax
of the DATE or DATE-TIME iCalendar value type.

A VEVENT component falls in a given time-range if:

(DTSTART <= start AND DTEND > start) OR
(DTSTART <= start AND DTSTART+DURATION > start) OR
(DTSTART >= start AND DTSTART < end) OR
(DTEND > start AND DTEND <= end)

A VTODO component falls in a given time-range if:

(DTSTART <= start AND DUE >= start) OR
(DTSTART <= start AND DTSTART+DURATION > start) OR
(DTSTART >= start AND DTSTART < end) OR
(DUE >= start AND DUE < end)

A VJOURNAL component falls in a given time-range if:

DTSTART >= start AND DTSTART < end

A VALARM component falls in a given time-range if:

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

Any property of value type DATE-TIME or DATE (e.g., DTSTAMP) will
match a given time-range if:

value >= start AND value < end

15.2.14 Example: Partial retrieval of events by time range

In this example, the client requests the server to return specific

Daboo, et al. Expires June 13, 2005 [Page 49]

Internet-Draft CalDAV December 2004

components and properties of the VEVENT components that overlap the
time range from September 2nd, 2004 at 00:00:00 am UTC to September
2nd, 2004 at 11:59:59 pm UTC. In addition the WebDAV "getetag"
property is also requested and returned as part of the response.

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
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:calendar-query-result>
<C:icalcomp name="VCALENDAR">
<C:allicalprop/>
<C:icalcomp name="VEVENT">
<C:icalprop name="X-ABC-GUID"/>
<C:icalprop name="UID"/>
<C:icalprop name="DTSTART"/>
<C:icalprop name="DTEND"/>
<C:icalprop name="DURATION"/>
<C:icalprop name="EXDATE"/>
<C:icalprop name="EXRULE"/>
<C:icalprop name="RDATE"/>
<C:icalprop name="RRULE"/>
<C:icalprop name="LOCATION"/>
<C:icalprop name="SUMMARY"/>
</C:icalcomp>
<C:icalcomp name="VTIMEZONE">
<C:allicalprop/>
<C:allicalcomp/>
</C:icalcomp>
</C:icalcomp>
</C:calendar-query-result>
<C:filter>
<C:icalcomp-filter name="VCALENDAR">
<C:icalcomp-filter name="VEVENT">
<C:time-range start="20040902T000000Z"
end="20040902T235959Z">
</C:icalcomp-filter>
</C:icalcomp-filter>

Daboo, et al. Expires June 13, 2005 [Page 50]

Internet-Draft CalDAV December 2004

</C:filter>
</C:calendar-query>

>> Response <<

HTTP/1.1 207 Multi-Status
Content-Type: text/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/calendar/ev102.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>23ba4d-ff11fb</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<C:calendar-query-result>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTART:20040902T100000Z
DTEND:20040902T120000Z
SUMMARY:Design meeting
UID:34222-232@example.com
X-ABC-GUID:E1CX4zp-0005Ld-21@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-query-result>
</D:response>
<D:response>
<D:href>http://cal.example.com/bernard/calendar/mtg103.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>ff11fb-23ba4d</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<C:calendar-query-result>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTART:20040902T130000Z
DTEND:20040902T150000Z
SUMMARY:Design meeting - Part II attribute is optional. A
server should respond with a status of 422 if it is used but
cannot be supported.

<!ELEMENT text-match #PCDATA>

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

Daboo, et al. Expires June 13, August 14, 2005 [Page 51] 48]

Internet-Draft CalDAV December 2004

UID:63409-868@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-query-result>
</D:response>
</D:multistatus>

15.2.15 Example: Retrieval of todos by alarm February 2005

10.4 CALDAV:time-range XML Element

Name: time-range
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Specifies a time interval for testing components against.
Description: The CALDAV:time-range element allows for a single time
range

In this example, to be defined, in order to limit all the client requests results of the server
search to return the VTODO
components set of resources that contain a component which
falls into that have an alarm trigger scheduled in the specified time range. No WebDAV properties are requested.

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:calendar-query-result/>
<C:filter>
<C:icalcomp-filter name="VCALENDAR">
<C:icalcomp-filter name="VTODO">
<C:icalcomp-filter name="VALARM">
<C:time-range start="20041121T000000Z"
end="20041121T235959Z">
</C:icalcomp-filter>
</C:icalcomp-filter>
</C:icalcomp-filter>
</C:filter>
</C:calendar-query>

15.2.16 Example: Retrieval The value of event by UID

In this example, the client requests "start" and "end"
attributes MUST follow the server to return syntax of the DATE or DATE-TIME
iCalendar value type, with any time specified in UTC.
A VEVENT component that has the UID falls in a given time-range if:

(DTSTART <= start AND DTEND > start) OR
(DTSTART <= start AND DTSTART+DURATION > start) OR
(DTSTART >= start AND DTSTART < end) OR
(DTEND > start AND DTEND <= end)

A VTODO component falls in a given time-range if:

(DTSTART <= start AND DUE >= start) OR
(DTSTART <= start AND DTSTART+DURATION > start) OR
(DTSTART >= start AND DTSTART < end) OR
(DUE >= start AND DUE < end)

A VJOURNAL component falls in a given time-range if:

DTSTART >= start AND DTSTART < end

A VALARM component falls in a given time-range if:

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

Any property set to
"20041121-FEEBDAED@foo.org". No WebDAV properties are requested. of value type DATE-TIME or DATE (e.g., DTSTAMP) will
match a given time-range if:

value >= start AND value < end

<!ELEMENT time-range EMPTY>

<!ATTLIST time-range start CDATA
end CDATA>

10.5 DAV:response XML Element

Daboo, et al. Expires June 13, August 14, 2005 [Page 52] 49]

Internet-Draft CalDAV December 2004

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:calendar-query-result/>
<C:filter>
<C:icalcomp-filter name="VCALENDAR">
<C:icalcomp-filter name="VEVENT">
<C:icalprop-filter name="UID">
<C:text-match
caseless="no">20041121-FEEBDAED@foo.org</C:text-match>
</C:icalprop-filter>
</C:icalcomp-filter>
</C:icalcomp-filter>
</C:filter>
</C:calendar-query>

15.2.17 Example: Retrieval of events by participation status

In this example, the client requests the server to return the VEVENT
components February 2005

Name: response
Namespace: DAV:
Purpose: Response that have includes calendar data.
Description: Modifies the ATTENDEE property with standard WebDAV response element to include
calendar data in the value
"mailto:jsmith@example.org" and for which response if required by the PARTSTAT parameter is
set report type.

<!ELEMENT DAV:response (DAV:href,
((DAV:href*, DAV:status)|(DAV:propstat+)),
calendar-data?,
DAV:responsedescription?) >

10.6 CALDAV:calendar-multiget XML Element

Name: calendar-multiget
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: CalDAV report used to "NEEDS-ACTION". No WebDAV properties are requested.

Daboo, et al. Expires June 13, 2005 [Page 53]

Internet-Draft retrieve specific calendar component
items via their URIs.
Description: See Section 8.4.

<!ELEMENT calendar-multiget (DAV:allprop | DAV:propname | DAV:prop)?
calendar-data? DAV:href+>

10.7 CALDAV:free-busy-query XML Element

Name: free-busy-query
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: CalDAV December 2004

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:calendar-query-result/>
<C:filter>
<C:icalcomp-filter name="VCALENDAR">
<C:icalcomp-filter name="VEVENT">
<C:icalprop-filter name="ATTENDEE"/>
<C:text-match
caseless="yes">mailto:jsmith@foo.org</C:text-match>
<C:icalparam-filter name="PARTSTAT"/>
<C:text-match caseless="no">NEEDS-ACTION</C:text-match>
</C:icalparam-filter>
</C:icalprop-filter>
</C:icalcomp-filter>
</C:icalcomp-filter>
</C:filter>
</C:calendar-query>

15.2.18 Example: Retrieval of events only

In this example, the client requests the server report used to generate a VFREEBUSY to return all VEVENT
components. No WebDAV properties are requested. determine busy
time over a specific set of time ranges.
Description: See Section 8.5.

<!ELEMENT free-busy-query time-range+ >

Daboo, et al. Expires June 13, August 14, 2005 [Page 54] 50]

Internet-Draft CalDAV December 2004

>> Request <<

REPORT /bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:calendar-query-result/>
<C:filter>
<C:icalcomp-filter name="VCALENDAR">
<C:icalcomp-filter name="VEVENT">
<C:is-defined/>
</C:icalcomp-filter>
</C:icalcomp-filter>
</C:filter>
</C:calendar-query> February 2005

11. Internationalization Considerations

Daboo, et al. Expires June 13, August 14, 2005 [Page 55] 51]

Internet-Draft CalDAV December 2004

16. Disconnected 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. Strong ETags are the key
to making this work, but these are not required February 2005

12. Security Considerations

12.1 Authentication of all WebDAV
servers. Since offline functionality is more important to Calendar
applications than to other WebDAV applications, Clients

CalDAV servers MUST
support strong ETags.

Much more work could be done to make disconnected operations work
better. WebDAV implementors have discussed ETag-like tags for
collections (CTags?) which would change whenever the membership (or
members?) of a collection changed. Tombstones might also be useful relies on HTTP authentication to synchronize with DELETE operations. However, all these mechanisms
are of general use and not limited authenticate users to Calendaring. Therefore, it is
suggested that work on advanced synchronization take place in the
server. As a
separate document independent of result the calendaring-specific features
discussed here. Many people are interested in doing this kind security considerations for use of
work and it has wide applicability and usefulness. Requirements or
design contributions from calendaring implementors are welcome.

TODO: this section should be expanded to give more guidance to
clients on how HTTP
authentication also apply to synchronize WebDAV objects most effectively. CalDAV. In particular, we need to understand how UID/SEQ metadata works the HTTP Basic
authentication method MUST NOT be used without adequate transport
layer security.

12.2 Denial of Service

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
synchronization.

Note that a recurrence isn't rule that specifies a synchronization problem in this model.
Recurring items appear only once recurring
event occurring every second for the next 100 years which would
result in normal PROPFIND responses, so
there's no danger approximately 3 x 10^9 instances! A report that in synchronizing a client will accidentally
create extra recurrences. Instead, asks for
recurrences appear only in a
special REPORT which MUST not to be used for synchronization. expanded over that range would likely constitute a
denial-of-service attack on the server.

[[Comment.6: We
believe this separation between data (recurring appointments) should make an explicit reference to the security
considerations mentionned in iCalendar, iTIP and
presentation (the display of a period containing several recurrences) iMIP. We should
also specify if there is crucial to simplifying synchronization.

Daboo, et al. Expires June 13, 2005 [Page 56]

Internet-Draft any semantic defined in CalDAV December 2004

17. Security Considerations

TODO for the
iCalendar property CLASS (access classification). --desruisseaux]]

Daboo, et al. Expires June 13, August 14, 2005 [Page 57] 52]

Internet-Draft CalDAV December 2004

18. February 2005

13. IANA Consideration

In addition to the namespaces defined by RFC2518 [5] [3] for XML
elements, this document uses a URN to describe a new XML namespace
conforming to a registry mechanism described in RFC3688 [7]. [6]. All
other IANA considerations mentioned in RFC2518 [5] [3] also apply to this
document.

18.1

13.1 Namespace Registration

Registration request for the caldav 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 June 13, August 14, 2005 [Page 58] 53]

Internet-Draft CalDAV December 2004

19. References

19.1 February 2005

14. Acknowledgements

The authors would like to thank the following individuals for
contributing their ideas and support for writing this specification:
Michael Arick, Mario Bonin, Scott Carr, Helge Hess, Dan Mosedale,
Julian F. Reschke, Mike Shaver, Simon Vaillancourt, and 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.

15. Normative References

[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2396, August 1998. 2119, March 1997.

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

[3] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
"iCalendar Transport-Independent Interoperability Protocol
(iTIP) Scheduling Events, BusyTime, To-dos Goland, Y., Whitehead, E., Faizi, A., Carter, S. and Journal Entries", D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2446, November 1998. 2518,
February 1999.

[4] 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.

[5] Goland, Y., Whitehead, E., Faizi, A., Carter, S. Clemm, G., Amsden, J., Ellison, T., Kaler, C. and D. Jensen,
"HTTP J. Whitehead,
"Versioning Extensions for to WebDAV (Web Distributed Authoring -- WEBDAV", RFC 2518,
February 1999.

[6] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps",
Versioning)", RFC 3339, July 3253, March 2002.

[7]

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

[8]

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

[9] W3C, "iCalendar Schema in RDF/XML", site
http://www.w3.org/2002/12/cal/ical, December 2002.

19.2 Informative References

[10] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.

[11] Clemm, G., Amsden, J., Ellison,

[8] Bray, T., Kaler, C. and J. Whitehead,
"Versioning Extensions to WebDAV (Web Distributed Authoring and
Versioning)", RFC 3253, March 2002.

[12] Reschke, Paoli, J., Reddy, S., Davis, J. Sperberg-McQueen, C., Maler, E. and A. Babich, "WebDAV SEARCH
(DASL)", draft-reschke-webdav-search-06 (work in progress), F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC-xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.

[9] The Unicode Consortium, "The Unicode Standard - Version 4.0",
Addison-Wesley , August 2003,
<http://www.unicode.org/versions/Unicode4.0.0/>.

Daboo, et al. Expires June 13, August 14, 2005 [Page 59] 54]

Internet-Draft CalDAV December 2004

August 2004. February 2005

ISBN 0321185781

Authors' Addresses

Cyrus Daboo
ISAMET Inc.
5001 Baum Blvd Blvd.
Suite 650
Pittsburgh, PA 15213
US

EMail:

Email: daboo@isamet.com
URI: http://www.isamet.com/

Bernard Desruisseaux
Oracle Corporation
600 blvd. Blvd. de Maisonneuve West
10th Floor
Montreal, QC H3A 3J2
CA

EMail:

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

Lisa Dusseault
Open Source Application Foundation
2064 Edgewood Dr.
Palo Alto, CA 94303
US

EMail:

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

Daboo, et al. Expires June 13, August 14, 2005 [Page 60] 55]

Internet-Draft CalDAV December 2004 February 2005

Appendix A. Acknowledgements

Michael Arick has provided substantial feedback for this draft. CalDAV Method Privilege Table (Normative)

The following table extend the WebDAV Method Privilege Table
specified in Appendix B of WebDAV ACL [7].

Daboo, et al. Expires June 13, August 14, 2005 [Page 61] 56]

Internet-Draft CalDAV December 2004 February 2005

Appendix B. Changes

B.1 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.
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.

B.2 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.

B.2

B.3 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

B.3

B.4 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

Daboo, et al. Expires August 14, 2005 [Page 57]

Internet-Draft CalDAV February 2005

c. Added new principal properties
d. Added new SCHEDULE method and related headers
e. Added new privileges for scheduling

B.4

B.5 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 June 13, August 14, 2005 [Page 62] 58]

Internet-Draft CalDAV December 2004 February 2005

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@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 (C) The Internet Society (2004). (2005). 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 June 13, August 14, 2005 [Page 63] 59]

----