Re: ETags?

A client cannot take such short-cuts unless the etag specification
states they can take those short cuts.  There is nothing in the etag
specification that allows them to make that assumption, and therefore
as Greg has pointed out, it is just an implementation error if they
base their implementation on something other than the specification.

Perhaps we should also state that the last segment of the etag does
not have to match the current modification date, to make sure they do
not optimize their implementation by making that assumption?  (:-)

Cheers,
Geoff

Lisa wrote on 01/19/2005 12:16:16 PM:

> 
> 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.
> 
> Lisa
> 
> 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.
> >
> 
>