[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-13 14:16 -------
I haven't been able to finish the proposed changes for this issue, but here's
some text that could go into the introduction of section 14. I'm currently not
sure whether we should have it there, or whether it would be better just to
expand the explanations for DAV:getlastmodified and DAV:getetag. Speaking of
which, one could argue that these explanations don't belong here at all, but
should appear where the WebDAV namespace ops are defined. Feedback appreciated.


   The properties defined by this specification fall into two distinct
   categories:

   1.  Properties defined based on the values of certain HTTP response
       headers, such as DAV:getetag which is based on HTTP's "ETag"
       response header.

   2.  Other properties that not have a direct counterpart in HTTP (such
       as DAV:creationdate).

   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 namespace operations (such as COPY or
   MOVE) does preserve their semantics, in particular:

   o  For any given URL, the "Last-Modified" value must increment
      everytime 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).

   For properties defined based on HTTP GET response headers (DAV:get*),
   the value could include LWS as defined in [RFC2616], section 4.2.
   Server implementors SHOULD NOT include extra LWS in these values,
   however client implementors MUST be prepared to handle extra LWS.

   Note that all property elements can be extended according to the
   rules defined in Section 16.




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

Received on Tuesday, 13 December 2005 22:17:42 UTC