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