Subject: Re: GULP (version 5)

From: Jason Crawford <[email-masked]>
Date: Thu, 10 Oct 2002 21:07:17 -0400

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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 11 Oct 2002 09:43:13 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Friday, October 11, 2002 3:07 AM
> To: Clemm, Geoff
> Cc: 'Webdav WG'
> Subject: Re: GULP (version 5)
> ..
>

I agree.

Like it or not, a lock has a unique URI and identity, thus it is a resource
(it may even be a WebDAV resource :-).

> ...

How about saying "is affected by a lock"?

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760