RE: GULP (version 5.2)

Jason suggested switching the sentence order in the second section.

************************** 
Grand Unified Lock Proposal (V5.2) 

- 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.  The 
  "lock-root" of the new lock is the request-URL. 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.  

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