RE: GULP (version 4)

Either way is fine with me.  But note that I consider that to
be a marshalling detail of the UNLOCK request (since the server
will be maintaining the lock-root, why would it care?) ... the GULP
lock semantics should apply however we decide to marshall UNLOCK.

Cheers,
Geoff

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

yes, that's what I wanted. At least it seemed to me that we had agreed on
that.


-----Original Message-----
From:  Clemm, Geoff

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? 

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

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)?

-----Original Message----- 
From:  Clemm, Geoff 

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