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

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

From: Cyrus Daboo <cyrus@daboo.name>
Date: Mon, 16 Jul 2007 11:19:17 -0400
To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org
cc: ietf-carddav@osafoundation.org
Message-ID: <C4E535EC204E5BF24F6076F0@caldav.corp.apple.com>

Hi Mr.,

--On July 16, 2007 4:06:30 PM +0100 "Mr. Demeanour" 
<mrdemeanour@jackpot.uk.net> wrote:

>> What do others thinks about this?
>
> Strongly in favour - and I agree with you that it should be separate
> from the CardDAV spec.
>
> But that doesn't force you to adopt the MKADDRESSBOOK route in the
> meantime, does it?

That is true. One option would be to keep MKADDRESSBOOK in, but if the 
MKCOL extension  spec beats CardDAV to the IESG we could remove it.

>>
>> 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.
>
> Not really; the CalDAV multiget requires the server to parse the
> resource body, because the client can ask for selected iCalendar
> properties. ASs it happens, I think that was a rotten idea, and multiget
> would be better-off without that feature.

Returning partial data is important for "low capacity" devices such as 
mobile devices, who arguably benefit the most from multiget as well. Note 
that parsing the data is an implementation issue, e.g. servers that store 
the data in a database can simply implement the the "partial data" aspect 
by doing a query for only the requested parameters etc.

-- 
Cyrus Daboo
Received on Monday, 16 July 2007 15:19:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT