Subject: GULP as pure model

From: Lisa Dusseault <[email-masked]>
Date: Mon, 9 Jan 2006 19:22:46 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jan 2006 17:40:03 +0100

Lisa Dusseault wrote:
 > 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

Two general comments:

- I think removing the normative language after all is a bad idea; it 
means that specs defined on top of WebDAV that add new methods can not 
simply ignore locking and delegate it to the base spec.

- One change I expected but do not see here (at least not consequently) 
is the removal of actual marshalling considerations (such as replacing 
"A LOCK request with a non-empty body..." by "A LOCK creation request...").

Some more comments inline.

lock.
 >    the request, the request-URL is not mapped to a resource, a new

Any particular reason why "empty" was removed from the last part?

conflicting.

OK.

lock,
 >    then the resource becomes indirectly locked by that collection's lock.

That is incorrect, unless it's a Depth: Infinity lock (see original text).

 >    resource is no longer locked by that collection's lock.

Same.

 >    unmapped URL, then the lock is also deleted by that request.

I think I prefer the previous language, because it keeps things together 
that belong together (last part of 7 and 8):

- 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.
 > are quite redundant with this, and if so, whether to trim.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Jan 2006 09:00:50 -0800

On Jan 16, 2006, at 8:40 AM, Julian Reschke wrote:

> these

I don't follow this line of argument.  Do you mean an extension spec 
like bind or advanced collection or quota, or a spec that obsoletes 
this spec? How does this follow?

>
> - One change I expected but do not see here (at least not 
> consequently) is the removal of actual marshalling considerations 
> (such as replacing "A LOCK request with a non-empty body..." by "A 
> LOCK creation request...").

That seems like a good idea.

> Any particular reason why "empty" was removed from the last part?

I suppose I could argue that the model doesn't have to say what kind of 
resource is created but in reality I think I just dropped that by 
accident.

> >    and if the new member resource does not already have a 
> conflicting lock,

True enough.

> I think I prefer the previous language, because it keeps things 
> together that belong together (last part of 7 and 8):
>

I see #7 as being about "what actions require the lock token to be 
submitted" and #8 about "what happens when a lockroot is deleted".  It 
happens that deleting a locked resource is one of those actions that 
require the lock token to be submitted so that certainly belongs in #7. 
  I could phrase the item more clearly to be completely inclusive of all 
the cases.

> > are quite redundant with this, and if so, whether to trim.
thanks,
lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jan 2006 18:51:15 +0100

Lisa Dusseault wrote:
> like bind or advanced collection or quota, or a spec that obsoletes this 
> spec? How does this follow?

The former. For instance, take ACL. If the model language is normative, 
all ACL needs to define is whether the ACL properties are lockable.

>  I could phrase the item more clearly to be completely inclusive of all 

OK, I'll check then...

Best regards, Julian