RE: GULP (version 4)

That is covered by the rule:
- If a request would remove a lock from a resource, the request MUST 
  fail unless the lock-token for that lock is specified in the 
  request. 

So, yes, you can use /b is the request-URL for the UNLOCK, as long
as you submit the lock-token for the lock.

Did you want to require that the request-URL of the UNLOCK be /a?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]

Geoff,

maybe now it's *too* simple...

I am missing rules that tell me which request URIs I can submit an UNLOCK
request to.

For instance,  let /a and /b bindings to the same resource, which was
exclusively locked on the URI /a. Can I unlock /b (using the lock token I
get via DAV:lockdiscovery)?

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Clemm, Geoff
Sent: Monday, October 07, 2002 2:51 PM
To: 'Webdav WG'
Subject: GULP (version 4)


We are about to submit a new ID for the BIND extension, and as part of 
that work, we are verifying that locking semantics is clearly defined 
in the presence of multiple bindings to a single resource.  The last 
time we were working on locking for the bind proposal (about 2.5 years 
ago :-), I submitted a series of GULPs (Grand Unified Locking 
Proposals), the last of which was V3: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0061.html>. 
The most complex part of this proposal was capturing the semantics 
of lock-null resources (and was a significant factor in my crusade 
agains them :-).  Happily, now that we have cleaned up locking by 
removing lock-null resources, we can also significantly simplify 
the description of write-lock semantics: 
************************** 
Grand Unified Lock Proposal (V4) 
- 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 request causes a resource with a direct lock to no longer be 
  mapped to the lock-root of that lock, then that lock MUST be removed 
  from that resource. 
- If a collection has a direct depth:infinity lock with token X, all 
  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. 
- If a request would modify the content, dead properties, or bindings 
  of a locked resource, the request MUST fail unless the lock-token 
  for that lock is specified in the request. 
- If a request would remove a lock from a resource, the request MUST 
  fail unless the lock-token for that lock is specified in the 
  request. 
- If a request would cause two different exclusive locks to appear on 
  the same resource, the request MUST fail. 
************************** 
If you have any locking use cases (no matter how obscure or unlikely) 
that are not properly covered by this proposal, please let me know. 
We're especially interested in obscure multiple binding use cases, 
such as cyclic bindings. 
Cheers, 
Geoff