WDIFF

draft-dusseault-caldav-01.txt --> draft-dusseault-caldav-02.txt

Network Working Group L. Dusseault C. Daboo
Internet-Draft OSAF ISAMET
Expires: January 16, March 21, 2005 July 18, B. Desruisseaux
Oracle
L. Dusseault
OSAF
September 20, 2004

Calendar Server

Calendaring and Scheduling Extensions for to WebDAV (CalDAV)
draft-dusseault-caldav-01
draft-dusseault-caldav-02

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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.
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 January 16, March 21, 2005.

Abstract

This document specifies a set of methods, headers and resource types
that define the calendaring and scheduling extension to the WebDAV
protocol. In the five years since WebDAV [3] was standardized, at least
three groups have used WebDAV as a basis to provide Internet calendar
access with a minimum of development effort. However, each group
decided independently how the calendaring data model would map to the
WebDAV data model and how to deal with features such as recurrance recurrence
and queries for free-busy times. This draft proposes a standard data

Daboo, et al. Expires March 21, 2005 [Page 1]

Internet-Draft CalDAV September 2004

model mapping and a few extensions to WebDAV that make
WebDAV-server-based calendaring work well for clients while requiring
a minimum of new work (particularly on clients).

Dusseault Expires January 16, 2005 [Page 1]

Internet-Draft caldav July 2004

Table of Contents

1. Introduction

This draft was commissioned at the Fall 2003 Minneapolis working
group meeting of the CalSched working group. The concept . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Advantages of using
HTTP [2] and WebDAV as a basis for a calendaring server is by no
means a new concept: it was discussed in the CalSched working group
as early as 1997 or 1998. Several companies have implemented
calendaring servers using Calendar Access . . . . . . . . . 4
1.1.1 HTTP PUT/GET to upload and download
iCalendar [1] events, URLs for Calendar Objects . . . . . . . . . . . . 4
1.1.2 Web Services and using WebDAV PROPFIND Web Interfaces . . . . . . . . . . . 5
1.1.3 Client Implementations from Simple to get listings of
resources. However, those implementations do not interoperate
because there are many small Rich . . . . . . 5
1.1.4 Support for lock feature . . . . . . . . . . . . . . . 6
1.1.5 Support for access control . . . . . . . . . . . . . . 6
1.1.6 Security, Implementations and big decisions to be made in how to
model calendaring data as WebDAV resources Deployed Base . . . . . 7
1.1.7 Migration, Synchronization and properties, as well as
how to implement required Offline Functionality . 7
1.1.8 Search Support . . . . . . . . . . . . . . . . . . . . 7
1.1.9 Clear extensibility model . . . . . . . . . . . . . . 8
2. Required CalDAV features that aren't already part of
WebDAV. This draft is therefore intended to propose a standard way . . . . . . . . . . . . . . . . . . 9
3. CalDAV Support Discovery . . . . . . . . . . . . . . . . . . 10
3.1 Example: Using OPTIONS for the Discovery of modeling calendar data in WebDAV, plus some additional features to
make calendaring work well.

WebDAV properties and other XML element names defined in this
specification all Support for
CalDAV . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Calendaring Data Model . . . . . . . . . . . . . . . . . . . 11
4.1 Calendar Repository or Server . . . . . . . . . . . . . . 11
4.2 Recurrence and the Data Model . . . . . . . . . . . . . . 12
4.3 CalDAV and timezones . . . . . . . . . . . . . . . . . . . 12
4.4 Scheduling, Fanout and the Data model . . . . . . . . . . 13
5. New Resource Types . . . . . . . . . . . . . . . . . . . . . 15
5.1 Calendar Container Collection . . . . . . . . . . . . . . 15
5.2 Calendars Collection . . . . . . . . . . . . . . . . . . . 15
5.3 Event Collection . . . . . . . . . . . . . . . . . . . . . 16
5.4 Todo Collection . . . . . . . . . . . . . . . . . . . . . 16
5.5 Journal Collection . . . . . . . . . . . . . . . . . . . . 17
5.6 iTIP Inbox Collection . . . . . . . . . . . . . . . . . . 17
5.7 iTIP Outbox Collection . . . . . . . . . . . . . . . . . . 17
6. Creating Resources . . . . . . . . . . . . . . . . . . . . . 19
7. Users and Groups . . . . . . . . . . . . . . . . . . . . . . 21
8. Property Promotion and Demotion . . . . . . . . . . . . . . 22
9. Scheduling and Fanout . . . . . . . . . . . . . . . . . . . 23
9.1 SCHEDULE Method for WebDAV . . . . . . . . . . . . . . . . 24
9.1.1 Status Codes for use with 207 (Multi-Status) . . . . . 25
9.1.2 Example - Simple appointment invitation . . . . . . . 26
9.2 Retrieving incoming iTIP Messages . . . . . . . . . . . . 27
9.2.1 Example - Retrieve incoming iTIP Message . . . . . . . 27
10. HTTP Headers for CalDAV . . . . . . . . . . . . . . . . . . 29
10.1 Originator Header . . . . . . . . . . . . . . . . . . . 29
10.2 Recipient Header . . . . . . . . . . . . . . . . . . . . 29
11. Properties from iCalendar . . . . . . . . . . . . . . . . . 30
11.1 has-recurrence Property . . . . . . . . . . . . . . . . 32

Daboo, et al. Expires March 21, 2005 [Page 2]

Internet-Draft CalDAV September 2004

11.2 has-alarm Property . . . . . . . . . . . . . . . . . . . 32
11.3 has-attachment Property . . . . . . . . . . . . . . . . 32
12. CalDAV Resource Properties . . . . . . . . . . . . . . . . . 33
12.1 Calendar-owner Property . . . . . . . . . . . . . . . . 33
13. CalDAV Principal Properties . . . . . . . . . . . . . . . . 34
13.1 alternate-calendar-URI Property . . . . . . . . . . . . 34
13.2 calendar-URL Property . . . . . . . . . . . . . . . . . 34
13.3 itip-inbox-URL Property . . . . . . . . . . . . . . . . 34
13.4 itip-outbox-URL Property . . . . . . . . . . . . . . . . 35
13.5 primary-itip-inbox-URL Property . . . . . . . . . . . . 35
13.6 primary-itip-outbox-URL Property . . . . . . . . . . . . 35
14. Calendaring Privileges . . . . . . . . . . . . . . . . . . . 36
14.1 view-free-busy Privilege . . . . . . . . . . . . . . . . 36
14.2 schedule Privilege . . . . . . . . . . . . . . . . . . . 36
14.3 calendar-bind Privilege . . . . . . . . . . . . . . . . 37
14.4 Privilege aggregation and the "urn:ietf:params:xml:ns:calsch" namespace.
Implementors may find occasion
'supported-privilege-set' property . . . . . . . . . . . 38
14.4.1 Partial example of 'supported-privilege-set'
property . . . . . . . . . . . . . . . . . . . . . . 38
15. Calendaring Reports . . . . . . . . . . . . . . . . . . . . 41
15.1 calendar-time-range Report . . . . . . . . . . . . . . . 42
15.1.1 Request for 'calendar-time-range' . . . . . . . . . 42
15.1.2 Response to define new 'calendar-time-range' . . . . . . . . . 43
15.1.3 Errors for 'calendar-time-range' . . . . . . . . . . 44
15.2 calendar-property-search REPORT . . . . . . . . . . . . 44
15.2.1 Example: calendar-property-search REPORT . . . . . . 44
16. Using existing WebDAV properties features in Calendaring . . . . . . . 46
16.1 SEARCH and
other XML elements calendar data . . . . . . . . . . . . . . . . 46
16.2 Disconnected Operations . . . . . . . . . . . . . . . . 46
17. Security Considerations . . . . . . . . . . . . . . . . . . 48
18. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 49
18.1 Namespace Registration . . . . . . . . . . . . . . . . . 49
19. Normative References . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 50
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.1 Changes in implementing this specification, but this
namespace is not intended for use -02 . . . . . . . . . . . . . . . . . . . . . . 53
B.2 Changes in custom extensions.

1.1 Advantages -01 . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . 54

Daboo, et al. Expires March 21, 2005 [Page 3]

Internet-Draft CalDAV September 2004

1. Introduction

The concept of using HTTP [5] and WebDAV for Calendar Access

WebDAV offers a number of advantages as a framework or basis for
calendar access. Most of these advantages boil down to a significant
reduction calendaring
server is by no means a new concept: it was discussed in design costs, implementation costs, interoperability
test costs, deployment 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 [3] events, 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, as well as how to implement required features that aren't
already part of WebDAV. This draft is therefore intended to propose
a standard way of modeling calendar data in WebDAV, plus some
additional features to make calendaring work well.

WebDAV properties and other XML element names defined in this
specification all use the "urn:ietf:params:xml:ns:caldav" namespace.
Implementors may find occasion to define new WebDAV properties and
other XML elements in implementing this specification, but this
namespace is not intended for use in custom extensions.

1.1 Advantages of WebDAV for Calendar Access

WebDAV offers a number of advantages as a framework or basis 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 or implementor finds certain small errors and the
IETF spends considerable time and effort remediating these. Some of
the advantages are contingent upon the way WebDAV is used, which is
why this section exploring advantages is inseparable from the rest of
this document for the moment.

1.1.1 HTTP URLs for Calendar Objects

WebDAV is an extension of HTTP [2], to the HTTP/1.1 [5] protocol, therefore its
URLs 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 to be written
for devices that already have a HTTP stack: the client merely needs
to download those calendar objects and be able to parse their
formats. Since the iCalendar [1] [3] 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 used to
represent a calendar object, then appointment references can be
easily downloaded, synchronized and shared.

Dusseault Expires January 16, 2005 [Page 2]

Internet-Draft caldav July 2004

Specifying new URL formats creates additional work for implementors

Daboo, et al. Expires March 21, 2005 [Page 4]

Internet-Draft CalDAV September 2004

of clients, servers and related applications that might see those
URLs. Although new URL formats are appropriate 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 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, as
opposed to thin clients or Web browsers) typically also have a Web
interface accessible by thin clients. Some calendaring applications
are available only via Web interfaces, for example those found on
systems such as Yahoo! Groups.

Because of the frequent use of Web interfaces, and the possibility of
supporting Web services, WebDAV is a particularly suitable framework
for calendar data. HTTP URLs 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/deploy/
confeat/e2kowa.asp>.
<http://www.microsoft.com/technet/prodtechnol/exchange/exchange2000/
deploy/confeat/e2kowa.asp>.

1.1.3 Client Implementations from Simple to Rich

The HTTP/WebDAV feature model encourages a wide range of clients,
from extremely simple to very rich. This is because servers must
support a wide range of features, but clients can pick and choose
which features to support. For example, even though a WebDAV server
must support the 'lockdiscovery' property, there's no requirement for
a client to request or parse this property value 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 the error conditions which might be returned. A simple
client can merely download and upload iCalendar objects and use very
little XML or advanced WebDAV functionality.

