Re: Comments on draft-daboo-carddav-02

I agree with all of Julian's comments below.


Julian wrote on 07/15/2007 06:21:31 AM:

> 
> 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
>