- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 16 Jul 2007 18:27:51 +0200
- To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>
- CC: w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
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
Received on Monday, 16 July 2007 16:28:11 UTC