Re: GULP as pure model

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

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.

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

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

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

OK.

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

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

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

Same.

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

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

Best regards, Julian

Received on Monday, 16 January 2006 16:42:25 UTC