GULP as pure model

This is an attempt to rewrite GULP purely as a model for inclusion in 
the introductory section of RFC2518bis. Mostly that meant rewording 
requirements in terms of statements about the model.  Also recall a 
couple weeks ago I brought up a couple wording issues with GULP -- 
these are addressed here too. Another notable change is that the last 
point (from the last version of GULP) was moved to #3, as I thought 
"conflicting lock" was a required concept before discussing how a new 
member of a locked collection may have a conflicting lock.

1.  A lock either directly or indirectly locks a resource.

2.  A LOCK request with a non-empty body 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 is created.

3. A resource cannot be directly or indirectly locked with an exclusive
    lock and any other lock at the same time, as these would be 
conflicting.

4. 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.  Changes in collection membership
    affect the set of resources indirectly locked by the lock:
      * If an internal member resource is added to a locked collection,
    and if the new member resource does not already have a conflicting 
lock,
    then the resource becomes indirectly locked by that collection's 
lock.
       * If an internal member resource is removed or deleted such that
    the resource is no longer a member of the locked collection, then the
    resource is no longer locked by that collection's lock.

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

6. A lock token is "submitted" in a request when it appears in an If
    header.

7.  A lock-token must be submitted in a request if that request would
    modify any of the following aspects of a locked resource:
  	- any variant,
	- any dead property,
	- any live property (unless otherwise specified for that property),
	- for a collection, an internal member URI (an internal member
	URI of a collection is considered to be modified if it is added,
	removed, or identifies a different resource).
   In addition, the lock-token must be submitted if the request-URI
   mapping changes to another resource or to no resource (e.g. DELETE).

8. If a request causes the lock-root of any lock to become an
    unmapped URL, then the lock is also deleted by that request.


Other changes to make to RFC2518bis subsequently:
  - define which properties are not lockable (lockdiscovery?)
  - Check for any missing requirements derived from this model and add 
them under LOCK, UNLOCK, or other sections
  - Refer back to these model statements by number if that seems 
appropriate.
  - Consider whether there are statements in the lock introduction that 
are quite redundant with this, and if so, whether to trim.

Comments?

Lisa

Received on Tuesday, 10 January 2006 03:23:00 UTC