Subject: Question for implementors: definition of Lock with bindings

From: Lisa Dusseault <[email-masked]>
Date: Fri, 16 Dec 2005 12:02:15 -0800

In the current proposed model of locking and binding (GULP -- several 
emails recently with pointers), it's defined that a lock covers the 
binding that the LOCK request that was sent to and the resource that 
the binding maps to.

Another possible definition of the scope of a lock could be that the 
lock would cover the resource that the binding maps to and ALL 
bindings.

One consequence of choosing between these two models is the cases in 
which DELETE of a locked resource requires the lock token.  According 
to the first definition, DELETE requires a lock token only if the 
locked binding is addressed; all other bindings can be removed without 
needing a lock token.  According to the second definition, DELETE of a 
locked resource always requires the lock token.

Please answer with your model preference and reasoning so that we can 
close this issue.  We'd particularly like to know if this affects an 
implementation -- an implementation that supports BIND, or has custom 
bindings through file system links (mod_dav?), or could otherwise be 
affected.

Thanks!
Lisa Dusseault

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Dec 2005 21:48:40 +0100

> emails recently with pointers), it's defined that a lock covers the 

Rather then letting people search for these messages, why not include a 
link???

GULP: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>

> binding that the LOCK request that was sent to and the resource that the 
> binding maps to.

Actually, the URL, not the binding:

" - 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."

> lock would cover the resource that the binding maps to and ALL bindings.

Previously discussed in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1042.html>...

> which DELETE of a locked resource requires the lock token.  According to 
> the first definition, DELETE requires a lock token only if the locked 
> binding is addressed; all other bindings can be removed without needing 
> a lock token.  According to the second definition, DELETE of a locked 
> resource always requires the lock token.
> 

The effect of requiring all URLs to be protected by the lock are:

- more complexity in server
- loss of symmetry (why is it possible to add a binding without having 
the lock token, but not to remove the same binding later?)
- questionable client semantics (exactly why would a client care?? 
please provide a use case that justifies the additional requirements).

Best regards, Julian