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

[Julian Reschke <[e-mail]>]

Cyrus Daboo wrote:
> Hi Julian,
> Thanks for your detailed review.

And thanks for the feedback!

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

Understood. I think there's a small difference in that RFC3253 defined a 
generic framework for versioning -- which may be applicable to many use 
cases -- where Ca*DAV use it for a very specific business case. I'll 
admit that the border between "generic" and these ones is fuzzy, though.

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

I think that would be great. I think all we need is a request body (XML 
+ mime type) that will allow to specify a set of WebDAV properties, 
including the 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.
> 
> 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.

Yes, so I don't think that these concerns apply.

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

Understood, but this is related to the issue below: if the contents of 
the calendar/address resource would be exposed as *true* WebDAV 
property, a single PROPFIND would be 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).
> 
> 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.
 > ...

Looking forward to that. As this is a general WebDAV design question, 
maybe we should keep it over on this list...

Best regards, Julian