GULP (version 5)

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

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

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

**************************