At the other end of the scale, 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, by using more of the features and
possibly defining its own dead properties. (Note: WebDAV's 'dead'

Dusseault Expires January 16, 2005 [Page 3]

Internet-Draft caldav July 2004
properties are those which the server allows clients to set but the

Daboo, et al. Expires March 21, 2005 [Page 5]

Internet-Draft CalDAV September 2004

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

1.1.4 Support for lock feature

WebDAV includes locking support. Locks are indispensible indispensable when
multiple authors may modify or create the same resources. Locks not
only prevent authors from accidentally overwriting each others work
(as ETags do), they also help authors coordinate that work by seeing
when to wait for another author to finish. Calendar users benefit
slightly from this functionality, more so when group calendars or
shared calendars allow booking of large groups of people or
broadly-used resources such as conference rooms or equipment.

1.1.5 Support for access control

The WebDAV ACL specification [7] [11] 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 a
user for new appointments without having to make email requests, who
can view free/busy time, and who can see the details of certain
appointments.

WebDAV ACLs provide a flexible and extensible list of privileges,
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 WebDAV use cases (for
example, the privilege to view a calendar's free-busy information).
However the bad part is that a flexible and extensible list of
privileges is hard for clients to display and explain to users. This
draft attempts to minimize the difficulty by more closely defining
the list of privileges that a CalDAV server must support, including
calendaring-specific privileges.

Implementors should note that WebDAV ACLs are not designed to limit
access to specific properties. For example, a calendaring
application may wish to choose which other users can view the start/
end times of appointments, and separately choose which users can also
see the location 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 that
standard calendaring systems can be built using existing WebDAV ACL
support.

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 4] 6]

Internet-Draft caldav July CalDAV September 2004

1.1.6 Security, Implentations Implementations and Deployed Base

Many WebDAV client appliations, applications, servers and APIs already exist.
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 WebDAV servers all support TLS, providing at a
minimum single-hop privacy and server authentication. HTTP Digest
and Basic authentication may provide adequate client authentication
(Basic essentially uses a clear-text password but this may be
appropriate if the connection is secured 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
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 in
Calendaring systems. Luckily, these are already well understood for
HTTP/WebDAV technology. HTTP ETags provide a reliable way to
determine whether a document 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).
(http://www.xythos.com/home/xythos/wfc_features.html).

Many WebDAV working group members are discussing more work to improve
the performance of synchronization betweeen between WebDAV clients and WebDAV
repositories. This ongoing work can benefit the calendaring
community at the same time, provided that the calendaring data model
fits easily in the WebDAV data model. The model proposed in this
document is one with which new WebDAV synchronization features are
likley
likely to be equally applicable to calendaring data.

Data migration is almost the same problem as synchronization. One
use of a WebDAV tool like sitecopy is to move data to a new server.
The move is peformed performed by doing a new synchronization. Once the
initial synchronization is complete and verified, the data on the old
system can be removed or archived. Data portability is a convenient
feature to administrators, particularly when deploying a new system.

1.1.8 Search Support

Calendaring systems need a mix of fixed, specific searches (such as a

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 5] 7]

Internet-Draft caldav July CalDAV September 2004

"search" for the events occuring occurring today) and general search support.
WebDAV DASL [9] [13] can provide the functionality for the general search
support (although not always for specific frequently used searches).
The only hitch is that DASL is not yet standardized. The WebDAV WG
is currently putting effort into completing DASL and several
interoperable implementations already exist. In the meantime, if
DASL is delayed the specific fixed searches defined in this document
(using the REPORT method, see section 7), together with the ability
to browse calendars and request calendar objects with certain
property values, ought to provide quite reasonable calendar browse/
search support.

Note that the property promotion proposed in this document means that
not only can iCalendar documents be searched with "contains" text
searches, but also more sophisticated value matching can be done.
For example, since 'dtstart' is promoted from a VEVENT document body
to the resource's property list, a DASL search can be constructed to
find events with 'dtstart' before a specified date.

1.1.9 Clear extensibility model

WebDAV has a clear and proven extensibility model. The major way
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. However, 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 the
DASL extensions. Dead properties can also be used in reports.

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

1.2 Required Calendaring Features Missing in WebDAV

Certain

Daboo, et al. Expires March 21, 2005 [Page 8]

Internet-Draft CalDAV September 2004

2. Required CalDAV features that are required for modern enterprise-level
calendar systems are not present in HTTP or WebDAV, unsurprisingly.

This section makes clear lists what those missing functionality is required of a CalDAV server.
To advertise support for the 'calendar-access' features are. The rest of CalDAV, a
server:
o MUST support WebDAV Class 1 and 2 (all of RFC2518 [6] including
locking).
o MUST support WebDAV ACLs [11] with the privilege set defined in
Section 14.
o MUST support SSL.
o MUST support strong ETags to support disconnected operations.
o MUST support DASL [13].
o MUST support property promotion as described in this document is largely about how those missing document.
o MUST support calendaring REPORTs as described in this document.

To advertise support for the 'calendar-schedule' features could be
filled in.

Dusseault 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 and Originator
headers.

In addition, a server:
o MAY support WebDAV DeltaV [7] or some of its components.

Daboo, et al. Expires January 16, March 21, 2005 [Page 6] 9]

Internet-Draft caldav July CalDAV September 2004

Fanout: One of

3. CalDAV Support Discovery

If the valuable functions a calendaring server can
provide to a client is fanning out scheduling requests. This
allows clients to perform simple operations (send supports the calendar access features described in this
document it MUST include "calendar-access" as a single
schedule request to field in the server) and have DAV
response header from an OPTIONS request on any resource that supports
any calendar properties, reports, or privileges.

If the server perform
complex and possibly time consuming processing. The server can
send individual scheduling requests to different invitees. It can
choose supports the most appropriate calendar scheduling features described in
this document it MUST include "calendar-schedule" as a field in the
DAV response header from an OPTIONS request transport on any resource that
supports the SCHEDULE method.

3.1 Example: Using OPTIONS for each
invitee, not necessarily using the same technology Discovery of Support for each
invitee to 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

In this example, the OPTIONS response indicates that the same meeting. The server can then remain online to
collect
supports both calendar access and scheduling functionality and collate responses. Fanout is unlike any existing
WebDAV feature. Thus, support for fanout dictates that /
lisa/calendar/outbox/ can be specified as a Request-URI to the
SCHEDULE method.

Daboo, et al. Expires March 21, 2005 [Page 10]

Internet-Draft CalDAV September 2004

4. Calendaring server cannot simply be an out-of-the-box Data Model

One of the features which has made WebDAV
server with no modifications. A CalDav server must have fanout
logic in addition to a successful protocol is
its basic WebDAV feature support. firm data model. This
document defines how fanout works.
Recurrance: Recurring appointments are common in calendaring
applications, and these are the hardest events to fit into makes it a
finite resource listing model useful framework for other
applications such as WebDAV. However, WebDAV
does have the functionality calendaring. In this proposal, we attempt to perform reports. Recurrance
expansion is much like
follow the expand-property report defined in
DeltaV [4]. CalDAV defines a same pattern by developing all new report type specifically for
expanding recurrances.
Notifications: HTTP has no way for the server to contact features based on a
well-described data model.

In the client.
HTTP interactions all begin with CalDAV data model, every iCalendar VEVENT, VJOURNAL, VTODO and
VFREEBUSY is stored as a client request regular HTTP/WebDAV resource. That means
each calendar resource may be individually locked and end have individual
properties. These resources are sorted into WebDAV collections with
a
server response. The server has no obligation to maintain an open
connection to the client, rather the server MAY sever the TCP
connection after any response. Thus, there mostly-fixed structure.

4.1 Calendar Repository or Server

A CalDav repository, or server, is no way for a calendaring-aware engine
combined with a WebDAV repository. A WebDAV repository is a set of
WebDAV collections, containing other WebDAV resources, within a
unified URL namespace. For example, the
server to send repository
"http://example.org/webdav/" may contain WebDAV collections and
resources, all of which have URLs beginning with
"http://example.org/webdav/". Note that the client alarms. Since HTTP is root URL
"http://example.org/" may not designed for
this, it itself be a WebDAV repository (for
example, if the WebDAV support is recommended that implemented through a different technology be used to
solve this problem.
There are servlet or
other IETF technologies much more suitable than HTTP to
provide notifications. Currently, SIP Web server extension).

A WebDAV repository may include calendar data in some areas, and XMPP are appropriate
technologies for servers to send notifications to subscribed
clients. The SIP SUBSCRIBE method defined
non-calendaring data in RFC3265 [5] allows
custom event types to other areas. Calendar data will be declared and subscribed to, indicated
through specific container relationships and CalDAV
(or a separate draft) could define a list of resource types that CalDAV
servers could optionally (or be required to) support. Similarly,
XMPP allows clients to subscribe to events other than presence
state change events.
Using a separate technology for notifications has advantages. It
can be seen discussed
in the next sections.

A WebDAV repository may advertise itself as an advantage to have notification support optional,
at least for client implementations - a simple CalDav client need
not support notifications at all CalDAV server if it doesn't use alarms, or
generates its own alarms, or stays offline most of
supports the time.
Another advantage is that it allows CalDAV servers to be
stateless, handling HTTP requests by generating responses, plus
events that can be fired off to a separate notification engine
(perhaps a separate server) and then forgotten. Finally, a

Dusseault Expires January 16, 2005 [Page 7]

Internet-Draft caldav July 2004

