CalDAV and WCAP comparison

The Sun Proprietary WCAP protocol is used by a variety of calendar clients to interact with the Sun Calendar Server. Just to list a few:

  • Sun CommsExpress and Portal Web clients,
  • Sun Desktop Sync software,
  • Sun Connector for Microsoft Outlook
  • Mozilla Lightning,
  • Novell Evolution,
  • Sun internal version of Namefinder,
  • ...

It is also used by partner companies like Synchronica or NotifyLink to build SyncML connectors.

Follows an attempt to compare it with the base CalDAV specification and its scheduling extension.

Data Model:

CalDAV defines calendar collections as containers for events/todos. Those collections can be organized in a hierarchical fashion, by mixing them with regular WebDAV collections although this is not a mandatory feature. Collections are identified by their http URLs, the hierarchy delimiter being the "/" character (like in a unix filesystem path).

WCAP is not hierarchical but a single user can create different calendar containers (equivalent to calendar collections) and access other user's calendar. Calendar containers are identified by their calid. So in a sense, this could be seen as a one level hierarchy.

When using WCAP, a calendar event/todo in a particular container is identified by its iCalendar UID + its container calid. When storing a new event, the UID can either be provided by the client or generated by the server.

CalDAV resources (events, todos) are identified by their http URLs (concatenation of the calendar collection URL + a unique resource name). The client is responsible for generating unique resource names. The UID of an event must be unique in the scope of the calendar collection in which it is stored but there is no relationship between the resource name and its UID.

WCAP calendars can always contain both VEVENT and VTODO when CalDAV let clients specify restrictions on the calendar component types that calendar object resources may contain in a calendar collection.

Scheduling data model:

CalDAV defines 2 special collections:

  • a scheduling outbox which is used (http POST command) to send calendar invitations to other users (iTIP REQUEST) or to respond to other user's invitation (iTIP REPLY). It is also the repository for the history of iTIP sent messages.
  • a scheduling inbox where calendar invitations or responses are received.

In other words, the organizer POST his invitation in his scheduling outbox, specifying a list of recipient and the server asynchronously creates a copy of this invitation in each of the recipient's scheduling inbox. The recipient list does not necessary match the ATTENDEE list in the iTIP REQUEST.

Invitations are sent to users and do not target particular calendar collections. It is the client responsibility to copy a received invitation to a regular calendar collection if the end user decides to accept it although a server implementation may choose to have an option to auto accept/decline invitations under particular circumstances (e.g. a conference room calendar disallowing doublebooking).

When using WCAP, the organizer creates the event in his own calendar and send the invitation in the same operation. The event is then copied asynchronously into each of the ATTENDEE calendar (usually their default calendar if the ATTENDEE specifies an email address). The fetchcomponents_by_range.wcap command can be used to retrieve the list of pending invitations (by using the inviteecount parameter).

Master versus fan-out model:

Both protocols are capable of returning calendar components using either a master + exceptions or fan-out (expanded) model.

Timezones and recurring events

In the CalDAV model, a client application will usually store recurring components along with their own timezone definition (as required by the iCalendar specification). When using the fan-out model to retrieve an event, the DTSTART/DTEND properties are translated to UTC time. When using the master+exceptions model, the event DTSTART/DTEND properties are expressed using their original local time (and the timezone definition is returned along with the event).

On the other hand, WCAP let clients specify only a known (server managed) tzid. This tzid will be used to calculate the instances of the recurring events in the fan-out model. When using the fan-out model to retrieve an event, the DTSTART/DTEND properties are translated to UTC time. When using the master+exceptions model, the event DTSTART/DTEND properties are also translated to UTC time, the tzid being mentioned only as an X- property (X-NSCP-DTSTART-TZID).

WCAP has a command to retrieve all the timezone definitions known by the server (get_all_timezones.wcap). Adding or modifying those timezones is an administrative task. CalDAV has no equivalent command (it is not really needed) although it does not prohibit storing resources containing only VTIMEZONE components.

Component modification:

WCAP let client applications change individual properties on components or even single instances of recurring components. CalDAV clients must send the whole resource (Timezone definition + master + all exceptions), even if only one property of a single instance needs to be modified.

Queries:

Both protocol allows for querying a calendar (or a list of calendars in the case of WCAP) by time range and on the content of certain properties.

WCAP has a fetchcomponents_by_lastmod.wcap command which is more or less missing from CalDAV (one could do a timerange query on the LAST-MODIFIED ical property but this value may come from the client).

Delete log:

 When components are deleted using WCAP (delete\*_by_id.wcap, delete\*_by_range.wcap), the server has an option to keep a "lightweight" copy of the deleted components for some configurable time. Those deleted component can then be retrieved by clients using the fetch_deletedcomponents.wcap command.

