[Ietf-carddav] Comments on draft-daboo-carddav-02
julian.reschke at gmx.de
Sun Jul 15 03:21:31 PDT 2007
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
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?
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.
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
More information about the Ietf-carddav