separate notification system can then deal with scaling to handle functionality defined in this specification at any point
within the combinatorial problems root of multiple subscribed clients (e.g.
my PDA, my laptop the repository. That might mean that calendaring
data is spread throughout the repository and my desktop) combined mixed with multiple event
sources non-calendar
data in nearby collections (e.g. my work calendar server plus my sports team calendar server plus non-calendaring event sources).
It is likely data may be found in /
lisa/calendar/ as well as in /nborenstein/calendar/, and non-calenadr
data in /lisa/contacts/). Or, it might mean that CalDAV servers will calendar data can
be required to support
notification once we have more input on which technology to use.
At found only in certain sections of the least, repository (e.g. /caldav/
usercals/*). Calendaring features are only required in the server would support notification of new
resources added to collections, so
repository sections that clients can subscribe to
know when new iTIP requests have been delivered or when other
clients have added new events are or other contain calendaring objects. A
CalDAV server might also initiate notification when a reminder is
needed. This could allow simple non-calendaring clients (e.g. So a
cell phone)
repository confining calendar data to subscribe the /caldav/ collection would
only need to reminder event notifications
without having to do any other part of calendaring.

Dusseault support calendaring REPORTs defined here within that
collection.

The CalDAV server or repository is the canonical location for
calendar data, state information and semantics. The CalDAV server

Daboo, et al. Expires January 16, March 21, 2005 [Page 8] 11]

Internet-Draft caldav July 2004

2. Required CalDAV features

This section lists what functionality September 2004

has significant responsibility to ensure that the data is required of a CalDAV server.
To advertise support for CalDAV consistent
and compliant. Clients may submit requests to change data or claim compliance, a server:
o MUST support WebDAV Level 1
download data. Clients may store the calendar offline and 2 (all of RFC2518 [3] including
locking).
o MUST support WebDAV ACLs [7] with attempt to
synchronize when reconnected, but changes to the privilege set defined in
Section 7.
o MAY support WebDAV DeltaV [4].
o MUST support DASL [9].
o MUST support SSL.
o MUST support property promotion as described in this document.
o MUST support scheduling fanout as described in this document.
o MUST support calendaring REPORTs as described repository occurring
in between are not considered to be automatically disposable and
clients should consider the repository to be the first authority on
state. HTTP Etags and other tools help this document.

Dusseault Expires January 16, 2005 [Page 9]

Internet-Draft caldav July 2004

3. Calendaring work.

4.2 Recurrence and the Data Model

One

Recurrence is an important part of the features which has made WebDAV a successful protocol is
its firm data model. This makes model because it a useful framework for other
applications such as calendaring. In governs
how many resources are expected to exist.

Consider the outcome if recurrence were handled through the creation
of many nearly-identical WebDAV resources. With this proposal, we attempt model, it
becomes hard to
follow keep their data consistent. Even worse, some
features like LOCK become difficult -- it's hard to lock the same pattern by developing right
set of resources so that the user can change the title of all new features based on a
well-described data model.

In
recurrences of an appointment. With these considerations, this data model, every iCalendar VEVENT, VALARM, VJOURNAL, VTODO
and VFREEBUSY is stored
proposal does not treat recurrences as a regular HTTP/WebDAV resource. That
means each calendar resource may be individually locked and have
individual properties. These resources are sorted into WebDAV
collections with a mostly-fixed structure.

All resource types defined in this section, and all resources of MIME
type text/calendar appearing within these collections, have certain
required properties. These properties may be defined in this
document or in a separate document. Another TODO: This section needs
more information on what resources.

Instead, this proposal models recurrence patterns as properties are REQUIRED on each type of
collection. The iTIP document has useful tables listing properties
event resources. This makes for each method, which might apply much less data to these collections.

3.1 Calendar Repository or Server

A CalDav repository, synchronize, and
makes it easier to make changes to all recurrences or server, is a calendaring-aware engine
combined with a WebDAV repository. A WebDAV repository is to a set of
WebDAV collections, containing other WebDAV resources, within recurrence
pattern. It makes it easier to create a
unified URL namespace. For example, the repository "http://
example.org/webdav/" may contain WebDAV collections recurring event, and resources, easier
to delete all recurrences.

The drawback of which have URLs beginning with "http://example.org/webdav/".
Note that the root URL "http://example.org/" may not itself be a
WebDAV repository (for example, if the WebDAV support recurrence-is-a-property approach is implemented
through that it
becomes harder to see what events occur in a servlet or other Web server extension).

A WebDAV repository may include given time period. It's
a very common function for calendar data in some areas, and
non-calendaring data in other areas. Calendar data will be indicated
through specific container relationships views to display all events
happening between midnight yesterday and resource types discussed
in the next sections.

A WebDAV repository may advertise itself midnight tonight, or all
events happening within one week. In these views, each recurrence
appears as a CalDAV server if it
supports the functionality defined in were an individual appointment. To make these views
possible, this specification at any point
within the root proposal defines a REPORT specifically to view events
in a time period [TODO - ref section].

Because of this choice, clients MUST NOT create separate resources to
represent a recurring event when the repository. That might mean that calendaring
data recurrence pattern is spread throughout known.
Otherwise, it makes it more difficult for other clients to
interoperate and modify the repository (e.g. in /ldusseault/
calendar as well recurring event. Most importantly,
clients MUST NOT duplicate events represented through recurrence
patterns with manually created events, which would appear as in /nborenstein/calendar) or only in certain
sections of the repository (e.g. /caldav/usercals/*). Calendaring
features are only required in
duplicates to the repository sections that server and to other clients.

4.3 CalDAV and timezones

VTIMEZONE components are or
contain calendaring objects. So primarily used within other iCalendar
components, when a repository confining calendar data recurrance rule needs to specify what timezone the /caldav/ collection would only need to support calendaring

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 10] 12]

Internet-Draft caldav July 2004

REPORTs defined here within that collection.

The CalDAV server or repository is the canonical location for
calendar data, state information and semantics. The September 2004

recurrance occurs in. Since CalDAV server
has significant responsibility to ensure contains iCalendar components
that the data is consistent
and compliant. Clients may submit requests to change data or
download data. Clients contain recurrances, of course those recurrances may store the calendar offline and attempt contain
VTIMEZONEs. This makes it a little harder for servers to
synchronize when reconnected, expand
recurrances, but changes to the repository occurring
in between are not considered otherwise CalDAV servers have little to be automatically disposable and
clients should consider the repository do with
VTIMEZONE components. There is no place to be the first authority store VTIMEZONE
components on
state. HTTP Etags and other tools help this work.

Dusseault Expires January 16, 2005 [Page 11]

Internet-Draft caldav July 2004

4. New Resource Types

CalDAV defines the following new resource types for use their own, either in a user's calendar
repositories.

4.1 Calendar Containers

A WebDAV collection which contains one or more calendars is
considered in a Calendar Container. It has central
location.

4.4 Scheduling, Fanout and the Data model

One of the key workflows in calendaring and scheduling is when a new resource type:

A calendar container may contain more than only Calendar resources.
However, non-Calendar resources within
meeting organizer creates an invitation and sends it to a Calendar-Container are not
typically intended for user display. These resources may contain
configuration or application data created by clients or offered by number of
attendees. Each of those attendees wants the server for use by clients.

4.2 Calendars

A WebDAV collection which corresponds event to a single appear on
their own calendar or VAGENDA (if they accept it) and have their status
reflected back to the organizer. This section is a Calendar. It has a new resource type:

The calendar collection contains sub-collections with specific kinds brief overview of calendar objects. It also has certain properties which are
required
how this workflow relates to be the data model of CalDAV, which only
applies if the server supports the 'calendar-schedule' set of
features.

An invitation is not yet an accepted event. Thus, invitations should
appear outside the main part of the calendar, and not be included in
free-busy rollup or calendar REPORT requests. To handle this in the
data model, CalDAV defines an iTIP Inbox collection to contain
incoming invitations. Similarly, 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 as 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 clients and to support
delegation use cases. CalDAV defines an iTIP Outbox collection to
contain outbound invitations and other iTIP methods. A single user
with multiple clients can use this collection to synchronize the
outbound request history. Two users coordinating scheduling with one
calendar (e.g. a calendar user and her assistant) can see what
scheduling messages the other user has sent. (The calendar owner
would then typically have permission to DELETE the scheduling
messages but the assistant need not.)

Thus, for every scheduling request, we would like to see one copy in
the organizer's iTIP Outbox, as well as one copy in each attendee's
iTIP Inbox. Rather than require that many PUT requests, CalDAV
defines the SCHEDULE method to request that the server place a copy
of an iTIP message in a given iTIP Outbox, and do its best to fan out
the iTIP message to the recipients' iTIP Inboxes.

The server may support fanout to other domains, and the client may

Daboo, et al. Expires March 21, 2005 [Page 13]

Internet-Draft CalDAV September 2004

attempt to get the server to do this by specifying remote addresses
for the fanout recipients, but the server is not bound to support or
complete remote fanout operations even if it advertises support for
'calendar-schedule' features. Note 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 is completed, CalDAV clients will see the iTIP
messages the next time they synchronize or query the iTIP Inbox
collection. To reply to an iTIP invitation, the client uses the
SCHEDULE method to send another iTIP message (this time, a reply).
If the user has decided to accept the invitation, the client also
uses PUT (or some other method) to create a VEVENT resource (text/
calendar) in the appropriate calendar, and with the appropriate
details. Typically, the step of putting the event in the calendar is
left up to the client, so that the client can make appropriate
choices about where to put the event, and with what alarms, etc.
However, the server MAY be configured (how is not defined here) to
auto-accept or auto-reject invitations, and if the server
auto-accepts invitations then the server is responsible for creating
VEVENT resources in the user's calendar.

Daboo, et al. Expires March 21, 2005 [Page 14]

Internet-Draft CalDAV September 2004

5. New Resource Types

CalDAV defines the following new resource types for use in calendar
repositories.

LMDTODO: This section needs more information on what properties are
REQUIRED on each type of collection. The iTIP document has useful
tables listing properties for each method, which might apply to these
collections.

5.1 Calendar Container Collection

A WebDAV collection which contains one or more calendars is
considered a Calendar Container. The purpose of the Calendar
Container resource is so that the client can identify a container
resource which supports the calendar-time-ranges REPORT, besides
calendars themselves. A calendar container has a new resource type:

A calendar container may contain more than only Calendar resources.
However, non-Calendar resources within a Calendar-Container are not
typically intended for user display. These resources may contain
configuration or application data created by clients or offered by
the server for use by clients.

5.2 Calendars Collection

A WebDAV collection which corresponds to a single calendar or VAGENDA
is a Calendar. It has a new resource type:

The calendar collection contains sub-collections with specific kinds
of calendar objects. It also has certain properties which are
required to be present on calendards (see XML section).

Calendars calendards (see XML section).

Calendars MUST NOT contain other calendars. Calendars MAY exist
inside calendar-containers or inside normal WebDAV collections.
Thus, a repository may have calendars without having
calendar-containers. Calendar-containers are typically useful so
that a client can automatically detect when a user has multiple

Daboo, et al. Expires March 21, 2005 [Page 15]

Internet-Draft CalDAV September 2004

calendars, e.g. "/lisa/calendars/work" and "/lisa/calendars/karate".

A Calendar has a specified substructure. It MUST contain one event
collection and one alarm collection. It MAY contain one todo
collection and one journal. It MUST NOT contain more than one of any
of these specific collections, although it MAY contain additional
collections and non-collection resources of types not defined here.

5.3 Event Collection

Each Calendar MUST have a collection containing events. All
resources within this event collection (even within its
sub-collections) are considered part of the calendar, so substructure
can be used to organize events into smaller collections without
affecting the overall content of the calendar. Clients MUST be
prepared to identify and navigate multiple event collections within a
Calendar. An event collection has its own resource type so these
collections are easily identifiable.

Every non-collection resource in a calendar-events collection is
considered to be an event. Thus, listing the resources inside a
calendar-events collection is a good way to find out all the events
on a calendar. Each resource inside an events collection MUST have
the default MIME type text/calendar, and each one contains exactly
one VEVENT or VFREEBUSY object.

5.4 Todo Collection

Each Calendar MAY have a collection containing tasks or todos. All
resources within this todo collection (even within its
sub-collections) are considered part of the calendar. The todo
collection has its own resource type.

Every non-collection resource in a todo collection is considered to
be a todo. Every resource MUST have the default MIME type text/
calendar, and contains exactly one VTODO.

Daboo, et al. Expires March 21, 2005 [Page 16]

Internet-Draft CalDAV September 2004

5.5 Journal Collection

Each Calendar MAY have a collection containing journal items. All
resources within this journal collection (even within its
sub-collections) are considered part of the journal. The journal
collection has its own resource type.

Every non-collection resource in a journal is considered to be a
journal item. Every resource MUST NOT contain other calendars. Calendars MAY exist
inside calendar-containers or inside normal WebDAV collections.
Thus, have the default MIME type text/
calendar, and contains exactly one VJOURNAL.

5.6 iTIP Inbox Collection

On a repository may server supporting 'calendar-schedule' features, every
Calendar-Container MUST have calendars without having
calendar-containers. Calendar-containers are typically useful so
that an iTIP Inbox collection to contain
incoming iTIP messages. If a client can automatically detect when Calendar is not inside a user has multiple
calendars, e.g. "/ldusseault/calendars/work" and "/ldusseault/
calendars/karate".

A
Calendar-Container, then that Calendar has MUST have its own iTIP Inbox
collection.

Every non-collection resource in the iTIP Inbox collection is
considered to be an iTIP message. Every resource MUST have the media
type text/calendar, and contain the iCalendar METHOD property.

5.7 iTIP Outbox Collection

On a specified substructure. It server supporting 'calendar-schedule' features, every Calendar
MUST have a child collection to contain one event fanout requests and responses
for appointments scheduled by the calendar owner (or other users of
this calendar). This collection is to store REQUESTs initiated by
this calendar server for this calendar, as well as REPLY items
received in reply. This collection is only for review because the
CalDAV server is responsible for parsing incoming REPLY messages and one alarm collection. It MAY contain one todo
adding attendee information to events.

Daboo, et al. Expires March 21, 2005 [Page 17]

Internet-Draft CalDAV September 2004

Every non-collection resource in the scheduling collection is
considered to be a REQUEST or REPLY. Every resource MUST have the
default MIME type text/calendar, and contains exactly one journal. It MUST NOT contain more than 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 any of these specific collections, although it
the iTIP message in that iTIP outbox. This then serves as a record
of outgoing scheduling messages.

The server MAY contain additional
collections and non-collection auto-delete messages in the outbox after a suitably
long period or to keep within a quota. The server SHOULD allow the
calendar owner to DELETE resources of types not defined here.

Dusseault in the outbox.

Daboo, et al. Expires January 16, March 21, 2005 [Page 12] 18]

Internet-Draft caldav July CalDAV September 2004

4.3 Event Collection

Each Calendar

6. Creating Resources

Calendars, calendar-containers, collections of calendar objects, and
individual calendar objects may all be created by either the CalDAV
client or by the CalDAV server. For example, a server might come
preconfigured with a user's calendar collection, or the CalDAV client
might create a new calendar collection. Servers might create event
requests as calendar objects inside a VEVENT collection, or clients
might create event requests. Either way, both client and server MUST have
comply with the requirements in this document, and MUST understand
objects appearing in calendars or calendar-containers according to
the data model defined here.

When servers create HTTP resources, it's not hard for the server to
choose a collection containing events. All unique URL. It's slightly tougher for clients, because a
client might not want to examine all resources within this event in the collection, and
might not want to lock the entire collection (even within its
sub-collections) to ensure that a new one
isn't created with a name collision. However, there are considered part of the calendar, so substructure
can be used tools to organize events into smaller collections without
affecting the overall content of
mitigate this. If the calendar. Clients MUST be
prepared client intends to identify and navigate multiple event collections within create a
Calendar. An event collection has its own resource type so these
collections are easily identifiable.

Every new non-collection resource in
resource, such as a calendar-events collection new VEVENT, the client SHOULD use the HTTP header
"If-None-Match: *" on the PUT request. The Request-URI on the PUT
request MUST include the target collection, where the resource is
considered to
be an event. Thus, listing created, plus the resources inside name of the resource in the last path segment.
The last path segment could be a
calendar-events collection is random number, or it could be a good way
sequence number, or a string related to find out all the events
on object's 'summary'
property. No matter how the name is chosen, the "If-None-Match"
header ensures that the client cannot overwrite an existing resource
even if it has accidentally chosen a calendar. Each duplicate resource inside name.

PUT /lisa/calendar/events/mtg10028.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

The request to change an events collection MUST have existing event is the default MIME type text/calendar, and each one contains exactly
one VEVENT or VFREEBUSY object.

4.4 Alarm Collection

Each Calendar same, but with a
specific ETag in the "If-Match" header, rather than the

Daboo, et al. Expires March 21, 2005 [Page 19]

Internet-Draft CalDAV September 2004

"If-None-Match" header.

For optimum interoperability with existing HTTP clients, CalDAV
clients and servers MUST have a collection containing alarms. All
resources within this alarm collection (even within its
sub-collections) are considered part of use the calendar. The alarm
collection has its own resource file extension ".ics" as well as the
"text/calendar" MIME type, whenever creating Calendar objects of that
MIME type.

Every non-collection resource

Note because of these requirements that there is no semantic value in
any other part of a alarms collection is considered to
be an alarm. Every resource MUST have name other the default MIME type text/
calendar, and contains exactly one VALARM.

4.5 Todo Collection

Each Calendar MAY have file extension. Thus, a
Calendar collection containing tasks may be called "calendar", "cal", "Calendario" or todos. All
resources within this todo collection (even within its
sub-collections) are considered part
"日历" (Chinese). It's the properties of the calendar. The todo
collection has its own resource type.

Dusseault that define
what it is, not the name.

Daboo, et al. Expires January 16, March 21, 2005 [Page 13] 20]

Internet-Draft caldav July CalDAV September 2004

<C:todos xmlns:C="urn:ietf:params:xml:ns:calsch">
</resourcetype>

Every non-collection

7. Users and Groups

The WebDAV ACL specification requires that any principal to whom
permissions can be represented via a WebDAV resource (complete with
WebDAV properties and a HTTP URL). 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 framework for linking users to calendars in a todo collection fashion not
otherwise easily implemented.

Note that the WebDAV principal resources may not be modifiable
through WebDAV. This is considered an important consideration because it allows
the principal directory to be merely a WebDAV representation 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 a todo. Every resource MUST have linked into the default MIME type text/
calendar, and contains exactly one VTODO.

4.6 Journal

Each Calendar MAY have a collection containing journal items. All
WebDAV repository through configuration information. WebDAV server
implementations exist which offer principal resources, but when the
principal resources within this journal collection (even within its
sub-collections) are considered part of queried the journal. The journal
collection has its own resource type.

Every non-collection resource in server actually makes a journal is considered LDAP
request to be a
journal item. Every resource MUST have get the default MIME type text/
calendar, and contains exactly one VJOURNAL.

4.7 Invites Collection

Every Calendar-Container MUST have a child collection principal information from its official source.
This saves WebDAV clients from having to contain
invites received through iTIP. If implement LDAP and provides
a Calendar single URL format for principals regardless of whether the user
directory is not inside a
Calendar-Container, then that Calendar stored in LDAP or some other system.

A server supporting CalDAV MUST have its own invites
collection. This collection is support additional properties on
principal resources if these principals are associated with
calendars. In addition, certain properties are required on calendars
to store received, accepted link to principal resources. These properties are defined in the
properties section.

Daboo, et al. Expires March 21, 2005 [Page 21]

Internet-Draft CalDAV September 2004

8. Property Promotion and
archived invitations so Demotion

Property promotion and demotion (hereafter called simply "property
promotion") is the name for the functionality by which a server
ensures that clients can accept a resource's internal data and review scheduling
invitations.

Every non-collection resource in the invites its externally-visible
metadata remain consistent. In WebDAV, a collection is considered
to be listing
(PROPFIND) selects a REQUEST. Every resource MUST have the default MIME type
text/calendar, and contains exactly one REQUEST.

4.8 Scheduling Collection

Every Calendar MUST have set of property names to retrieve. For a child
collection listing to contain fanout
requests be useful to browse calendars, certain
calendaring information must be exposed as WebDAV properties (this
also makes WebDAV SEARCH useful, and responses for appointments scheduled by makes the definition of REPORTs
easier). Since a calendar
owner (or other users resource of this calendar). This collection is type text/calendar has
properties which duplicate some of its internal state, it's the
server's responsibility to store
REQUESTs initiated by this calendar keep those consistent somehow.

The server for this calendar, has some leeway in how it makes properties and bodies
consistent, as well long as REPLY items received the response to a GET shows information
consistent with the response to a PROPFIND in reply. This collection the interval in which a
calendar object has not been altered. Thus, the server MAY change
property values when a PUT is only for review

Dusseault Expires January 16, 2005 [Page 14]

Internet-Draft caldav July 2004

because performed that alters data exposed as
properties, and also change the CalDAV body when a PROPPATCH is performed
that alters calendar properties. Alternatively, a server could
implement "lazy promotion" and apply consistency changes only when a
GET, PROPFIND, SEARCH or REPORT is responsible for parsing incoming REPLY
messages issued. Finally, a server might
decompose property data and adding attendee non-property data into separate locations
and recompose the information only when a GET requests the entire
resource. Any of these approaches MUST be transparent to events.

Every non-collection resource the client,
in that operations behave consistently, with complete round-trip
fidelity of all the invites collection is considered
to be data originally provided. Thus, a REQUEST or REPLY. Every server MAY
canonicalize its resource bodies (e.g. eliminate meaningless spaces)
but MUST have the default MIME
type text/calendar, and contains exactly one REQUEST preserve all data.

Not all properties need to be promoted, only those properties most
useful for clients to do property value searching or exactly one
REPLY.

4.9 Recurrance and the Data Model

Recurrance is an important part listings of the data model because it governs
how many resources are expected to exist.

Consider the outcome if recurrance were handled
calendar events either through PROPFIND or through the creation
of many nearly-identical WebDAV resources. With this model, it
becomes hard to keep their data consistent. Even worse, some
features like LOCK become difficult -- it's hard to lock recurrence
report. All unrecognized properties can be left in the right
set of resources 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 that 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

Daboo, et al. Expires March 21, 2005 [Page 22]

Internet-Draft CalDAV September 2004

9. Scheduling and Fanout

Scheduling and fanout is a valuable function provided by advanced
calendaring servers. Simple clients clearly benefit from having the user can change
logic handled by the title of all
recurrances of an appointment. With these considerations, this
proposal does not treat recurrances as separate resources.

Instead, this proposal models recurrance patterns as properties of
event resources. This makes for much server. Rich clients also benefit from having
to upload less data to synchronize, and
makes it easier to make changes to all recurrances or to a recurrance
pattern. It makes it easier various servers (including messaging servers
to create a recurring event, and easier send invitations via messages) to delete all recurrances.

The drawback of accomplish the recurrance-is-a-property approach is that it
becomes harder to see what events occur in a given time period. It's
a very common function same things.
Servers can sometimes provide more advanced scheduling functionality
than clients - for calendar views to display all events
happening between midnight yesterday and midnight tonight, or all
events happening within one week. In these views, each recurrance
appears as if it were an individual appointment. To make these views
possible, this proposal defines a REPORT specifically to view events
in example, a time period [TODO - ref section].

Because of this choice, clients MUST NOT server providing fanout could create separate
"unconfirmed" VEVENT resources within invitees' calendars.

However, rich calendaring clients may prefer to
represent do fanout. Clients
can perform special functionality during scheduling (for example, a recurring event when the recurrance pattern is known.
Otherwise, it makes
client may be configured to be able to directly put events on others'
calendars if the user has sufficient permissions). Thus, it more difficult for other clients is
proposed that CalDAV allow the client to
interoperate either perform fanout and modify
merely create the recurring event. Most importantly,
clients MUST NOT duplicate events represented through recurrance
patterns event (complete with manually created events, which would appear as
duplicates to attendee information) OR
request that the server and to perform fanout. In other clients.

Dusseault Expires January 16, 2005 [Page 15]

Internet-Draft caldav July 2004

4.10 Calendar, event words, the server
MUST handle fanout if requested, and custom timezones

This is a big issue because clients MAY perform fanout if
the client chooses.

CalDAV servers need to know the timezone
of that return the calendar value "calendar-schedule" in order the DAV
response header MUST support iTIP to calculate recurrances in a deterministic
manner. In addition send and receive scheduling
requests as well as reply to having a calendar default timezone,
individual events (e.g. those received in a scheduling request from
another place) can request. Outgoing iTIP
messages MUST be submitted to an iTIP Outbox collection. Incoming
iTIP messages MUST be delivered to an iTIP Inbox collection.

TODO: We need to clarify if outgoing iTIP messages that have different timezones. Finally, iCalendar has
a way not yet
been delivered to specify custom timezones.

The default all specified calendars should be accessible as
calendar timezone is probably simply resources in the iTIP Outbox collection.

Incoming iTIP messages will remain in the iTIP Inbox collection until
a property value on client deletes them. CalDAV servers MUST parse incoming REPLY
messages and update the calendar collection, which appropriate event with attendee information.
Thus, it's not necessary for clients to review REPLY messages,
although they may.

When a CalDAV server delivers an iTIP message, it MUST store the
object in an iTIP Inbox collection for the calendaring client can change.
The event timezone is a piece to handle. Each
recipient of VEVENT metadata that would therefore
appear both inside the event in iCalendar format, message will have properties indicating whether it
is new, has been accepted, has been rejected, and as a promoted
property on the whether it is an
obsolete REQUEST (the event resource. Storing custom timezone definitions
can be through has passed). Note that when a new collection if necessary. More discussion here calendar
server receives iTIP messages it MAY auto-accept based on user
configured preferences. How these preferences are configured is welcome.

Dusseault Expires January 16, 2005 [Page 16]

Internet-Draft caldav July 2004

5. Creating Resources

Calendars, calendar-containers, collections out
of calendar objects, and
individual calendar objects may all be created by either the scope of this specification, but one could imagine that a
CalDAV
client or by the server could host auto-accept configuration Web pages. A
CalDAV server. For example, a server might come
preconfigured with a user's calendar collection, or is NOT REQUIRED to do any auto-accepting, it MAY simply
store the CalDAV client
might create a new calendar collection. Servers might create event requests as calendar objects inside a VEVENT collection, or clients
might create event requests. Either way, both client and server MUST
comply with for the requirements in this document, and MUST understand
objects appearing in calendars or calendar-containers according to next time the data model defined here.

When servers create HTTP resources, it's not hard client is online.

Daboo, et al. Expires March 21, 2005 [Page 23]

Internet-Draft CalDAV September 2004

Exact mechanisms for triggering fanout requests must be determined
and input is welcome. There are several ways fanout could be
accomplished: (a) A PUT of the server to
choose resource triggers fanout, so the body
must contain the fanout information (text and flags), (b) a unique URL. It's slightly tougher for clients, because PROPPATCH
triggers fanout if certain properties are set, (c) a
client might not want to examine all resources in new method
requests fanout of a resource that has already been uploaded. These
three approaches are the collection, most obvious to this author and
might not want there is
surprisingly little to lock choose between. More input is needed, for
example input on whether the entire collection to ensure fanout should be synchronous or
asynchronous. An asynchronous fanout mechanism using PUT or
PROPPATCH would mean that the client would synchronously handle the
PUT or PROPPATCH itself, but send invitations at some later time. A
synchronous fanout mechanism would probably use a new one
isn't created method with a
name collision. However, there are tools like SCHEDULE, because adding new synchronous behavior to
mitigate this. If
existing methods might require more complicated server implementation
work.

When the client intends to create a new non-collection
resource, such server does fanout, it may send requests and receive
replies. Probably these requests and responses should be stored as a new VEVENT,
WebDAV resources so that the client SHOULD use can examine the HTTP header
"If-None-Match: *" on details if
desired. This could be a separate collection within the PUT request. The Request-URI on calendar
collection.

To achieve these goals, this section specifies a WebDAV binding for
the PUT
request MUST include iCalendar Transport-independent Interoperability Protocol (iTIP
[4]). It provides the target collection, where necessary information to convey iTIP over
WebDAV.

9.1 SCHEDULE Method for WebDAV

The SCHEDULE method submits an iTIP message specified in the resource is request
body to
be created, plus the name location specified by the Request-URI. The request body
of a SCHEDULE method MUST contain an iCalendar object that obey the resource
restrictions specified in the last path segment. iTIP [4]. The last path segment could resource identified by the
Request-URI MUST be a random number, or it could resource collection of type "itip-outbox"
(Section 5.7).

The submitted iTIP message will be a
sequence number, or a string related delivered to the object's 'summary'
property. No matter how calendar
addresses specified in the name is chosen, Recipient header.

The calendar address of the "If-None-Match"
header ensures that originator of the client cannot overwrite an existing resource
even if it has accidentally chosen iTIP message MUST be
specified in the Originator header. This calendar address MUST
identify a duplicate resource name.

PUT /lisa/calendar/events/mtg10028.ics HTTP/1.1
If-None-Match: *
Host: cal.example.com
Content-Type: text/icalendar
Content-Length: XXX

BEGIN:VEVENT
DTSTART:20010714T170000Z
DTEND:20010715T035959Z
SUMMARY:Bastille Day Party
END:VEVENT

The request to change an existing event collection of type "itip-inbox" (Section 5.6).
that is owned by the same, but with a
specific ETag in currently authenticated user.

The calendar address of the "If-Match" header, rather than recipient(s) of the
"If-None-Match" header.

For optimum interoperability with existing HTTP clients, CalDAV
clients and servers iTIP message MUST use the file extension ".ics" as well as be
specified in the
"text/ icalendar" MIME type, whenever creating Calendar objects of

Dusseault Recipient header. There MUST be at least one
Recipient per SCHEDULE request.

Daboo, et al. Expires January 16, March 21, 2005 [Page 17] 24]

Internet-Draft caldav July CalDAV September 2004

that MIME type.

Note because

The body of these requirements that there the SCHEDULE request is no semantic value in
any other part of a resource name other complete iCalendar component
(content type text/calendar), and MUST have an iTIP method. The list
of attendees and the file extension. Thus, a
Calendar collection may be called "calendar", "cal", "Calendario" or
"日历" (Chinese). It's organizer information in this request body might
well be redundant with the properties values of the resource Recipient and Originator
headers. This is intentional, so that define
what it is, not the name.

Dusseault Expires January 16, 2005 [Page 18]

Internet-Draft caldav July 2004

6. Users client can have more
control over who receives invitations and Groups who sends them:
o The WebDAV ACL specification requires that any principal client may send invitations to whom
permissions can be represented via a WebDAV resource (complete with
WebDAV properties and a HTTP URL). Thus, both calendar users may be
represented (for example, as /principals/users/ldusseault) and groups not on the
attendee list (for example, as /principals/groups/calsch). This feature offers an
excellent framework for linking users to calendars in a fashion an assistant, caterer, observer,
etc).
o The client may choose not
otherwise easily implemented.

Note that to send invitations to calendar users
who are on the WebDAV principal resources attendee list (for example, attendees who have been
scheduled through an out-of-band mechanism).
o The originator may not be modifiable
through WebDAV. This is different than the organizer, for example an important consideration because it allows
assistant who has calendar-bind privileges on the principal directory organizer's
calendar.

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

The following are examples of response codes one would expect to be merely
used in a WebDAV representation of data
which is canonically stored 207 (Multi-Status) response for this method. Note,
however, that unless explicitly prohibited any 2/3/4/5xx series
response code may be used in an outside system. For example, an
enterprise might use an LDAP server to store and administer all user
and group properties. This LDAP a 207 (Multi-Status) response.

200 (OK) - The command succeeded.

202 (Accepted) - The request was accepted, but the server could be linked into 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 the
WebDAV repository through configuration information. WebDAV server
implementations exist which offer principal resources, but when chooses not to
specify, cannot submit an iTIP message to the
principal resources are queried specified Request-URI.

404 (Not Found) - The URL in the server actually makes Request-URI, the Originator, or the
Recipient headers could not be found.

423 (Locked) - The specified resource is locked and the client either
is not a LDAP
request to get lock owner or the principal information from its official source.
This saves WebDAV clients from having lock type requires a lock token to implement LDAP be
submitted and provides the client did not submit it.

502 (Bad Gateway) - The Recipient header contained a single URL format for principals regardless of whether which the user
directory is stored in LDAP or some other system.

A
server supporting CalDAV MUST support additional properties on
principal resources if these principals are associated with
calendars. In addition, certain properties are required on calendars
to link considers to principal resources. These properties are defined be in another domain, which it cannot forward
iTIP messages to.

507 (Insufficient Storage) - The server did not have sufficient space
to record the
properties section.

Dusseault iTIP message.

Daboo, et al. Expires January 16, March 21, 2005 [Page 19] 25]

Internet-Draft caldav July 2004

7. Calendaring Privileges

A CalDAV server MUST support the WebDAV ACLs standard [7]. That
standard provides a framework for an extensible list of privileges on
WebDAV collections and ordinary resources. A September 2004

9.1.2 Example - Simple appointment invitation

>> Request <<

SCHEDULE /lisa/calendar/outbox/ 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/
Content-Type: text/calendar
Content-Length: xxx

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

Daboo, et al. Expires March 21, 2005 [Page 26]

Internet-Draft CalDAV server MUST also
support the set of calendar-specific privileges defined in this
section.

7.1 Free-busy Viewing Privilege

Calendar users often wish to allow other users to see their free-busy
times, without viewing the other details of September 2004

>> Response <<

HTTP/1.1 207 Multi-Status
Date: Thu, 02 Sep 2004 16:53:32 GMT
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://cal.example.com/bernard/inbox/</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://cal.example.com/cyrus/inbox/</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

In this example, the calendar events
(location, subject, attendees). This allows a significant amount of
privacy while still allowing those other users to schedule meetings
at times when client requests the calendar owner is likely server to be free.

The view-free-busy privilege deliver an
appointment invitation (iTIP REQUEST) in the "urn:ietf:params:xml:ns:calsch"
namespace controls access to view the start times Bernard's and end times Cyrus's iTIP
Inbox collections.

9.2 Retrieving incoming iTIP Messages

Incoming iTIP messages will be stored in resource collection of
free and busy blocks type
"itip-inbox". The originator 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 to those events
would show up as free iTIP message will be specified
in the free-busy rollup Originator response header. The same rules for property
promotion apply to an unauthorized
viewer), but incoming iTIP messages, so a server MAY forbid the free-busy privilege from being
used on individual events or event containers. A CalDAV server MUST
support client can also use
PROPFIND and REPORT to get some of the free-busy privilege most important information on a Calendar collection.

<!ELEMENT view-free-busy EMPTY>

The view-free-busy privilege is aggregated
iTIP messages in the standard WebDAV
'read' privilege. Clients can discover support for various
privileges using the 'DAV:supported-privilege-set' property defined
in RFC2518 [3].

Dusseault iTIP inbox.

9.2.1 Example - Retrieve incoming iTIP Message

>> Request <<

GET /bernard/calendar/outbox/mtg456.ics HTTP/1.1
Host: cal.example.com

Daboo, et al. Expires January 16, March 21, 2005 [Page 20] 27]

Internet-Draft caldav July CalDAV September 2004

Example - Partial value for 'supported-privilege-set' property

<D:supported-privilege-set>
<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 xmlns:C="urn:ietf:params:xml:ns:calsch"/>
</D:privilege>
<D:description xml:lang="en">View free-busy rollup</D:description>
</D:supported-privilege>
</D:supported-privilege>
...

Dusseault

>> Response <<

HTTP/1.1 200 OK
Date: Thu, 02 Sep 2004 17:05:23 GMT
Originator: http://cal.example.com/lisa/inbox/
Content-Type: text/calendar
Content-Length: xxx

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

Daboo, et al. Expires January 16, March 21, 2005 [Page 21] 28]

Internet-Draft caldav July CalDAV September 2004

8. Property Promotion and Demotion

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

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 name for originator of an iTIP message submitted with
the functionality by SCHEDULE method. Note that the absoluteURI production is defined
in RFC2396 [2].

10.2 Recipient Header

Recipient = "Recipient" ":" 1#absoluteURI

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

Daboo, et al. Expires March 21, 2005 [Page 29]

Internet-Draft CalDAV September 2004

11. Properties from iCalendar

The W3C RDF Calendar group has already defined a resource's internal data namespace
("http://www.w3.org/2002/12/cal/ical#") and its externally-visible
metadata remain consistent. In WebDAV, a collection listing
(PROPFIND) selects a set of property XML element names to retrieve. For a
collection listing to be useful to browse calendars, certain for
many calendaring information must be exposed 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 (this
also makes WebDAV SEARCH useful, are needed to describe calendars and makes
calendar-containers because the definition of REPORTs
easier). Since a calendar resource of type text/calendar has W3C RDF Calendar group defines
properties which duplicate some of its internal state, it's for the
server's responsibility to keep those consistent somehow.

The server has some leeway in how it makes properties and bodies
consistent, as long iCalendar-defined objects only.

When used as a WebDAV property, each property name/namespace can
appear only once because the response property name and namespace is used to a GET shows information
consistent with
identify the response property in requests like PROPFIND and PROPPATCH.
Multi-valued elements could either be promoted to properties by using
a PROPFIND container (e.g. an 'attendees' property could hold each 'attendee'
element), or multi-valued elements can remain in the interval in which a
calendar object has iCalendar body,
and not been altered. Thus, the server MAY change
property values when a PUT is performed that alters data exposed be promoted as
properties, and also change WebDAV properties. That means clients must
download the event body when a PROPPATCH is performed
that alters calendar properties. Alternatively, a server could
implement "lazy promotion" and apply consistency changes only when a
GET, PROPFIND, SEARCH or REPORT is issued. Finally, a server might
decompose property data to learn the values for those pieces of
metadata.

TODO: Need to reference RFC3339 and non-property data into separate locations put date/time values in that
format, and recompose the information only when a GET requests note where that format differs from that of the entire
resource. Any iCalendar
RFC values.

If any of these approaches properties appear in an iCalendar body stored in a
CalDAV repository they MUST be transparent promoted. All these properties are in
the "http://www.w3.org/2002/12/cal/ical#" namespace.

Daboo, et al. Expires March 21, 2005 [Page 30]

Internet-Draft CalDAV September 2004

REQUIRED properties for promotion from iCalendar

The "has-xxx" properties listed above do not correspond to the client, properties
in that operations behave consistently, with complete round-trip
fidelity of all iCalendar components. Instead they are synthesised by the data originally provided. Thus, a WebDAV
server MAY
canonicalize its resource bodies (e.g. eliminate meaningless spaces)
but MUST preserve all data.

Not all based on the component's properties need to be promoted, only those as described in the
following sections. These WebDAV properties most
useful for are available to allow
clients to do provide hints about component state to the user without
the need to explicitly inspect the component data.

Daboo, et al. Expires March 21, 2005 [Page 31]

Internet-Draft CalDAV September 2004

11.1 has-recurrence Property

The "has-recurrence" property value searching indicates whether the corresponding
component contains one or listings of
calendar events either through PROPFIND more RRULE, RDATE, EXRULE or through EXDATE
properties. i.e. the recurrance
report. All unrecognized component is recurring. The integer value '1'
indicates that at least one of the recurrence properties can be left in is present,
the event body
(such as those beginning with x-).

TODO: This section needs further definition and details. Clients can
upload iCalendar files with syntactic 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 semantic errors, so helpful
error codes must be chosen for these cases:
o more embedded VALARM components. The
integer value '1' indicates that at least one embedded VALARM
component is present, the integer value '0' indicates that no
embedded VALARM components are present.

11.3 has-attachment Property

The "has-attachment" property indicates whether the corresponding
component contains one or more ATTACH properties. The integer value
'1' indicates that at least one ATTACH property is set which can't be demoted without making present, the
iCalendar body invalid
o iCalendar body provided isn't valid

Dusseault
integer value '0' indicates that no ATTACH properties are present.

Daboo, et al. Expires January 16, March 21, 2005 [Page 22] 32]

Internet-Draft caldav July CalDAV September 2004

9. Scheduling and Fanout

Scheduling and fanout

12. CalDAV Resource Properties

The namespace "urn:ietf:params:xml:ns:caldav" is reserved for this
specification, or standards-track specifications written to extend
CalDAV. It MUST NOT be used for custom extensions. It is a valuable function provided by advanced
calendaring servers. Simple clients clearly benefit from having the
logic handled by
namespace for every new property defined in this section (and every
XML element defined in this document).

Note that the server. Rich clients also benefit from having
to upload less data XML Schema declarations used in this document are
incomplete, in that they do not include namespace information. Thus,
the reader MUST NOT use these declarations as the only way to various servers (including messaging servers create
valid CalDAV properties or to send invitations via messages) validate CalDAV-related XML. Some of
the declarations refer to accomplish XML elements defined by WebDAV which use
the same things.
Servers can sometimes provide more advanced scheduling functionality
than clients - for example, "DAV:" namespace. Those WebDAV elements are not redefined in
this document.

12.1 Calendar-owner Property

Name: calendar-owner
Location: MUST appear on a server providing fanout could create
"unconfirmed" VEVENT calendar or calendar-container if there is
a principal resources within invitees' calendars.

However, rich calendaring (user or group) with which it is associated.
Purpose: This property is used for browsing clients may prefer to do fanout. Clients
can perform special functionality during scheduling (for example, find out the
user, group or resource for which the calendar events are
scheduled. Sometimes the calendar is a
client may be configured to user's calendar, in which
case the value SHOULD be able to directly put events on others'
calendars if the user user's principal URL from WebDAV ACL.
(In this case the DAV:owner property probably has sufficient permissions). Thus, it the same
principal URL value.)
If the calendar is
proposed that CalDAV allow a group calendar the client to either perform fanout and
merely create value SHOULD be the event (complete with attendee information) OR
request that
group's principal URL. (In this case the server perform fanout. In DAV:owner property
probably specifies one user who manages this group calendar.)
If the calendar is a resource calendar (e.g. for a room, or a
projector) there won't be a principal URL, so some other words, URL
SHOULD be used. A LDAP URL could be useful in this case.
This property contains one 'href' element in the server "DAV:" namespace.
Declaration: <!ELEMENT calendar-owner (href) >
Extensibility: MAY contain additional elements, which MUST handle fanout be ignored
if requested, and clients MAY perform fanout not understood.

Daboo, et al. Expires March 21, 2005 [Page 33]

Internet-Draft CalDAV September 2004

13. CalDAV Principal Properties

This section defines new properties for WebDAV principal resources as
defined in RFC3744 [11]. All these properties SHOULD exist on every
principal if the client chooses. server supports CalDAV servers MUST support iTIP anywhere in its namespace.
Generally, if no appropriate value is known for these properties, the
properties SHOULD exist but be blank. Generally these properties are
likely to do fanout when requested, and
MUST fall back be protected but the server MAY allow them to iMIP when iTIP is impossible. Each REQUEST
generated on behalf be written by
appropriate users.

13.1 alternate-calendar-URI Property

Name: alternate-calendar-URI
Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URI of an alternate calendar or scheduling
resource for the associated principal resource.
Description: The alternate-calendar-URI property is used to provide a Calendar MUST
resource address or identifier, such as a mailto URL [1] calendar
address, that can be stored used as an alternative to the
primary-itip-inbox-URL of the associated resource in the calendar's
'scheduling' collection. Each REPLY received
Originator or Recipient headers. This property SHOULD contain the
mailto URL if it is known to those REQUESTs MUST
be stored in accept iMIP requests, because clients
generally need a way to find out if some calendar user for whom
the iMIP address is known is the same collection. These REQUEST and REPLY items are
available until calendar user for whom the client deletes them so that clients can view
extra information (if present). CalDAV servers MUST parse incoming
REPLY messages
iTIP Inbox address is known, and update this property is the appropriate event with attendee
information. Thus, it's not necessary for clients only
reliable way to review REQUEST link those addresses together.
Value: Zero or REPLY items, although they may.

As well, 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 of any calendar collections owned by 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 March 21, 2005 [Page 34]

Internet-Draft CalDAV servers MUST support September 2004

Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identify the URL of any iTIP to receive scheduling
requests. When a CalDAV server receives an 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 of any iTIP request, it MUST
store Outbox collections owned by
the REQUEST object in an "invites" associated principal resource.
Value: Zero 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 the URL of the principal iTIP Inbox collection for
owned by the client to
handle. Each invite resource 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 associated principal resource. A principal resource
may have many iTIP requests Inbox collection, but it MAY auto-accept based on user
configured preferences. How these preferences are configured is out
of 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 the scope URL of this specification, the principal iTIP Outbox collection
owned by the associated principal resource. A principal resource
may have many iTIP Outbox collection, but it must have one could imagine that a
"principal iTIP Outbox".
Value: URI

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

Daboo, et al. Expires March 21, 2005 [Page 35]

Internet-Draft CalDAV server could host auto-accept configuration Web pages. September 2004

14. Calendaring Privileges

A CalDAV server is NOT REQUIRED to do any auto-accepting, it MAY simply
store the requests for the next time MUST support the client is online.

Exact mechanisms WebDAV ACLs standard [11]. That
standard provides a framework for triggering fanout requests must be determined an extensible list of privileges on
WebDAV collections and input is welcome. There are several ways fanout could be
accomplished: (a) ordinary resources. A PUT of CalDAV server MUST also
support the resource triggers fanout, so set of calendar-specific privileges defined in this
section.

14.1 view-free-busy Privilege

Calendar users often wish to allow other users to see their free-busy
times, without viewing the body

Dusseault Expires January 16, 2005 [Page 23]

Internet-Draft caldav July 2004

must contain other details of the fanout information (text and flags), (b) a PROPPATCH
triggers fanout if certain properties are set, (c) calendar events
(location, subject, attendees). This allows a new method
requests fanout significant amount of a resource that has already been uploaded. These
three approaches are
privacy while still allowing those other users to schedule meetings
at times when the calendar owner is likely to be free.

The view-free-busy privilege in the most obvious "urn:ietf:params:xml:ns:caldav"
namespace controls access to this author view the start times and there is
surprisingly little end times of
free and busy blocks of time. This privilege may be granted on an
entire calendar. It may also make sense to choose between. More input is needed, for
example input grant this privilege on whether the fanout should be synchronous or
asynchronous. An asynchronous fanout mechanism using PUT or
PROPPATCH would mean that
individual events (in which case the client time allocated to those events
would synchronously handle show up as free in the
PUT or PROPPATCH itself, free-busy rollup to an unauthorized
viewer), but send invitations at some later time. A
synchronous fanout mechanism would probably use a new method with a
name like INVITE, because adding new synchronous behavior to existing
methods might require more complicated server implementation work.

When MAY forbid the free-busy privilege from being
used on individual events or event containers. A CalDAV server does fanout, it may send requests and receive
replies. Probably these requests and responses should be stored as MUST
support the free-busy privilege on a Calendar collection.

<!ELEMENT view-free-busy EMPTY>

The view-free-busy privilege is aggregated in the standard WebDAV resources so
'read' privilege. Clients can discover support for various
privileges using the 'DAV:supported-privilege-set' property defined
in RFC3744 [11].

14.2 schedule Privilege

The schedule privilege controls 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 and never
grant that permission to anybody else. If the client privilege is granted
to somebody other than the calendar owner, that person is called the
delegate, somebody who can examine issue invitations or replies on behalf of
the details calendar owner. Thus, if
desired. This could be a separate collection within server receives a SCHEDULE request
where the calendar
collection.

Dusseault authenticated sender of the SCHEDULE request does not have
schedule permission, the server MUST reject the request.

<!ELEMENT schedule EMPTY >

For example, the following ACE, on Bernard's iTIP Outbox, would only

Daboo, et al. Expires January 16, March 21, 2005 [Page 24] 36]

Internet-Draft caldav July CalDAV September 2004

10. Properties from iCalendar

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 W3C RDF Calendar group has already defined calendar-bind privilege is used on a namespace ("http://
www.w3.org/2002/12/cal/ical#") and XML element names for many
calendaring properties, and these are completely consistent with
iCal. This standard reuses those namespaces, names and definitions,
as much as iTIP Inbox or on a calendar
collection, to govern whether a user may cause new calendar resources
(MIME type text/calendar) to be created in the collection. It is consistent with
similar to the WebDAV data model. Additional
properties are needed to describe calendars and calendar-containers 'bind' privilege but more restricted, because
it only allows the W3C RDF Calendar group defines properties user to create new resources of certain types. It
doesn't, for example, allow the
iCalendar-defined objects only.

When used as a WebDAV property, each property name/namespace can
appear only once because privileged user to create new
collections.

Recall that the property name and namespace iTIP Inbox is used to
identify receive iTIP messages. The
server automatically creates resources inside the property in requests like PROPFIND and PROPPATCH.
Multi-valued elements could either be promoted iTIP Inbox when it
handles invitations for the inbox's owner. Thus, the calendar-bind
privilege determines whether an event organizer is allowed to properties by using send an
invitation to an attendee and have it appear in their iTIP Inbox.

One way an invitation may appear in an iTIP inbox is with the
SCHEDULE request. If the server receives a SCHEDULE request where a container (e.g. an 'attendees' property could hold each 'attendee'
element), or multi-valued elements can remain
calendar inbox is named in the iCalendar body,
and not be promoted as WebDAV properties. That means clients must
download Recipient header, it MUST check to see
whether the event body 'calendar-bind' privilege is granted either to learn the values for those pieces
authenticated sender of
metadata.

TODO: Need the request, OR to reference RFC3339 and put date/time values in that
format, and note where the owner of the iTIP
Outbox that format differs the request comes from that (the Request-URI of the iCalendar
RFC values. SCHEDULE
method). Thus, if user Alice grants Bob calendar-bind privilege on
Alice's inbox, 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. The SCHEDULE request If any the server's calendar-bind
privilege check fails for a given inbox, the rest of these properties appear in an iCalendar body stored in the SCHEDULE
request may still succeed, but a
CalDAV repository they MUST be promoted. All these properties are 403 Forbidden error would apper in
the "http://www.w3.org/2002/12/cal/ical#"

REQUIRED properties for promotion from iCalendar

Name WebDAV Property value type
---------- --------------------------
summary text
dtstart date-time from RFC2518
dtend date-time from RFC2518
duration DURATION from RFC2445
transp text with values from RFC2445
due date-time from RFC2518
completed date-time from RFC2518
status text with values from RFC2445
priority integer
percent-complete integer
uid text
trigger see below TODO

Dusseault Expires January 16, 2005 [Page 25]

Internet-Draft caldav July 2004

11. CalDAV Resource Properties Multi-status response to the SCHEDULE request.

The namespace "urn:ietf:params:xml:ns:calsch" server SHOULD also attempt to apply the calendar-bind privilege
in other situations where it is reserved for
specifications written by requested to add a resource to the
iTIP inbox. For example, if the server handles invitations received
through some other iTIP binding, the server SHOULD try to see if the CalSch working group or its eventual
successors. It MUST NOT

Daboo, et al. Expires March 21, 2005 [Page 37]

Internet-Draft CalDAV September 2004

invitation should be used for custom extensions. It is automatically rejected based on the
namespace for every access
control on the iTIP inbox.

Outside the iTIP inbox, the same privilege has a slightly different
effect, but has the same meaning. If the server receives any HTTP
request which would create a new defined in this section (and every XML
element defined in this document).

Note that resource inside a calendar, the XML Schema declarations used in this document are
incomplete, in
server MUST check to see whether calendar-bind privilege is granted
on that they do calendar collection.

Typically, not include namespace information. Thus, many users will allow others to put events directly on
their calendar, instead preferring to see invitations and choose
whether to accept. In the reader MUST NOT use exceptional cases, users will allow a
select few to directly put events on their calendar, and in these declarations as
cases, the only way to create
valid CalDAV properties or 'calendar-bind' privilege will be granted to validate CalDAV-related XML. Some of those few.
On the declarations refer other hand, many users are happy to XML elements defined by WebDAV which use receive invitations from
anyone, so an iTIP inbox may grant 'calendar-bind' privilege to all
users.

<!ELEMENT calendar-bind EMPTY >

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

In the "DAV:" namespace. Those WebDAV elements are not redefined in
this document.

11.1 Calendar-owner Property

Name: calendar-owner
Location: ACL standard, servers MUST appear on a calendar or calendar-container if there support the
'supported-privilege-set' property to show which privileges are
abstract, which privileges are supported, how 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 principal resources (user subset or group) with which it is associated.
Purpose: This a superset of another
privilege. For example, because reading the ACL property is used to discover the calendar owner, or
considered a more specific privilege than the
person or group for which read privilege (a
subset of the calendar events total set of actions are scheduled. It
MAY have allowed), it is aggregated
under the same value as read privilege. Although the DAV (ACL) 'owner' property, but not
necessarily. For example, list of supported privileges
MAY vary somewhat from 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 the president may view-free-busy privilege. The
view-free-busy privilege MUST be non-abstract, and MUST be
aggregated under the
calendar-owner, but her secretary is read privilege.
o If the owner for all ACL/
administrative purposes. This property contains one 'href'
element in server supports scheduling, the "DAV:" namespace.
Declaration: <!ELEMENT calendar-owner (href) >
Extensibility: MAY contain additional elements, which server MUST support the
schedule and calendar-bind privileges. Both these privileges MUST
be ignored
if not understood.

11.2 Calendars Property

Name: calendars
Location: non-abstract, and MUST appear on ACL Principal resources with which a
calendar is associated.
Purpose: be aggregated under the 'bind'
privilege.

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

This is a partial example of how the 'supported-privilege-set'
property could look on a server supporting CalDAV. Note that
aggregation is used to browse principals and find out what
calendars they have, for shown in the structure of the 'supported-privilege'

Daboo, et al. Expires March 21, 2005 [Page 38]

Internet-Draft CalDAV September 2004

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>
<D:privilege>
<C:calendar-bind/>
</D:privilege>
<D:description xml:lang="en">Directly schedule (request a
meeting) of the purpose owner of this iTIP inbox</D:description>
</D:supported-privilege>
<D:supported-privilege>
<D:privilege>
<C:schedule/>
</D:privilege>
<D:description xml:lang="en">Make schedule requests of
others, on behalf of then browsing their
calendar or their free/busy published information. It contains
one or more 'href' elements in the "DAV:" namespace (this is a
normal WebDAV approach to putting one or more URL value in a
property value).
Declaration: <!ELEMENT calendars (href+) >
Extensibility: MAY contain additional elements, which MUST be ignored
if not understood.

Dusseault owner of this iTIP

Daboo, et al. Expires January 16, March 21, 2005 [Page 26] 39]

Internet-Draft caldav July CalDAV September 2004

12.

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

Daboo, et al. Expires March 21, 2005 [Page 40]

Internet-Draft CalDAV September 2004

15. Calendaring Reports

This section defines the reports which a CalDAV server MUST support.
These all provide special query functionality not normally handled by
the generic PROPFIND or SEARCH mechanisms. This can be required when
a PROPFIND or SEARCH cannot be written 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 for some examples of reports required in other situations.

As defined in DeltaV, all REPORT requests include an XML body naming
the type of report requested (only one) and some variables for how
that report is to be compiled. Note 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 the reports
defined here and in the ACL standard, but is not expected to support
DeltaV reports unless it advertises them. Reports are advertised
with the 'supported-report-set' property defined in DeltaV (again,
even if versioning-specific features are not at all supported). so a
CalDAV server MUST provide a value for 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 any
REPORT request. This includes redirect status codes, syntax errors
(400 Bad Request), permission errors or policy errors (401
Unauthorized 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 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: XXX xxx

<?xml version="1.0" encoding="UTF-8" ?>
<D:error xmlns:D="DAV:">
<range-invalid xnlns="urn:ietf:params:xml:ns:calsch"/> xnlns="urn:ietf:params:xml:ns:caldav"/>
</D:error>

12.1 The 'calendar-time-range' report

Daboo, et al. Expires March 21, 2005 [Page 41]

Internet-Draft CalDAV September 2004

15.1 calendar-time-range Report

The 'calendar-time-range' report returns all objects of a specific

Dusseault Expires January 16, 2005 [Page 27]

Internet-Draft caldav July 2004
type within a time range, with or without recurrance recurrence expanded. The
first use case for this report is to have the server expand recurring
events to make a calendar view of a day's or week's events easy. The
WebDAV PROPFIND and SEARCH syntaxes do not as easily support this use
case. Even when the client doesn't need recurrance recurrence expanded, it can
use this report to save itself from the need to write a SEARCH query
which catches all events overlapping any part of the period
requested, or from having to do a PROPFIND and filter itself.

The second use case for this report is for users other than the
calendar owner to find out when the calendar owner is free. This is
only a minor variation, because it's effectively the same objects
(VEVENT and VFREEBUSY), only with permissions restricting the kind of
data the server will return. Servers MUST allow users with
permission to view the free-busy times for a calendar to use this
report. Servers MUST return event properties for visible events
including dtstart, dtend and free-busy type. Other properties MAY be
refused.

The third use case for this report is to list all alarms in a time
range. The selection of VALARM objects, instead of VEVENT or
VFREEBUSY objects, allows this use case to be handled with the same
report framework.

12.1.1

15.1.1 Request for 'calendar-time-range'

The REPORT request-body MUST have the root element
'calendar-time-range'.

o The root element MAY contain the 'expand-recurrances' 'expand-recurrences' element as a
flag.
o The root element MAY contain the 'object-types' 'component' element to list what
object types to return.
o The root element MUST contain the 'prop' element in the "DAV:"
namespace as defined in WebDAV, to list what property values to
return.
o The root element MUST contain one 'dtstart' element
o The root element MUST contain one 'dtend' element.

The Request-URI for this report MUST be a Calendar-container, a
calendar collection, or an events collection. The server MUST
collation
collate all the event data contained within the requested
collection.

Dusseault collection
(this implies depth infinity, so the Depth header isn't used on this
report).

Daboo, et al. Expires January 16, March 21, 2005 [Page 28] 42]

Internet-Draft caldav July CalDAV September 2004

Sample request for 'time-range-events' 'calendar-time-range' report

REPORT /lisa/Calendar /lisa/calendar HTTP/1.1
Host: cal.example.com
Content-Type: text/xml
Content-Length: XXX xxx

<?xml version="1.0>
<report
<c:calendar-time-range xmlns="DAV:" xmlns:i="http://www.w3.org/2002/12/cal/ical">
<c:time-range-events xmlns:c="urn:ietf:params:xml:ns:calsch">
xmlns:c="urn:ietf:params:xml:ns:caldav"
xmlns:i="http://www.w3.org/2002/12/cal/ical#">
<c:expand-recurrances>
<i:dtstart>20031101</i:dtstart>
<i:dtend>20031131</i:dtend>
<c:object-types><i:Vevent/></c:object-types>
<c:component-filter><i:Vevent/></c:component-filter>
<prop>
<i:dtstart/> <i:dtend/> <i:summary/> <i:valarm/>
</prop>
</c:expand-event-report>
</report>

12.1.2
</c:calendar-time-range>

15.1.2 Response to 'time-range-events' 'calendar-time-range'

The response to this report is a WebDAV Multi-Status response,
containing one <response> element for each event AND for each
recurrance.
recurrence. This differs from the PROPFIND response to an event
collection only in that the relevant recurrances recurrences each have their own
<response> element, not just the master event.

The server MUST expand all recurring events calendar objects within the
entire collection (including sub-collections) if requested, and
return all those events calendar objects or recurrances recurrences which overlap the
period defined by the start to end. If an event a calendar object ends at
precisely the requested start time, or begins at precisely the
requested end time, it does not overlap the period requested.

If the user requests properties which may not be seen (e.g. a user
with permission only to see free-busy time requests to see the
location of events), calendar objects), the response uses the regular WebDAV
approach for properties which are private (either 401 Unauthorized if
the client is not authenticated, or 403 Forbidden if the client is
authenticated and still the property value is private). These errors
appear within the standard Multi-Status response.

TODO: I guess an example is probably needed here.

12.1.3 Errors for 'time-range-events'

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 29] 43]

Internet-Draft caldav July CalDAV September 2004

15.1.3 Errors for 'calendar-time-range'

invalid-range The server returns this error when the range requested
in the 'dtstart' and 'dtend' values is an invalid range (e.g.
dtend is earlier than or equal to dtstart value).

12.1.4 Timezones report

CAP offers

15.2 calendar-property-search REPORT

The calendar-property-search REPORT performs a way to get timezones. I'm unclear whether search for all
calendar objects whose properties contain character data that matches
the search criteria specified in the request. The authors anticipate
that this report will be required if DASL is a
server-wide list, or whether not standardized before
CalDAV.

Support for the contents vary by calendar/user.
That would help to decide whether to use a special OPTIONS request, a
new REPORT, or a new collection.

Dusseault calendar-property-search REPORT is REQUIRED.

Marshalling: TODO

15.2.1 Example: calendar-property-search REPORT

>> Request <<

REPORT /lisa/calendar/events/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0"?>
<C:calendar-property-search
xmlns:C="urn:ietf:params:xml:ns:caldav"
xmlns:I="http://www.w3.org/2002/12/cal/ical#">
<C:component-filter>
<I:vevent/>
</C:component-filter>
<C:calendar-property>
<I:uid>20010712T182145Z-123401@example.com</I:uid>
</C:calendar-property>
</C:calendar-property-search>

Daboo, et al. Expires January 16, March 21, 2005 [Page 30] 44]

Internet-Draft caldav July CalDAV September 2004

13.

>> Response <<

HTTP/1.1 207 Multi-Status
Date: Thu, 02 Sep 2004 18:07:46 GMT
Content-Type: text/xml
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>
http://cal.example.com/lisa/calendar/events/mtg10028.ics
</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>

Daboo, et al. Expires March 21, 2005 [Page 45]

Internet-Draft CalDAV September 2004

16. Using existing WebDAV features in Calendaring

13.1

16.1 SEARCH and calendar data

The DASL framework for search requests provides a powerful way to
find calendars in a repository, and to find calendar objects within a
calendar. It is virtually unlimited in variations. It can be used
to request and search on calendar properties as well as WebDAV
properties. One drawback of DASL, however, is that implementations
are given great leeway in which properties support search. That's
less acceptable in calendaring applications, so this specification
adds requirements of CalDAV servers to support searches on specific
properties.

CalDAV servers MUST support 'eq' DASL searches on the following
properties: uid, valarm. recurrence-id.

CalDAV servers MUST support 'eq', 'gt' and 'lt' DASL searches on the
following properties: dtstart, dtend, dtstamp.

CalDAV servers MUST support 'eq' and 'contains' DASL searches on the
following properties: location, comment, description, summary,
organizer, attendee, categories.

13.2

16.2 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 of all WebDAV
servers. Since offline functionality is more important to Calendar
applications than to other WebDAV applications, 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
to synchronize with DELETE operations. However, all these mechanisms
are of general use and not limited to Calendaring. Therefore, it is
suggested that work on advanced synchronization take place in a
separate document independent of the calendaring-specific features
discussed here. Many people are interested in doing this kind 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 to synchronize WebDAV objects most effectively. In

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 31] 46]

Internet-Draft caldav July CalDAV September 2004

particular, we need to understand how UID/SEQ metadata works with
synchronization.

Note that recurrance recurrence isn't a synchronization problem in this model.
Recurring items appear only once in normal PROPFIND responses, so
there's no danger that in synchronizing a client will accidentally
create extra recurrances. recurrences. Instead, recurrances recurrences appear only in a
special REPORT which MUST not be used for synchronization. We
believe this separation between data (recurring appointments) and
presentation (the display of a period containing several recurrances) recurrences)
is crucial to simplifying synchronization.

Daboo, et al. Expires March 21, 2005 [Page 47]

Internet-Draft CalDAV September 2004

17. Security Considerations

TODO

Daboo, et al. Expires March 21, 2005 [Page 48]

Internet-Draft CalDAV September 2004

18. IANA Consideration

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

18.1 Namespace Registration

Registration request for the caldav namespace:

URI: urn:ietf:params:xml:ns:caldav

Registrant Contact: See the "Author's Address" section of this
document.

XML: None. Namespace URIs do not represent an XML specification.

19 Normative References

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

[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.

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

[2]

[4] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
"iCalendar Transport-Independent Interoperability Protocol
(iTIP) Scheduling Events, BusyTime, To-dos and Journal
Entries", RFC 2446, November 1998.

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

[3]

[6] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC
2518, February 1999.

[4]

[7] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead,
"Versioning Extensions to WebDAV (Web Distributed Authoring and
Versioning)", RFC 3253, March 2002.

[5]

Daboo, et al. Expires March 21, 2005 [Page 49]

Internet-Draft CalDAV September 2004

[8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.

[6]

[9] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.

[7]

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

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

[8]

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

[9]

[13] Reschke, J., Reddy, S., Davis, J. and A. Babich, "WebDAV
SEARCH", draft-reschke-webdav-search-06 (work in progress),
August 2004.

Dusseault

Authors' Addresses

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

EMail: daboo@isamet.com

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

EMail: bernard.desruisseaux@oracle.com

Daboo, et al. Expires January 16, March 21, 2005 [Page 32] 50]

Internet-Draft caldav July CalDAV September 2004

Author's Address

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

EMail: lisa@osafoundation.org

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 33] 51]

Internet-Draft caldav July CalDAV September 2004

Appendix A. Acknowledgements

Cyrus Daboo and

Michael Arick have has provided substantial feedback for this draft.

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 34] 52]

Internet-Draft caldav July CalDAV September 2004

Appendix B. Changes

B.1 Changes in -02

Basically still adding major sections of content:
a. Defined new field values to the OPTIONS "DAV:" response header
b. Added new resource properties
c. Added new principal properties
d. Added new SCHEDULE method and related headers
e. Added new privileges for scheduling

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

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 35] 53]

Internet-Draft caldav July CalDAV September 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 36] 54]

Internet-Draft caldav July CalDAV September 2004

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Dusseault

Daboo, et al. Expires January 16, March 21, 2005 [Page 37] 55]

----