- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 18 Mar 2004 22:58:26 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, Webdav WG <w3c-dist-auth@w3c.org>
Lisa Dusseault wrote: >> That is correct. If the etags on the rebound (or moved) resources >> satisfy etag semantics, the etags can stay the same. But they might have >> to be changed (in case there previously was a resource at the destination >> of the REBIND MOVE with that etag but with different content), so you >> can't >> infer whether or not the etag changes as the result of a MOVE. >> > > Why couldn't the source ETag be preserved in a REBIND, even if the > destination resource is being overwritten? At the least, the spec > should say that the source ETag MAY be preserved, so that clients know > they have to handle both cases. A "MAY" doesn't really help. The issue here is that servers that do have ETags that are unique across *all* resources in the namespace will be able to preserve them. However, those that use weaker RFC2616 semantics (unique per entity body and URL) will have to ensure that namespace operations such as COPY or MOVE (or REBIND) will not cause duplicate ETags for different entities to appear. Both types of implementations exist (actually, we have both types within the same server). Now it may make sense to discuss this issue, but it's not related to BIND. As I said, REBIND and MOVE share the same considerations here. > The getlastmodified is a little more contentious. Does it mean that the > underlying resource body changed? If so, then the spec should say that > this property SHOULD NOT (or MUST NOT) change only because of a REBIND > operation. Nope. If anything, the spec should say that REBIND should behave like MOVE in this regard. In particular, I'd lean to SHOULD change, because in general there's no other reliable way to maintain RFC2616's semantics for the "Last-Modified" header. Anyway, this issue applies to all WebDAV namespace operations, and we have lived with the current under-specification since 1999. Thus having it clarified in RFC2518bis should suffice. Regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 18 March 2004 17:33:39 UTC