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

I agree with this as well.

- Jim
On Dec 17, 2005, at 7:43 AM, Geoffrey M Clemm wrote:

>
> 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).
> >