- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 9 Mar 2003 14:11:30 -0500
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Lisa Dusseault > > Here's some initial feedback on the latest GULP. > > "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." > > Do we really want to allow an UNLOCK to an indirectly-locked > resource to remove the lock on the directly locked parent? I'd > like to know whether RFC2518 says about UNLOCK: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So I think GULP only repeats what RFC2518 has been saying all the time (BTW: this is issue UNLOCK_WHAT_URL on the open issues list). Yes, this was just echoing what appeared to be in 2518. I'd probably go with the tighter restriction (i.e. the client must issue the UNLOCK against the URL that was specified in the LOCK request), but either one is fine with me. Since this issue is already been tracked, I suggest we handle this issue independently of GULP (the change to GULP is obvious and trivial, i.e. replace "either directly or indirectly" with just "directly"). > "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." > > This doesn't mention untagged-list syntax in If header. Is a corollary > of this proposal that we remove the untagged-list syntax? Or was the > omission of untagged-list accidental? I'd prefer to keep the untagged > list syntax, so I believe this should read: > "A lock token is "submitted" in a request when it appears in an If > header." I'd prefer "when it appears in an If header tagged-list whose tag is the lock-root of the lock, or if it appears in an untagged list and the request-URL is the lock-root of the lock". I agree this change should be made, and I prefer Julian's rewording, as it is more precise. I'll post a new version of GULP with this change. > Then this paragraph, with the substitution to "internal member" > made as Julian suggested... > > "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 member URL > in a locked collection, the request MUST fail unless the > lock-token for that lock is submitted in the request." > > Being picky here, this sentence is conditional on a request > modifying "a member URL" in a locked collection. Isn't it any > modifications to the internal member, not just the URL? > E.g. this definition must encompass a PUT to a indirectly locked > internal member, as well as a MOVE. No. The *shallow* lock on a collection locks it's member URLs. If the lock on the collection isn't deep, you can modify internal members without the lock token, as long as you don't change their name (affecting the state of the collection itself). Julian is correct. If the lock is deep, then the first phrase of of this section handles the lock on the content of the member resource. Cheers, Geoff
Received on Sunday, 9 March 2003 14:11:51 UTC