- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 30 Sep 2001 01:24:27 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
From: Lisa Dusseault [mailto:lisa@xythos.com] On Behalf Of Clemm, Geoff > The best way to explain the defined MOVE semantics for a LOCK > is to say that a LOCK is on a URL, but that it is deleted > when the resource mapped to that URL is deleted. So far I can follow; it's not a bad model. I'd append "or moved" to the end; most people will consider this different than "deleted" because we have different methods for MOVE and DELETE. I agree that is worth making explicit to avoid any confusion. I don't follow your example as well (reproduced below) because WebDAV doesn't specifically allow for one resource to be mapped by several URLs. WebDAV allows for one resource to be mapped to multiple URL's because HTTP specifically allows for one resource to be mapped to multiple URL's. In particular, section 9.6 of RFC 2616: "A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version." Therefore the locking protocol (and the rest of WebDAV) must have well defined behavior in those cases where multiple URL's do identify the same resource. Let's keep it simple and assume that a WebDAV system only maps URLs to resources 1:1. That's fine, but it is good to keep the multiple mapping scenario in mind for when someone suggests a "simpler" model that does not handle the multiple mapping scenario. That means that when a collection containing null resources is moved or is renamed, all the locks in the collection disappear, and the null resources must be cleaned up. That seems contrary to what the users would like to see happen; that's the scenario that made me rethink the way this works. The loss of the locks is inherent in a "lock is on the URL" model. The reason the "lock is on the URL" model is superior to the "lock is on the resource" model can be seen by looking at the two cases for moving a locked resource. - If the client holding the lock does the move, it can easily lock the destination collection with a new depth lock, and then perform the move (the resources will be captured by the new depth lock). - If some other client not holding that lock does the move (if it is a shared lock, for example), there often is no good way for for the client to "find" the resource after it has been moved (since all the client has is a URL and a lock token). While we were debating this a while back, several vendors objected to the proposal that we require a server to allow a client to easily find a locked resource by using the lock token (PROPFIND Depth:Infinity on "/" is not considered a good way :-). Also, note that the current proposal for LOCK'ing an unmapped resource (i.e. creating a real resource there) would leave those empty resources in place to be captured by the depth lock at the destination. Cheers, Geoff
Received on Sunday, 30 September 2001 01:25:00 UTC