Subject: GULP as pure model, draft 2

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jan 2006 11:55:16 -0800

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 17 Jan 2006 12:50:43 -0500

Looking better.  A few suggested changes below:

>    lock and any other lock at the same time, as these would be 

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 

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

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

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

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

This model should appear in the LOCK section.

> presumably a sub-section after the model is introduced

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

> effectively) to say that "every lock has a unique lock-token assigned 

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

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jan 2006 17:09:17 +0100

Geoffrey M Clemm wrote:
>     lock, an attempt to lock that resource with a different lock MUST fail.

...while I agree with the comment, I still think that introducing the 
term "conflicting" makes sense; I think we need it in other parts of the 
spec.

> document needs to make normative statements about locking for methods other
> PROPINSERT method is defined (that inserts values into an existing property

+1

> This model should appear in the LOCK section.

+1

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

Yes, that would make a lot of sense.

Best regards, Julian