[Bug 85] clarification of live property behaviour vs namespace ops needed

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



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Saturday, 17 December 2005 11:25:56 UTC