W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2007

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

From: Elias Sinderson <elias@soe.ucsc.edu>
Date: Mon, 16 Jul 2007 09:32:54 -0700
Message-ID: <469B9DB6.1070404@cse.ucsc.edu>
To: Cyrus Daboo <cyrus@daboo.name>
CC: Julian Reschke <julian.reschke@gmx.de>, ietf-carddav@osafoundation.org, WebDAV <w3c-dist-auth@w3.org>

Cyrus Daboo wrote:
> --On July 15, 2007 12:21:31 PM +0200 Julian Reschke 
> <julian.reschke@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. [...] 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.
> [...] 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?
I believe that this is a most sensible idea -- the creation of new 
protocol methods to operate on resource types is Really Bad (TM) and 
defining a generic, extensible solution that supports domain specific 
MKxxx behavior is clearly preferred. Extending MKCOL with semantics 
covering the optional inclusion of a request body containing properties 
would seem like a very reasonable starting point in this.

It would further be my preference to see the above specified prior to 
pushing CardDAV along the RFC track.

Received on Tuesday, 17 July 2007 18:11:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC