Re: ETags?

I think the heart of this issue is that the binding
specification states that live properties SHOULD have the
same value no matter what binding is used to access it.
This would imply that the getetag property SHOULD have the
same value no matter what binding is used to it.

If we agree that a resource should have the same getetag
property, no matter what binding is used to access it, then
the specification is correct as currently written, but 
I'm OK with making that statement explicitly in the spec,
since that is an etag constraint that is not stated in 2616, and
so there probably are etag implementations that do not satisfy
that constraint and that therefore should not be used with
a binding implementation.

Conversely, if we agree that a resource may have different
getetag property values when it is accessed from different 
bindings, then we should modify section 2.6 to say "unless explicitly
stated in the definition of the live property", and then
state that getetag is a property whose value can differ when
accessed from different bindings.

Cheers,
Geoff

p.s. I did get a bit of a chuckle over the 
characterization of the statement about etags 
being "buried" in section 3.11 of RFC-2616, since the
the title of section 3.11 is "Entity Tags", and that
section is only 3 paragraphs long.
Come on Roy, how did you expect folks to find that kind
of stuff if you're going to hide it away like that (:-).


Lisa wrote on 01/18/2005 09:27:34 PM:
> 
> When I first considered ETags and bindings, I assumed that all bindings 
> to the same resource MUST show the same ETag.  That came from my 
> understanding of what the ETag is used for, which is shaped by the 
> implementations I've been involved in and what they do (authoring, 
> sharing).  Note that I'm not making the naive assumption that an ETag 
> can be used to identify two bindings -- but I did make the assumption 
> that a single ETag can be recorded in order to synchronize a set of 
> bindings to a single resource.
> 
> Then I saw Brian's email, where he put forward an excellent argument 
> for why every binding MUST show its own unique ETag.  I can entirely 
> understand a server implementor reading these specs and making that 
> decision.
> 
> So if I wrote a synchronizing client (which I am), and Brian wrote an 
> authoring server (which he does), if we were guided only by the specs 
> and our interpretations, we would probably have interoperability 
> problems.  My client would probably be confused by synchronizing two 
> URLs which it knew to be bindings to the same resource but which 
> reported different ETags.
> 
> Thus, I support adding text to bindings, either limiting the ways that 
> servers can implement ETags and bindings, or explaining to clients the 
> wide range of possible implementations they might have to deal with.
> 
> Lisa
> 
> On Jan 18, 2005, at 5:32 PM, Roy T. Fielding wrote:
> 
> >
> >>> I think all this says is that if you get the same Etag for "/a" and 
> >>> "/b", you can't assume that it's the same entity.
> >>
> >> Right, that's what I believe it says too, but I think that may be
> >> counter-intuitive for some implementers -- who may in fact miss
> >> this text in 3.11 and to implement expecting that they can assume
> >> it's the same entity.
> >
> > I suggest we give them a sharp object and let evolution take its 
> > course.
> >
> > There is nothing in either specification that would lead to such an
> > assumption and no evidence that implementers have made it (at least
> > none that survived in the wild).
> >
> > ....Roy
> >
> >
> 
>