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

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

Received on Saturday, 17 December 2005 11:42:40 UTC