Re: Etag-on-write, 4rd attempt (== IETF draft 03), was: I-D ACTION:draft-reschke-http-etag-on-write-03.txt

   Well, that's going to be dependent on the delivered format.  Many  
formats have multiple representations which are considered  
equivalent.  This includes iCalendar, which is why CalDAV's shoo-shoo- 
go-away stance on weak ETags is, well, weak.

   The example I gave, where the order of iCalendar properties changes  
within an iCalendar component, is what I have in mind in that context.


On Nov 5, 2006, at 1:29 PM, Lisa Dusseault wrote:

> Speaking for myself, my aversion is to ambiguously-defined weak  
> ETags.  You could probably define something called "Weak ETags" and  
> say more about how they work than RFC2616 does, and create something  
> useful.  I'm sure your idea of what weak ETags do is a sane one and  
> if everybody agreed we'd have interoperability.  But we've had  
> interoperability problems around weak ETags and that's the root  
> cause of my aversion.
> Lisa
> On Nov 4, 2006, at 1:33 PM, Wilfredo Sánchez Vega wrote:
>>   As a general note, I still don't quite understand the widespread  
>> aversion to weak ETags, and I think that the this editing property  
>> show why weak ETags *do* work in an authoring environment.

Received on Monday, 6 November 2006 01:54:50 UTC