- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Mar 2003 09:30:51 +0100
- To: "Brian Korver" <briank@xythos.com>, "WebDAV" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 2:34 AM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > > The only argument for not doing so is that being more > > specific probably requires including the entire GULP > > document, since that is needed to clearly define the difference > > between locking a resource and protecting a URL. > > But I don't think we want to include that information by > > copy in each protocol extension document, so I think it > > is more appropriate to get it into 2518bis, and refer to > > it from the other documents. > > > > Cheers, > > Geoff > > Geoff, > > As GULP frequently defines things in terms of bindings, > the text as-is seems more appropriate to the binding > spec. Strong disagreement. The way to "fix" this is either to add the term "binding" to RFC2518, or to use the term "internal member" instead (which *will* make the text harder to read). Let's see: -- - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a binding (1) to a resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing a binding (2) to the resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - 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 for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or a binding (3) 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 directly locked resource 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 deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. --- So, (1) "binding to a resource" -> "internal member" (2) "binding to the resource" -> "internal member URL identifying that resource" (3) "binding of a locked collection" -> "internal member URL in a locked collection" should be equivalent, just using RFC2518 terminology. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 5 March 2003 03:31:01 UTC