CalDAV: Calendar Server Extensions for WebDAV by Lisa Dusseault of OSAF/Chandler (not to mention WebDAV, XMPP [aka Jabber], IMAPext, and who knows what else!) is the most exciting new calendar standard in years. It always seemed strange to me that the Calsch working group chose not to build on top of what is clearly the protocol success story of the last decade and a half, HTTP.

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…

Because WebDAV gets you some wonderful things. Built in synchronization, built in security model (WebDAV ACL + TLS), built in authentication (SASL), high quality, wildly popular, open source, freely available server (Apache), large number of existing, high quality, freely available libraries (e.g. neon), large deploy base of WebDAV aware clients (every MacOSX and Windows XP box to start with), graceful degradation to the really ridiculously huge number of clients with a HTTP stack, the list goes on. Not to mention the space is hopping; lots of people working on improving performance, security and implementations of WebDAV, and high profile projects like Subversion validating the technology. Three groups including Apple we might point out, the only company to successfully move calendaring standards forward to date.

How Does It Work?

CalDAV proposes a relatively simple solution of nested collections, a calendar collection, for each calendar an event collection, for each event collection, subcollections for the various iCalendar objects (events, todos, freebusy, journals and alarms) plus an additional collection to handle invites (iTIP)

Now doesn’t that sound refreshingly easy and level headed compared to iRIP (prophetically named), and the many year ordeal of CAP and its several stalled attempts, and weird technology choices like BEEP? You almost feel like you could sit down and write it in an evening (install mod_dav, make dirs, and go!)

Some Caveats

Well unfortunately its not quite that simple. There is language in the proposal about handling recurrence calculations which makes sense, and handling fanout which is that same damn tendency to roll scheduling into calendaring which means that nothing ever gets done. (not to mention the weird idea of backchanneling alarms from the web server to the client via XMPP) I say get a decent calendar store implemented, then talk scheduling.

Its also relies on the ordered collections extension to WebDAV (approved Thursday before last1), WebDAV ACL, and suggests DeltaV. All of which adds up to that same feeling of specification creep that we’ve seen in the XML world (think XML Schema). The problem with spec creep is it raises the bar to open source development in favor of corporate solutions, and precludes later creativity.

Still at the end of the day you would have a calendar store that supported group collaboration, unique URIs per event and calendar (really a whole RESTful webservice API), offlining, and was easy to integrate with the current crop of clients and server side implementations (at least the open source ones). And it would probably be equally applicable to the work the RDF Calendar Taskforce is doing.

I’m terribly excited about calendaring for the first time in years (Sunbird is helping as well, have you seen its nifty pub/sub over HTTP feature?)

Why am I mentioning this all now?

Because the specification is set to expire two weeks from now on May 1st, and I’m hoping it won’t die.

update: When I read over the document on more time, I noticed that notifications (aforementioned iTIP and “weird backchanneling”) are noted as an optional feature; not all event sources will be calendaring sources. Right on.

1 Not to be confused with Thursday Next