- From: Mr. Demeanour <mrdemeanour@jackpot.uk.net>
- Date: Mon, 16 Jul 2007 17:19:43 +0100
- CC: w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
Julian Reschke wrote: > > So let's assume that the parts of a vCard resource would be exposed > as (potentially computed) WebDAV properties -- wouldn't the need for > the multiget report just go away? PROPFIND would be all that's > needed, then... Yes, that's correct, as far as I can see. If one did that, however, the consequence would be that the GET method would then become anomalous for CalDAV and CardDAV resources; the data that it returned would be properties masquerading as content. Similarly the PUT method would become obsolete, as any CalDAV or CardDAV content should then be set using PROPPATCH. Anyway, it seems most natural to map iCalendar/vCard properties to WebDAV properties, rather than to WebDAV content. I don't really see that as a terrible problem for CalDAV and CardDAV; GET and PUT on CalDAV/CardDAV resources could be left undefined, or those methods could be freed-up for other purposes. GET, in particular, might be used to present a rendition of the resource. The fact that GET is easy to cache, and PROPFIND and REPORT are not, would be quite consistent with that approach - returning a stale, cached version of a rendition would be a much less serious problem than returning stale (but live) property data. This all feels a bit theoretical, though; to make all CalDAV/CardDAV content become instead grade-A properties would be a pretty fundamental change in approach, affecting five or six different RFCs, and I hesitate to suggest anything that radical (without working it through properly first!). -- Jack.
Received on Monday, 16 July 2007 16:16:46 UTC