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.
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.
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.
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).
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.
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.
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).
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.
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..
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.
WCAP has an import/export command. CalDAV does not have an equivalent command.
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).
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.