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

Mr. Demeanour wrote:
> 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 think GET and PUT should just continue to do what they do today.

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

You mean, like an HTML view? That can always be done using content 
negotiation, I'd say.

> 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!).

Sorry? It would only affect a single RFC (RFC4791), no?

Best regards, Julian