[Ietf-carddav] Comments on draft-daboo-carddav-02

[Julian Reschke <[e-mail]>]

Below are some high-level comments on draft-daboo-carddav-02 
(<http://tools.ietf.org/html/draft-daboo-carddav-02>). I'm cross-posting 
this to the WebDAV and Carddav mailing lists, but will send a separate 
mail going into some other details of CardDAV just to the CardDAV 
mailing list.



The CardDAV design essentially is the same as for CalDAV, which has 
recently been approved by the IESG and been published as RFC4791. So it 
must be good, right?

Although I do agree that CalDAV solves an interesting problem, and that 
it is likely going to work in practice, it made several design decisions 
that I think hurt it with respect to acceptance, performance and 
generality. I understand that it's very tempting to just copy over the 
design; but I think it would be really good to reconsider the points below.


Overall design / new methods

Both specs use standard MIME types, and expose data through HTTP. This 
is a good thing. They also define new subclasses of WebDAV collections, 
which add some new constraints on their contents. I'm not entirely 
convinced that this is really needed, but in this case I'll trust the 
domain knowledge from the calendaring people. I'm not sure though 
whether the constraints for address books really require this.

The introduction of new DAV:resourcetypes however has lead to the 
introduction of new HTTP methods, with the single purpose of creating a 
WebDAV collection with a certain set of properties. I think this is an 
extremely bad idea.

Now I do *not* belong to the group of people with "new method angst". 
Defining new methods that have general applicability is completely ok 
IMHO. Good examples are COPY/MOVE, some of the versioning methods, BIND 
and so on. The difference to MKCALENDAR and MKADDRESSBOOK is that these 
ones are restricted to a single application use case. So what's next? 
MKPHOTOCOLLECTION? MKMUSIKCOLLECTION?

Instead, I'd suggest defining what MKCALENDAR and MKADDRESSBOOK have in 
common, and come up with a single solution to that. For instance, such 
as MKCOL using a request body that carries a set of properties, 
including the WebDAV resource type.


Use of Reports

Everytime a new REPORT is introduced, a new set of information is made 
hard to cache. In some cases that may be harmless (such as when it's 
something like a query, line in some RFC3744 reports).

However, defining a "multiget" really seems to be a bad idea, and now 
there are even two of those! Please take this out until it can be shown 
that just sending a bunch of GET requests (which can take advantage of 
caching) is not sufficient.


Property model

The specs avoid exposing the content of their data objects as WebDAV 
properties. This leads to lots of workarounds, such as introducing 
"pseudo-properties" containing the actual content 
(CARDDAV:addressbook-data), and abuse of DAV:prop for something that is 
not a WebDAV property. Don't do this, it requires generic WebDAV servers 
to use lots of special cases. (WebDAV SEARCH started with pseudo 
properties but got successfully rid of them, so this can be done).


Best regards, Julian