- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 2 Oct 2001 15:13:48 +0200
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > 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. Well, RFC 2518 Ch. 6 says: "The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantuee that another principal will not modify a resource while it is being edited..." This gave me the impression that locks are on a resource and not on one particular URL of that resource. I agree that multiple URL and deep locks on collections provide some interesting challenges to define consistent behaviour. But I find it a little bit hard to give up the assumption locking resource == locking resource content + properties So, maybe I have misunderstood this thread? //Stefan
Received on Tuesday, 2 October 2001 09:13:30 UTC