- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 21 Jun 2006 02:16:09 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>, ietf@ietf.org, Ted Hardie <hardie@qualcomm.com>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
Lisa Dusseault schrieb: > > On Jun 20, 2006, at 10:27 AM, Wilfredo Sánchez Vega wrote: > >> Not really, no. >> >> HTTP defines ETag. An HTTP server should be able to use the same >> ETag logic on all HTTP resources, and not treat ETags for calendar >> resources differently than others. Not all users of ETags are going >> to be aware that calendar resources are special. >> >> My concern is that if there is *any* inconsistency between the >> general solution when it comes and CalDAV's, that an implementor may >> have to choose between being compliant with CalDAV or the more general >> ETag spec, or may have to continue to implement special semantics on >> calendar resources for purposes which are better served by the other >> spec. >> >> I realize that "the other spec" doesn't exist today, and that this >> is a total drag. Can't we take your one paragraph and put it into its >> own document? I don't know IETF process very well, so I don't know >> what the next steps should be, but as an implementor, I'm >> uncomfortable with the prospect of dealing with two independently >> written specifications for the same behavior. > > We basically tried that. What it turned into was this > <http://www.ietf.org/internet-drafts/draft-whitehead-http-etag-00.txt> > with no consensus on the basic model or apparent drive to come to > consensus. Got any feedback on that draft? It's a shame we didn't make progress on that, but that doesn't invalidate the approach taken (making this an issue orthogonal to WebDAV, CalDAV or Atom). Best regards, Julian
Received on Wednesday, 21 June 2006 00:22:56 UTC