Re: GULP as pure model

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

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

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.

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

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.

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

True enough.

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

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.

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

Received on Monday, 16 January 2006 17:01:07 UTC