Re: ETags?

I do not believe that any amount of guidance in the specification
will solve the problem of an implementor that assumes that
implementations they are familiar with define the interoperable
semantics of a feature, rather than looking to see what the
appropriate RFC says.

The only effective solution for this problem is to teach those 
implementors
to actually base their implementation on the specification.  Since this
means they actually will have to read the specification, the best way for 
us to
support that solution is to keep the specification clear and avoid
any bloat resulting from extraneous text.  In fact, sprinkling
"guidance" through a variety of specifications just encourages such
implementors to not go to the defining specification, but rather to
just assume that they "got it" from the partial information provided
by some guidance they happened to run across. 

Cheers,
Geoff


Lisa wrote on 01/27/2005 08:35:04 PM:
> 
> Well as you can see Roy, we disagree.  I would have been fairly likely 
> to implement a client that assumed that the ETag would be the same for 
> all bindings to a resource, because the servers I've worked on and 
> worked with happened to work that way.
> 
> Sometimes what an implementer knows can blind them to what could be.
> 
> Lisa
> 
> On Jan 27, 2005, at 5:29 PM, Roy T. Fielding wrote:
> 
> > On Jan 27, 2005, at 5:26 PM, Lisa Dusseault wrote:
> >
> >> Ok, then
> >>
> >> "The value of the 'getetag' property (and thus the value of the ETag 
> >> for a resource at that point in time) MAY change when a new binding 
> >> is added to a resource. Also, the value of the 'getetag' property MAY 

> >> be different for a single resource depending on which binding path is 

> >> submitted to the PROPFIND request.
> >
> > No, the getetag property and the ETag value have no relation
> > whatsoever with the bindings specification or its methods,
> > and there is no reason whatsoever to add meaningless statements
> > to reiterate that fact.
> >
> > ....Roy
> >
> 
>