W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2004

Re: Issues remaining with Bind draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 18 Mar 2004 22:58:26 +0100
Message-ID: <405A1B82.6000001@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:29 UTC