W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Summary of ETag related issues in RFC2518bis

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 22 Dec 2005 09:00:24 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF50C153AA.FFFB6585-ON852570DF.004C9C52-852570DF.004CFE3F@us.ibm.com>
I agree with Julian that this is not something we should try to resolve
in 2518bis, and given the need to focus this group on 2518bis, 
I will restrain myself from using up any additional working group 
bandwidth
on this (from my perspective, interesting) topic until 2518bis (and BIND)
is finalized.

Cheers,
Geoff


Julian wrote on 12/22/2005 01:30:46 AM:
> > Let me ask the  converse question: If the server has the file, why
> > can't it send the etag?  That's all the spec is saying it should do.
> 
> 1) RFC2518 isn't saying it
> 2) RFC2616 doesn't say what that means (or if it does it's doing that in 

> such a vague way that reasonable people disagreed about what it means)
> 3) The most widely deployed servers do not return an ETag (IIS 5.1, does 

> anybody know about IIS 6), or return a weak ETag first
> 
> So this would be a normative change introducing a less-than-well-defined 

> requirement, which doesn't even reflect what most servers do today.
> 
> So my proposal is to resolve 2) first, and then discuss an extension of 
> RFC2518 that relies on it (conceivably containing other stuff like the 
> requirement to store arbitrary dead properties and such). I really don't 

> see how we can get this done in the time that has been allocated to us.
Received on Thursday, 22 December 2005 14:00:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT