GULP as pure model, draft 2

This draft addresses most of Julian's comments.  Changes and todos 
suggested from this are noted in square brackets.

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

2.  A resource becomes directly locked when a LOCK request to
    the URL of that resource creates a new lock.
    The "lock-root" of the new lock is that resource. If at the time of
    the request, the request-URL is not mapped to a resource, a new
    empty resource is created and directly locked.

   [Change: Readded "empty"]
   [Todo in LOCK section: creation request MUST have a body, refresh 
request does not]
   [Todo in LOCK section: server MUST create new resource if request-URI 
unmapped]

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.

   [Todo in LOCK section: server MUST fail request if it would create 
conflicting locks]

4. For a collection that is locked with an infinite depth lock, all 
member
    resources are indirectly locked.  Changes in membership of a such a 
collection
    affect the set of indirectly locked resources:
      * If an internal member resource is added to a the collection,
    and if the new member resource does not already have a conflicting 
lock,
    then the resource becomes indirectly locked by that lock.
       * If an internal member resource is removed or deleted such that
    the resource is no longer a member of the collection, then the
    resource is no longer locked by that lock.

  [Change: clarified to be clear that this whole point discusses 
infinite depth lock on collections]

5. An UNLOCK request deletes the lock with the specified lock token,
    provided that the request is addressed to 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 certain requests.  This is the 
case
    for any request resulting in the modification of a locked resource,
    including the following aspects of the locked resource:
  	- any variant,
	- any dead property,
	- any live property which is lockable (a live property is lockable 
unless otherwise defined.)
	- 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).
   Furthermore, a lock-token must be submitted if the mapping of the 
request-URI
   changes to another resource or to no resource (e.g. DELETE).

    [Change: rewrote so that this point clearly covers all cases where 
lock-token must be submitted]
    [Change: default=lockable wording so that property definitions can 
be concise saying either "this property is not lockable" or nothing ]
    [Todo elsewhere: add "not lockable" to certain property definitions]

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.

Now to address Julian's comment that we need some of this stuff to be 
normative so that other specs can be concise (e.g. in defining 
properties as not lockable, and for lockable properties, that the 
lock-token MUST be submitted.)  I propose that most requirements belong 
in the section where a method or header is defined -- this helps us 
avoid discussions of marshalling in the model, which makes it cleaner, 
and keeps requirements together readably (e.g. all requirements about 
LOCK are in LOCK section).

Thus:
  - Normative text about LOCK request goes in the section on LOCK.  E.g. 
creating new empty resource, refresh requirements.
  - Normative text about UNLOCK request goes in section on UNLOCK.
  - Model point #7 could EITHER become normative right there in the 
model and just change "must" to "MUST"
				OR go in the section relating to marshalling of submitting lock 
tokens, which is the If header section (ick)
				OR be repeated as normative in the "Lock Tokens" section, 
presumably a sub-section after the model is introduced

Suggestions welcome...


We're still not yet at the point where GULP can be very cleanly 
introduced (although I think we're getting closer).  For example,  GULP 
uses "lock-token" before that term has been introduced.  Does that mean 
that GULP should be in RFC2518bis after the section on lock-tokens, or 
that it should be before and we should add a model point (number 5.5, 
effectively) to say that "every lock has a unique lock-token assigned 
by the server"?

Lisa

Received on Monday, 16 January 2006 19:55:25 UTC