Re: BIND and live property value consistency

I agree with Julian.

For folks that may have missed Julian's previous explanations, if:
- a resource at /x/foo.html has getlastmodified value of 57
- a resource at /y/bar.html has getlastmodified value of 48,
- /x/foo.html is deleted
- BIND creates a second binding to /y/bar.html at /x/foo.html.
then:
- the getlastmodified value of /y/bar.html must be updated to be
at least 49.

This is illustrative of the general principle that the behavior
of properties should be defined without trying to treat multiple
bindings as a special case (i.e. any implementation that satisfies
the definition of that property should be acceptable, and shouldn't
be constrained by some "implementation advice" in the BIND specification).

Cheers,
Geoff

Julian wrote on 07/06/2005 12:18:30 PM:
> 
> Lisa Dusseault wrote:
> > 
> > Sure; how about this?  The general requirement and specific 
requirement 
> > don't have to be in the same place in the document so I've called them 

> > out  separately.
> > 
> > General requirement: "All live properties defined in RFC2518 MUST have 

> > the  same value across all bindings to the same resource. "
> > 
> > Specific: "The DAV:getlastmodified property MUST change when the 
> > underlying resource body is altered.  The property value MUST NOT 
> > change  when a new binding to the resource is created or when a 
binding 
> > to the  resource is removed.  If a collection has a 
DAV:getlastmodified 
> > property  then its value SHOULD change whenever its set of bindings 
> > changes  (including new bindings, removed bindings or bindings where 
the 
> > name or  target changes).  "
> 
> Well, as I have explained multiple times, this doesn't reflect reality. 
> Servers *do* have to change the lastmodified date because of namespace 
> operations; otherwise it will loose it's HTTP-2616-defined semantics.
> 
> > ...
> 
> Best regards, Julian
>