|Network Working Group||L. Dusseault|
|Intended status: Informational||July 18, 2004|
|Expires: January 19, 2005|
Calendar Server Extensions for WebDAV (CalDAV)
Note: a later version of this document has been published as RFC4791.
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.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2005.
Copyright © The Internet Society (2004). All Rights Reserved.
In the five years since WebDAV  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 and queries for free-busy times. This draft proposes a standard data 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).
This draft was commissioned at the Fall 2003 Minneapolis working group meeting of the CalSched working group. The concept of using HTTP  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 HTTP PUT/GET to upload and download iCalendar  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:calsch" 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.
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.
WebDAV is an extension of HTTP , 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  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.
Specifying new URL formats creates additional work for implementors 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.
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>.
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' properties are those which the server allows clients to set but the server has no special behavior regarding those properties. Other clients may query and use these dead properties.)
WebDAV includes locking support. Locks are indispensible 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.
The WebDAV ACL specification  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.
Many WebDAV client appliations, 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).
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).
Many WebDAV working group members are discussing more work to improve the performance of synchronization betweeen 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 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 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.
Calendaring systems need a mix of fixed, specific searches (such as a "search" for the events occuring today) and general search support. WebDAV DASL  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.
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.
Certain features that are required for modern enterprise-level calendar systems are not present in HTTP or WebDAV, unsurprisingly. This section makes clear what those missing features are. The rest of this document is largely about how those missing features could be filled in.
This section lists what functionality is required of a CalDAV server. To advertise support for CalDAV or claim compliance, a server:
One of the features which has made WebDAV a successful protocol is its firm data model. This makes it a useful framework for other applications such as calendaring. In this proposal, we attempt to follow the same pattern by developing all new features based on a well-described data model.
In this data model, every iCalendar VEVENT, VALARM, VJOURNAL, VTODO and VFREEBUSY is stored 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 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.
A CalDav repository, or server, is a calendaring-aware engine combined with a WebDAV repository. A WebDAV repository is a set of WebDAV collections, containing other WebDAV resources, within a unified URL namespace. For example, the repository "http://example.org/webdav/" may contain WebDAV collections and resources, all 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 is implemented through a servlet or other Web server extension).
A WebDAV repository may include calendar data in some areas, and non-calendaring data in other areas. Calendar data will be indicated through specific container relationships and resource types discussed in the next sections.
A WebDAV repository may advertise itself as a CalDAV server if it supports the functionality defined in this specification at any point within the root of the repository. That might mean that calendaring data is spread throughout the repository (e.g. in /ldusseault/calendar as well as in /nborenstein/calendar) or only in certain sections of the repository (e.g. /caldav/usercals/*). Calendaring features are only required in the repository sections that are or contain calendaring objects. So a repository confining calendar data to the /caldav/ collection would only need to 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 has significant responsibility to ensure that the data is consistent and compliant. Clients may submit requests to change data or download data. Clients may store the calendar offline and attempt to synchronize when reconnected, but changes to the 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 work.
CalDAV defines the following new resource types for use in calendar repositories.
A WebDAV collection which contains one or more calendars is considered a Calendar Container. It has a new resource type:
<resourcetype xmlns="DAV"> <collection/> <C:calendar-container xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
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.
A WebDAV collection which corresponds to a single calendar or VAGENDA is a Calendar. It has a new resource type:
<resourcetype xmlns="DAV"> <collection/> <C:calendar xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
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 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 calendars, e.g. "/ldusseault/calendars/work" and "/ldusseault/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.
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.
<resourcetype xmlns="DAV"> <collection/> <C:events xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
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.
Each Calendar MUST have a collection containing alarms. All resources within this alarm collection (even within its sub-collections) are considered part of the calendar. The alarm collection has its own resource type.
<resourcetype xmlns="DAV"> <collection/> <C:alarms xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
Every non-collection resource in a alarms collection is considered to be an alarm. Every resource MUST have the default MIME type text/calendar, and contains exactly one VALARM.
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.
<resourcetype xmlns="DAV"> <collection/> <C:todos xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
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.
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.
<resourcetype xmlns="DAV"> <collection/> <C:journal xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
Every non-collection resource in a journal is considered to be a journal item. Every resource MUST have the default MIME type text/calendar, and contains exactly one VJOURNAL.
Every Calendar-Container MUST have a child collection to contain invites received through iTIP. If a Calendar is not inside a Calendar-Container, then that Calendar MUST have its own invites collection. This collection is to store received, accepted and archived invitations so that clients can accept and review scheduling invitations.
<resourcetype xmlns="DAV"> <collection/> <C:invites xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
Every non-collection resource in the invites collection is considered to be a REQUEST. Every resource MUST have the default MIME type text/calendar, and contains exactly one REQUEST.
Every Calendar MUST have a child collection to contain 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 adding attendee information to events.
<resourcetype xmlns="DAV"> <collection/> <C:scheduling xmlns:C="urn:ietf:params:xml:ns:calsch"> </resourcetype>
Every non-collection resource in the invites collection is considered to be a REQUEST or REPLY. Every resource MUST have the default MIME type text/calendar, and contains exactly one REQUEST or exactly one REPLY.
Recurrance is an important part of the data model because it governs how many resources are expected to exist.
Consider the outcome if recurrance were handled 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 the right set of resources so that the user can change 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 less data to synchronize, and makes it easier to make changes to all recurrances or to a recurrance pattern. It makes it easier to create a recurring event, and easier to delete all recurrances.
The drawback of 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 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 a time period [TODO - ref section].
Because of this choice, clients MUST NOT create separate resources to represent a recurring event when the recurrance pattern is known. Otherwise, it makes it more difficult for other clients to interoperate and modify the recurring event. Most importantly, clients MUST NOT duplicate events represented through recurrance patterns with manually created events, which would appear as duplicates to the server and to other clients.
This is a big issue because CalDAV servers need to know the timezone of the calendar in order to calculate recurrances in a deterministic manner. In addition to having a calendar default timezone, individual events (e.g. those received in a scheduling request from another place) can have different timezones. Finally, iCalendar has a way to specify custom timezones.
The default calendar timezone is probably simply a property value on the calendar collection, which the calendaring client can change. The event timezone is a piece of VEVENT metadata that would therefore appear both inside the event in iCalendar format, and as a promoted property on the event resource. Storing custom timezone definitions can be through a new collection if necessary. More discussion here is welcome.
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 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 unique URL. It's slightly tougher for clients, because a client might not want to examine all resources in the collection, and might not want to lock the entire collection to ensure that a new one isn't created with a name collision. However, there are tools to mitigate this. If the client intends to create a new non-collection resource, such as a new VEVENT, the client SHOULD use the HTTP header "If-None-Match: *" on the PUT request. The Request-URI on the PUT request MUST include the target collection, where the resource is to be created, plus the name of the resource in the last path segment. The last path segment could be a random number, or it could be a sequence number, or a string related to the 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 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 is the same, but with a specific ETag in the "If-Match" header, rather than the "If-None-Match" header.
For optimum interoperability with existing HTTP clients, CalDAV clients and servers MUST use the file extension ".ics" as well as the "text/ icalendar" MIME type, whenever creating Calendar objects of that MIME type.
Note because of these requirements that there is no semantic value in any other part of a resource name other the file extension. Thus, a Calendar collection may be called "calendar", "cal", "Calendario" or "日历" (Chinese). It's the properties of the resource that define what it is, not the name.
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/ldusseault) and groups (for example, as /principals/groups/calsch). This feature offers an excellent framework for linking users to calendars in a fashion not otherwise easily implemented.
Note that the WebDAV principal resources may not be modifiable through WebDAV. This is an important consideration because it allows the principal directory to be merely a WebDAV representation of data which is canonically stored in an outside system. For example, an enterprise might use an LDAP server to store and administer all user and group properties. This LDAP server could be linked into the WebDAV repository through configuration information. WebDAV server implementations exist which offer principal resources, but when the principal resources are queried the server actually makes a LDAP request to get the principal information from its official source. This saves WebDAV clients from having to implement LDAP and provides a single URL format for principals regardless of whether 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 to principal resources. These properties are defined in the properties section.
A CalDAV server MUST support the WebDAV ACLs standard . That standard provides a framework for an extensible list of privileges on WebDAV collections and ordinary resources. A CalDAV server MUST also support the set of calendar-specific privileges defined in this section.
Calendar users often wish to allow other users to see their free-busy times, without viewing the other details of 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 the calendar owner is likely to be free.
The view-free-busy privilege in the "urn:ietf:params:xml:ns:calsch" namespace controls access to view the start times and end times of free and busy blocks 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 in the free-busy rollup to an unauthorized viewer), but a server MAY forbid the free-busy privilege from being used on individual events or event containers. A CalDAV server 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 'read' privilege. Clients can discover support for various privileges using the 'DAV:supported-privilege-set' property defined in RFC2518 .
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> ...
Property promotion and demotion (hereafter called simply "property promotion") is the name for the functionality by which a server ensures that a resource's internal data and its externally-visible metadata remain consistent. In WebDAV, a collection listing (PROPFIND) selects a set of property names to retrieve. For a collection listing to be useful to browse calendars, certain calendaring information must be exposed as WebDAV properties (this also makes WebDAV SEARCH useful, and makes the definition of REPORTs easier). Since a calendar resource of type text/calendar has properties which duplicate some of its internal state, it's the server's responsibility to keep those consistent somehow.
The server has some leeway in how it makes properties and bodies consistent, as long as the response to a GET shows information consistent with the response to a PROPFIND in the interval in which a calendar object has not been altered. Thus, the server MAY change property values when a PUT is performed that alters data exposed as properties, and also change the 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 and 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 the client, in that operations behave consistently, with complete round-trip fidelity of all the data originally provided. Thus, a server MAY canonicalize its resource bodies (e.g. eliminate meaningless spaces) but MUST preserve all data.
Not all properties need to be promoted, only those properties most useful for clients to do property value searching or listings of calendar events either through PROPFIND or through the recurrance report. All unrecognized properties can be left in the event body (such as those beginning with x-).
TODO: This section needs further definition and details. Clients can upload iCalendar files with syntactic or semantic errors, so helpful error codes must be chosen for these cases:
Scheduling and fanout is a valuable function provided by advanced calendaring servers. Simple clients clearly benefit from having the logic handled by the server. Rich clients also benefit from having to upload less data to various servers (including messaging servers to send invitations via messages) to accomplish the same things. Servers can sometimes provide more advanced scheduling functionality than clients - for example, a server providing fanout could create "unconfirmed" VEVENT resources within invitees' calendars.
However, rich calendaring clients may prefer to do fanout. Clients can perform special functionality during scheduling (for example, a client may be configured to be able to directly put events on others' calendars if the user has sufficient permissions). Thus, it is proposed that CalDAV allow the client to either perform fanout and merely create the event (complete with attendee information) OR request that the server perform fanout. In other words, the server MUST handle fanout if requested, and clients MAY perform fanout if the client chooses.
CalDAV servers MUST support iTIP to do fanout when requested, and MUST fall back to iMIP when iTIP is impossible. Each REQUEST generated on behalf of a Calendar MUST be stored in the calendar's 'scheduling' collection. Each REPLY received to those REQUESTs MUST be stored in the same collection. These REQUEST and REPLY items are available until the client deletes them so that clients can view extra information (if present). CalDAV servers MUST parse incoming REPLY messages and update the appropriate event with attendee information. Thus, it's not necessary for clients to review REQUEST or REPLY items, although they may.
As well, CalDAV servers MUST support iTIP to receive scheduling requests. When a CalDAV server receives an iTIP request, it MUST store the REQUEST object in an "invites" collection for 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 iTIP requests it MAY auto-accept based on user configured preferences. How these preferences are configured is out of the scope of this specification, but one could imagine that a CalDAV server could host auto-accept configuration Web pages. A CalDAV server is NOT REQUIRED to do any auto-accepting, it MAY simply store the requests for the next time the client is online.
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 resource triggers fanout, so the body must contain the fanout information (text and flags), (b) a PROPPATCH triggers fanout if certain properties are set, (c) a new method requests fanout of a resource that has already been uploaded. These three approaches are the most obvious to this author and there is surprisingly little to choose between. More input is needed, for example input on whether the 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 method with a name like INVITE, because adding new synchronous behavior to existing methods might require more complicated server implementation work.
When the server does fanout, it may send requests and receive replies. Probably these requests and responses should be stored as WebDAV resources so that the client can examine the details if desired. This could be a separate collection within the calendar collection.
The W3C RDF Calendar group has already defined 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 is consistent with the WebDAV data model. Additional properties are needed to describe calendars and calendar-containers because the W3C RDF Calendar group defines properties for the iCalendar-defined objects only.
When used as a WebDAV property, each property name/namespace can appear only once because the property name and namespace is used to identify the property in requests like PROPFIND and PROPPATCH. Multi-valued elements could either be promoted to properties by using a container (e.g. an 'attendees' property could hold each 'attendee' element), or multi-valued elements can remain in the iCalendar body, and not be promoted as WebDAV properties. That means clients must download the event body to learn the values for those pieces of metadata.
TODO: Need to reference RFC3339 and put date/time values in that format, and note where that format differs from that of the iCalendar RFC values.
If any of these properties appear in an iCalendar body stored in a CalDAV repository they MUST be promoted. All these properties are in the "http://www.w3.org/2002/12/cal/ical#"
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
The namespace "urn:ietf:params:xml:ns:calsch" is reserved for specifications written by the CalSch working group or its eventual successors. It MUST NOT be used for custom extensions. It is the namespace for every new defined in this section (and every XML element defined in this document).
Note that the 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 create valid CalDAV properties or to validate CalDAV-related XML. Some of the declarations refer to XML elements defined by WebDAV which use the "DAV:" namespace. Those WebDAV elements are not redefined in this document.
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).
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 <?xml version="1.0" encoding="UTF-8" ?> <D:error xmlns:D="DAV:"> <range-invalid xnlns="urn:ietf:params:xml:ns:calsch"/> </D:error>
The 'calendar-time-range' report returns all objects of a specific type within a time range, with or without recurrance 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 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.
The REPORT request-body MUST have the root element 'calendar-time-range'.
The Request-URI for this report MUST be a Calendar-container, a calendar collection, or an events collection. The server MUST collation all the event data contained within the requested collection.
Sample request for 'time-range-events' report
REPORT /lisa/Calendar HTTP/1.1 Host: cal.example.com Content-Type: text/xml Content-Length: XXX <?xml version="1.0> <report xmlns="DAV:" xmlns:i="http://www.w3.org/2002/12/cal/ical"> <c:time-range-events xmlns:c="urn:ietf:params:xml:ns:calsch"> <i:dtstart>20031101</i:dtstart> <i:dtend>20031131</i:dtend> <c:object-types><i:Vevent/></c:object-types> <prop> <i:dtstart/> <i:dtend/> <i:summary/> <i:valarm/> </prop> </c:expand-event-report> </report>
The response to this report is a WebDAV Multi-Status response, containing one <response> element for each event AND for each recurrance. This differs from the PROPFIND response to an event collection only in that the relevant recurrances each have their own <response> element, not just the master event.
The server MUST expand all recurring events within the entire collection (including sub-collections) if requested, and return all those events or recurrances which overlap the period defined by the start to end. If an event 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), 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.
CAP offers a way to get timezones. I'm unclear whether this is a server-wide list, or whether 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.
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.
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.
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 particular, we need to understand how UID/SEQ metadata works with synchronization.
Note that recurrance 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. Instead, recurrances 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) is crucial to simplifying synchronization.
|||Dawson, F., Stenerson, D., “Internet Calendaring and Scheduling Core Object Specification (iCalendar)”, RFC 2445, November 1998.|
|||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.|
|||Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, “HTTP Extensions for Distributed Authoring -- WEBDAV”, RFC 2518, February 1999.|
|||Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. Whitehead, “Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)”, RFC 3253, March 2002.|
|||Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification”, RFC 3265, June 2002.|
|||Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, July 2002.|
|||Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, “Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol”, RFC 3744, May 2004.|
|||W3C, “iCalendar Schema in RDF/XML”, site http://www.w3.org/2002/12/cal/ical, December 2002.|
|||Reschke, J., Reddy, S., Davis, J., and A. Babich, “WebDAV SEARCH”, Internet-Draft draft-reschke-webdav-search-06 (work in progress), August 2004.|
Cyrus Daboo and Michael Arick have provided substantial feedback for this draft.
Added section on privileges for calendaring, extending WebDAV ACL privilege set
Defined what to do with unrecognized properties in the bodies of iCalendar events, with respect to property promotion/demotion
Copyright © The Internet Society (2004). All Rights Reserved.
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 assigns.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.