WebDAV/CalDAV misses this functionality. This makes calendar synchronization more difficult and verbose in terms of data exchanged over the wire.

 Authentication:

 WCAP has a login/logout command and a notion of session id that must be passed in each command while CalDAV relies on the authentication mechanism defined by HTTP and hence is truly stateless.

Access Control:

Both protocols have a solid access control model although WCAP is currently lacking support for group ACL.

Both protocols allow to lookup users based on their name or email address (get_userprefs.wcap versus DAV:principal-property-search REPORT).

Calendar Subscriptions

WCAP let end users build and store a list of calendar subscriptions that can be retrieved by any calendar client (list_subscribed.wcap). CalDAV misses this functionality. 

Attachments:

WCAP 3.0 now let client store attachments along with calendar events/todos. A particular attachment is linked to an event and hence is automatically deleted when the event is deleted. On the other hand, CalDAV puts the responsibility on the client to store and clean up orphan attachments.. 

Locking:

 WCAP does not have any notion of locking à la WebDAV. On the other hand, it seems that very few CalDAV clients (if any) actually leverage this functionality of the protocol.

Import/Export:

WCAP has an import/export command. CalDAV does not have an equivalent command.

Data Output:

WCAP can output calendar components in a proprietary XML format.

Both allow a client application to choose which properties should be returned although WCAP has less flexibility (attrset parameter in fetchcomponents_by_range.wcap).

Freebusy queries:

Both protocols offer freebusy query commands, either on individual calendars or on a predefined list of calendars which are part of a user freebusy time.

WCAP is using a simple GET command which is easy to generate/consume (e.g. by Microsoft Outlook) when compared with the CalDAV REPORT command.

Comments:

Thanks for this interesting comparison of the two protocols. Some comments (from the persepective of one of the co-authors of CalDAV):

- As a general point it is true that CalDAV is not as advanced as some existing protocols - we anticipate over time that there will be additional extensions to cover some of the missing functionality. In particular smarter synchronization is important. Most of these extension will be WebDAV-generic - i.e. designed for use beyond just CalDAV servers - as many of the problems are relevant to WebDAV/HTTP as a whole.

- On 'Component modification': there has been a proposal for an HTTP PATCH extension that would allow sending a "diff" of data to the server to change parts of an existing resource. Such an extension could be used by CalDAV clients to change individual properties/parameters etc in calendar data. PATCH is obviously very important when you have inline attachments that can be large.

- On 'Queries': the WebDAV DASL extension defines a way to query WebDAV properties and could be supported for this. Also a synchronization capability (REPORT) could be defined to operate on last-modified etc

- On 'Delete log': yes a synchronization capability is important. I actually wrote a REPORT for sync'ing into the CardDAV spec (vCards over WebDAV) to test the waters on this. But I believe a more generic WebDAV collection syncronization capability should be defined.

- On 'Calendar Subscriptions': there has been some discussions in the Calendaring & Scheduling Consortium (Calconnect) about such a feature. Ideas include a property on either the principal resource or calendar home resource to list subscriptions. But arguably this is a client preference and perhaps should better be handled by a generic server-side client preferences capability. The XCAP protocol might be one solution for that. BTW Sun should join Calconnect :-)

On 'Import/Export': many servers have chosen to treat a GET on a calendar collection as an "export" operation by merging all the child calendar resources into a single calendar object returned by the GET. Obviously this is a not standard practice. There is no "import" capability.

- On 'Data Output': caldav was designed to allow storing or retrieving of calendar data in other formats, with iCalendar being the default. If people come together to define a standard iCal <-> XML format then I suspect many servers would support that as well.

- On 'Freebusy queries': in caldav-schedule the free-busy query is actually a POST of an iCalendar iTIP object. There is also work going on in Calconnect's Free-Busy technical committee looking at simple free-busy URL capabilities which might be extended to GET-type operations in CalDAV.

Obviously the hope with CalDAV is to provide a standards-based protocol that everyone can buy into and contribute to to build a robust platform for interoperable calendaring. Its still in its early stages, but we are seeing more and more adoption. I certainly hope that Sun can see its way to supporting it.

Posted by Cyrus Daboo on March 08, 2007 at 08:25 AM CET #

Thanks for making the post more thorough. I should have added that my goal was not to demonstrate that WCAP is more advanced. I'm convinced that CalDAV is the way to go. I just felt that this type of comparison was useful to ease the transition from one protocol to the other.

Posted by Arnaud Quillaud on March 09, 2007 at 01:52 AM CET #

Thanks for the clarity. on Data output: Is there any reason for not considering and building on xCal (iCal <->XML) ?

Posted by Sai Vedam on April 26, 2007 at 06:05 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

arnaudq

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks