Re: BIND, was: [Bug 85] clarification of live property behaviour vs namespace ops needed

Sounds good to me.

Cheers,
Geoff

Julian wrote on 12/17/2005 06:40:38 AM:

> 
> Hi.
> 
> With the inclusion of the proposed text below in RFC2518bius, we'd be 
> closing an issue that was raised in spring while discussing BIND. In the 

> subsequent discussion (summarized in 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-
> properties-latest.html>) 
> we found that it's not a problem specific to BIND at all, because it 
> applies to any operation that creates new resources or moves them.
> 
> Since then BIND has passed (a third!) working group last call, with no 
> new issues raised. So here's my current understanding of where we stand 
> with BIND. Feedback appreciated.
> 
> 1) BIND is finished, however it's currently on hold because we're busy 
> with RFC2518bis.
> 
> 2) Should the working group manage to complete RFC2518bis as planned, we 

> can slightly revise the current BIND draft, taking out stuff that's not 
> needed anymore, namely 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
> html#rfc.section.1.3> 
> ("preconditions and postconditions"), parts of 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
> html#rfc.section.2.4> 
> (discussion of broken DELETE semantics of RFC2518bis), and parts of 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-12.
> html#rfc.section.8.2> 
> (introduction of "DAV" request header). As these changes would be purely 

> editorial, I'll assume we wouldn't want to do another WGLC.
> 
> 3) On the other hand, should the working group fail to finish 
> RFC2518bis, we'll submit BIND as is.
> 
> 
> Best regards, Julian
> 
> 
> 
> 
> 
> 
> bugzilla@soe.ucsc.edu wrote:
> > http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=85
> > 
> > 
> > 
> > 
> > 
> > ------- Additional Comments From julian.reschke@greenbytes.de 
> 2005-12-17 03:25 -------
> > OK, I believe I have completed my changes. As usual, see them in 
context at
> > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-
> latest.html#rfc.issue.bz085>
> > 
> > 
> > In Section 8, NEW:
> > 
> >  8.1.6  Impacts of Namespace Operations on Cacheability
> > 
> >     Note that the HTTP response headers "Etag" and "Last-Modified" 
(see
> >     [RFC2616], Sections 14.19 and 14.29) are defined per URL (not per
> >     resource), and are used by clients for caching.  Therefore servers
> >     must ensure that executing any operation that affects the URL
> >     namespace (such as COPY, MOVE, DELETE, PUT or MKCOL) does preserve
> >     their semantics, in particular:
> > 
> >     o  For any given URL, the "Last-Modified" value must increment 
every
> >        time the representation returned upon GET changes (within the
> >        limits of timestamp resolution).
> > 
> >     o  For any given URL, no "ETag" value must ever be re-used for
> >        different representations returned by GET.
> > 
> >     In practice this means that servers
> > 
> >     o  may have to increment "Last-Modified" timestamps for every
> >        resource inside the destination namespace of a namespace
> >        operation, and
> > 
> >     o  similarily, may have to re-assign "ETag" values for these
> >        resources (unless the server allocates entity tags in a way so
> >        that they are unique across the whole URL namespace managed by 
the
> >        server).
> > 
> >     Note that these considerations also apply to specific use cases, 
such
> >     as using PUT creating a new resource at a URL that has been mapped
> >     before, but has been deleted since then.
> > 
> >     Finally, WebDAV properties (such as DAV:getetag and DAV:
> >     getlastmodified) that inherit their semantics from HTTP headers 
must
> >     behave accordingly.
> > 
> > In the description for DAV:getetag:
> > 
> > OLD:
> > 
> >     COPY/MOVE behaviour:  This property value is dependent on the 
final
> >        state of the destination resource, not the value of the 
property
> >        on the source resource.
> > 
> > NEW:
> > 
> >     COPY/MOVE behaviour:  This property value is dependent on the 
final
> >        state of the destination resource, not the value of the 
property
> >        on the source resource.  Also note the cacheability 
considerations
> >        in Section 8.1.6.
> > 
> > In the description for DAV:getlastmodified:
> > 
> > Section 14., para. 56:
> > OLD:
> > 
> >     COPY/MOVE behaviour:  This property value is dependent on the last
> >        modified date of the destination resource, not the value of the
> >        property on the source resource.  Note that some server
> >        implementations use the file system date modified value for the
> >        DAV:getlastmodified value, and this is preserved in a MOVE even
> >        when the HTTP Last-Modified value SHOULD change.  Thus, clients
> >        cannot rely on this value for caching and SHOULD use ETags.
> > 
> > NEW:
> > 
> >     COPY/MOVE behaviour:  This property value is dependent on the last
> >        modified date of the destination resource, not the value of the
> >        property on the source resource.  Also note the cacheability
> >        considerations in Section 8.1.6.
> > 
> > Note that tis particular change removes language that contradicts 
> RFC2616 (we
> > can't simply tell people that RFC2616 doesn't count anymore, at least 
not
> > without strong WG consensus).
>