Lisa Dusseault wrote:
>
>
> 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?
The former. For instance, take ACL. If the model language is normative,
all ACL needs to define is whether the ACL properties are lockable.
>> > 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.
OK, I'll check then...
Best regards, Julian