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

Re: ETags?

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 19 Jan 2005 09:16:16 -0800
Message-Id: <D3C3381A-6A3D-11D9-BEE8-000A95B2BB72@osafoundation.org>
Cc: " webdav" <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

The need for extra specification is introduced in binding, because the  
bindings draft provides a way to identify whether two bindings map to  
the same resource.  That functionality could lead a client to take  
either valuable short-cuts or harmful short-cuts when caching ETags to  
synchronize resources.


On Jan 19, 2005, at 4:13 AM, Geoffrey M Clemm wrote:

> I agree with Julian.  This is an existing RFC-2616 issue,
> not an issue introduced by the BIND specification, since:
> - RFC-2616 explicitly states that two URIs can be mapped to the same
> resource
> - RFC-2616 is where entity tags are defined
> Therefore whether or not two URIs that are mapped to the same resource
> have the same entity tag is an existing RFC-2616 issue.
> If there is current consensus on this question, then I'm OK with
> adding a sentence to the bind specification about it.  But if there is
> not consensus (and I suspect there is not), then I believe it makes
> no sense to hold up the BIND specification because of an issue with the
> etag specification in RFC-2616.
> Cheers,
> Geoff
> Julian wrote on 01/19/2005 03:18:38 AM:
> [WRT whether or not the etag SHOULD/MUST be the same at different
> bindings]:
>> That being said I do agree with the other comments Geoff made in
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/ 
>> 0060.html>
>> -- I'm just not convinced that BIND needs to decide either way at  
>> this 
>> stage of the standards process. Sometimes, when something is initially
>> submitted, being silent on a particular thing can be the right thing  
>> to
>> do. In particular, this seems to be an issue that actually affects
>> RFC2616 itself and possibly should be clarified there.
Received on Wednesday, 19 January 2005 17:16:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC