Re: ETags?

I heartily agree with everything Roy says here.

Roy: WRT your concern about the statement about live properties,
would it be OK instead to say:

    2.6  PROPFIND and Bindings
 
     Consistent with [RFC2518] the value of a dead property of a
     given resource MUST be independent of path to that resource
     submitted to PROPFIND.  The value of a live property SHOULD
     be independent of the path submitted to PROPFIND, unless
     the definition of the property explicitly states otherwise.

In other words, we are requiring live property definers to include
in the live property definition the behavior of that property in
the context of a resource being identified by multiple URLs.

Or would you prefer that the spec just say nothing about the behavior
of live properties?

Cheers,
Geoff



Roy wrote on 01/19/2005 05:08:47 PM:

> 
> On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote:
> > When I first considered ETags and bindings, I assumed that all 
> > bindings to the same resource MUST show the same ETag.
> 
> Well, that assumption was in error.  Errors happen and no amount
> of specification can prevent them.  In particular, specifying the
> internal implementation of ETag just to prevent people from making
> erroneous assumptions about the interface is contrary to the design
> of HTTP. One person's need for etags will differ from the needs
> of others.
> 
> In Apache httpd, for example, the contents of default etags are
> configurable.  Some people will want the inode and last-mod,
> other people cannot include the inode due to use of clusters,
> while still others will use an MD5 hash of a pre-generated
> response message because their content is backed by a CMS.
> There is no way for the standard to guess all of the possible
> implementations of etags.
> 
> There are two sections to consider in the bindings draft:
> 
>    2.6  PROPFIND and Bindings
> 
>     Consistent with [RFC2518] the value of a dead property MUST be, and
>     the value of a live property SHOULD be, independent of the number of
>     bindings to its host resource or of the path submitted to PROPFIND.
> 
> which I consider to be in error because live properties are owned
> by the server -- any requirement that they be consistent across
> bindings is wrong.
> 
> and
> 
>    2.7  Determining Whether Two Bindings Are to the Same Resource
> 
> which tells the implementer the right way to test for equivalence.
> 
> > 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.
> 
> No, you would have errors.  There is a difference between making a
> standard that enables interoperability and forcing implementations
> to use it correctly.
> 
> > 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.
> 
> Why do you insist on violating the basic design principles
> of an interface?  HTTP is supposed to support loose coupling
> of software systems, which means the standards cannot specify
> anything like what you describe above.  The specification is
> not the place to put tutorials on server design or lecture notes
> on potential implementations -- people can write books about that.
> 
> ....Roy
> 
>