mnot’s blog

Design depends largely on constraints.” — Charles Eames

Monday, 3 March 2008


Filed under: HTTP Protocol Design Web Web Services

Not many people that I know outside of IETF circles realise that a new *DAV effort has started up; CardDAV.

An address book access protocol leveraging the vCard data format.
The Internet-draft draft-daboo-carddav will be the starting point.
The WG is explicitly cautioned to keep the base specification feature
set small with an adequate extension mechanism, as failure to do so
was a problem for previous PAB efforts (ACAP).

Draft-daboo looks like it’s taken a page out of CalDAV — another recent *DAV effort that is gaining traction.

All of this led me to mutter “DAV WTF?” at the IETF APPS Architecture Workshop the other week. Do we really need to give folks the opportunity to mint more application-specific methods and headers?

Interestingly, Lisa Dusseault — one of the core folks in the DAV world — blogged about this the other day;

Were I to propose CalDAV today it would probably be CalAtom — some things would be easier, some harder, but it would catch a wave instead of drifting in the tail of something that was never much of a popular wave. Oh well, we needed something then, and WebDAV gave the most leverage at the time.

I gave a big sigh of relief when I read that, and I hope that the CardDAV folks take this to heart. Some parts of WebDAV (e.g., properties; see Yaron and Larry on this) deserve to be taken out back and shot — although, as Lisa says, they were necessary because of the state of the art at the time. That doesn’t mean we can’t do better now.


Julian Reschke said:

Hi Mark.

First of all, many parts of CalDAV received lots of criticism; even in WebDAV land – for instance for inventing non-generic methods (MKCALENDAR), and introducing yet another layer of “pseudo” properties.

On the WebDAV mailing list we discussed the strategy for CardDAV a few months ago, and the conclusion was not to invent another MKwhatever, but just use WebDAV’s MKCOL the way it was supposed to be. See and I’m not sure whether it re-uses CalDAV’s pseudo property stuff (will have to check that).

Bashing WebDAV certainly is popular, yet I seldom see concrete proposals how to do things better that actually get used, instead of being mentioned once in a while on a mailing list.

Putting medata into the document certainly is a good thing when it’s possible (MP3, JPG are very good examples), but it requires clients to handle many separate formats. WebDAV’s properties can interoperate with this approach, by simply exposing the document’s metadata as WebDAV properties, and putting the intelligence into the server.

That being said, here

is a proposal that tries to solve two of major problems with WebDAV properties, being addressing (no URIs) and cacheability.

Best regards, Julian

Monday, March 3 2008 at 7:28 AM

James said:

Instead of inventing another address protocol, what about a) GroupDAV b) LDAP c) Web3S?

Monday, March 3 2008 at 10:00 AM

Paul Downey said:

I must say I dislike DAV in theory and practice, but find it difficult to argue against the easy availability of utility Web DAV hosting, on .Mac through to sharepoint and Exchange behind the firewall. Let’s hope such an ecosystem arises and thrives for APP, beyond the embraced and extended Google Base, and soon!

Saturday, March 8 2008 at 2:45 AM

Julian Reschke said:


Instead of inventing another address protocol, what about a) GroupDAV b) LDAP c) Web3S?

The answer to b) is supposed to be

WRT c) – as far as I can tell, Microsoft has decided to use AtomPub instead of Web3S.

The trouble with GroupDAV seems to be its status – the latest draft (01, see is from November 2004. That being said; it’s certainly valuable to make vcarddav as simple as possible, contrary to what was done in CalDAV.

People interested in this should subscribe to the vcarddav mailing list (see, and potentially join the WG meeting on Tuesday, March 11 (through XMPP and audio cast, see instructions at

BR, Julian

Monday, March 10 2008 at 11:52 AM

Creative Commons