GULP (version 5.1)

Reworded, to emphasize that an indirect lock is not a separate lock,
to handle LOCKing an unmapped resource, and to handle locking live
properties.

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

Grand Unified Lock Proposal (V5.1) 

- A lock either directly or indirectly locks a resource.

- A LOCK request creates a new lock, and the resource identified by
  the request-URL is directly locked by that lock.  If at the time of
  the request, the request-URL is not mapped to a resource, a new
  resource with no content MUST be created by the request.  The
  "lock-root" of the new lock is the request-URL.

- If a collection is directly locked by a depth:infinity lock, all
  members of that collection (other than the collection itself) are
  indirectly locked by that lock.  In particular, if a binding to a
  resource is added to a collection that is locked by a depth:infinity
  lock, and if the resource is not locked by that lock, then the
  resource becomes indirectly locked by that lock.  Conversely, if a
  resource is indirectly locked with a depth:infinity lock, and if the
  result of removing a binding to the resource is that the resource is
  no longer a member of the collection that is directly locked by that
  lock, then the resource is no longer locked by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that 
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock.

- 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 for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or a binding 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 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. 

- If a request would cause a resource to be locked by two different
  exclusive locks, the request MUST fail.

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