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

[Cyrus Daboo]

Hi Julian,
Thanks for your detailed review.

--On July 15, 2007 12:21:31 PM +0200 Julian Reschke <julian.reschke at gmx.de> 
wrote:

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

Note that it was actually RFC3253 that let the cat out of the bag (so to 
speak) wrt new methods for creating collections (MKWORKSPACE and 
MKACTIVITY). In CalDAV We chose to be consistent with that approach by 
having MKCALENDAR, and hence CardDAV has MKADDRESSBOOK.

However, I do agree that this is not an ideal state of affairs. If there is 
consensus in the WebDAV community to do so, I agree that we should write up 
a formal extension to MKCOL that would cover all the other MKxxx's 
behaviors. However, I do not believe that belongs in CardDAV, it should be 
a separate extension that CardDAV can itself leverage. I would be happy to 
put a spec together on that (extracting the behaviors from the existing 
specs).

What do others thinks about this?

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

CalDAV has proved (to me at least) that multiget is a big win for both 
server and  client. Perhaps other implementers can also comment.

Its a win for several reasons including:

1) Cutting down on roundtrips. We did have discussion about why pipelining 
is not reliable in the PATCH extension thread on the HTTP list, though in 
this case we are only dealing with GETs.

2) multiget allows both the data and properties to be returned in one go: 
i.e. it is the equivalent of a GET and a PROPFIND.

3) It is much more efficient for a server to process a single request for a 
bunch of resources than to do separate requests. Whilst this ma admittedly 
be implementation specific, I can tell you that being able to cache certain 
things during the multiget is handy (e.g. only having to calculate the 
inherited aces that propagate down to all child resource of the same 
collection once, or being able to do a single DB query for all properties 
in one transaction rather than multiple ones for each resource).

Bottom line is I think multiget is vital to performance and should remain 
in.

That said, perhaps a more generic "multiget" behavior could be done that 
would be applicable to WebDAV as a whole. Really all multiget is is a 
PROPFIND that targets specific resources - with the one addition of the 
"pseudo" resource body property (which is the only thing that differs 
between CalDAV and CardDAV).

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

Well CardDAV and CalDAV are special cases of a generic WebDAV server. So I 
don't see this as being a big issue. There are reasons for doing things the 
way they are and I will address those in more detail in a follow up to your 
more detailed review posted to the CardDAV list.

-- 
Cyrus Daboo