- From: Jason Crawford <nn683849@smallcue.com>
- Date: 2002年10月10日 21:07:17 -0400
- To: "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
- Message-ID: <OF800C145A.0233907C-ON85256C4E.0077660F@us.ibm.com>
On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote: > Here is a new GULP, that tries to address the points raised in the > mailing list (i.e. UNLOCK, lock state clarification, submission of > lock tokens). > > ************************** > > Grand Unified Lock Proposal (V5) > > - A lock is either direct or indirect. > > - A LOCK request places a direct lock on the resource identified by > the request-URL. The "lock-root" of the new lock is the request-URL. > > - If a collection has a direct depth:infinity lock with token X, all Actually it doesn't matter if it's direct or not in this sentence.... or is "members" a recursive term? > members of that collection (other than the collection itself) will > have an indirect depth:infinity lock with token X. In particular, > if a binding to a resource is added to a collection with a > depth:infinity lock with token X, and if the resource does not have > a lock with token X, then an indirect lock with token X is added to > the resource. Conversely, if a resource has an indirect lock with > token X, and if the result of removing a binding to the resource is > that the resource is no longer a member of the collection with the > direct lock with token X, then the lock with token X is removed from > the resource. Again, it doesn't need to be direct at the parent, just the ancestor unless "members" is recursive. > - An UNLOCK request removes all locks (both direct and indirect) that > have the lock token specified in the Lock-Token header of the request. > The request-URL of the request MUST identify a resource that > has a lock (either direct or indirect) with the specified lock token. I am uncomfortable refering to multiple locks. I've always thought of it as one lock that affects multiple resources. I'm also uncomfortable saying a resource *has* as lock as opposed to saying it *is* locked. But I have to admit that how you're saying it so far is very easy to understand. > - A lock token is "submitted" in a request when it appears in an If > header tagged-list whose tag is the lock-root of the lock. > > - If a request would modify the content or dead properties of a locked > resource, or would modify the bindings of a locked collection, the > request MUST fail unless the lock-token for that lock is submitted in > the request. > > - If a request causes a resource with a direct lock to no longer be > mapped to the lock-root of that lock, then the request MUST > fail unless the lock-token for that lock is submitted in the > request. If the request succeeds, then that lock MUST have been > removed from that resource by that request. > > - If a request would cause two different exclusive locks to appear on > the same resource, the request MUST fail. > > ************************** > Good stuff. Do you want to say what happens if you lock an unmapped URL? That leaves the issue of how much of the If header is evaluated. I'll start a seperate thread on that as Geoff requested. ------------------------------------------ Phone: 914-784-7569
Received on Thursday, 10 October 2002 21:07:59 UTC