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.