Re: GULP as pure model, draft 2

Looking better.  A few suggested changes below:

Lisa wrote on 01/16/2006 02:55:16 PM:


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

I believe it is clearer to state this requirement in terms of what
operations must fail, because otherwise an implementor
could mistakenly conclude that the second
request could succeed, and just not result in a second lock.
Also, there is no need to introduce the term "conflicting"
here.  So I'd simplify this to just say:

 3. When a resource is directly or indirectly locked with an exclusive 
    lock, an attempt to lock that resource with a different lock MUST 
fail.

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

There would be no need for this ToDo if the requirement was rephrased
as suggested above.

> 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]

Should make clear that it is the same lock that indirectly locks the
members.  Also, the rule should not have an "if it does not already
have a conflicting lock" qualifier, because the reader might misinterpret
this as meaning that the lock is just not added in this case.
Also, the second clause needs to be fixed to handle the case where
the collection indirectly locks itself, so when it is removed as an
internal member, it is still directly locked.

4. If a collection is directly locked by a depth:infinity lock, all
   members of that collection are indirectly locked by that lock.
   Changes in collection membership affect the set of resources
   indirectly locked by the lock:
     * If a request causes a resource to become a member of the
   depth:infinity locked collection, then the resource becomes indirectly
   locked by that collection's lock.
     * If a request causes a resource to no longer be a member of the
   depth:infinity locked collection, then the resource is no longer
   indirectly locked by that collection's lock.


> 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:

This should be stated using normative MUST language, and I believe is
simpler/clearer if the "this is the case" is omitted.

7.  A lock-token MUST be submitted in any request that modifies any
    of the following aspects of the locked resource:


> Now to address Julian's comment that we need some of this stuff to be 
> normative so that other specs can be concise

The issue is not how precise another spec is ... the issue is that this
document needs to make normative statements about locking for methods 
other
than those defined in this specification.  For example, if a new
PROPINSERT method is defined (that inserts values into an existing 
property
value), then this model needs to normatively apply to PROPINSERT, which it
would not if the only normative language about locking 
appears in the 2518 method definitions.

> I propose that most requirements belong 
> in the section where a method or header is defined 

That fails to make this locking model normative to methods defined in 
other specs.

> -- this helps us 
> avoid discussions of marshalling in the model

Making the model normative does not require discussions of marshalling.

> which makes it cleaner, 
> and keeps requirements together readably (e.g. all requirements about 
> LOCK are in LOCK section).

This model should appear in the 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...

I suggest just making the model normative by changing "must" to "MUST"
wherever normative statements are being made in the model.

> 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"?

I suggest the latter, i.e. add the clause to the model.

Cheers,
Geoff