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

Received on Friday, 11 October 2002 14:57:51 UTC

AltStyle によって変換されたページ (->オリジナル) /