Re: rfc2518bis-14: locking terminology

I agree with all the points Manfred makes in this email, as well
as the points that he made in his earlier review message.

Cheers,
Geoff

Manfred wrote on 03/15/2006 05:48:49 PM:
> 
> Hi,
> 
> While the new lock model, as presented in section 6.1, seems appropriate
> to define the terminology needed to deal with locking, I think that the
> spec should try to avoid falling back to language that is not covered by
> section 6.1:
> 
> - Section 6.9:
> > A resource may be made available through more than one URI. A lock 
> > MUST cover the resource as well as the URI to which the LOCK request 
> > was addressed. The lock MAY cover other URIs mapped to the same 
> > resource as well.
> It is undefined what it means for a lock to cover an URI. As far as I
> can tell, this section can be dropped without doing harm.
> 
> - From section 7.3:
> > WebDAV provides the ability to lock an unmapped URL in order to 
> > reserve the name for use.
> Since it is undefined what it means to lock an URI, I would rephrase
> this: 'WebDAV provides the ability to create a lock by submitting a LOCK
> request to an unmapped URL.'
> 
> - From section 7.4:
> > A "Depth 0" write lock on a collection protects the collection 
metadata...
> It is undefined what it means for a lock to protect anything. A lock
> locks resources as defined by section 6.1. That's it.
> > With a depth-infinity lock, the root of the lock is directly locked
> No, since the root of the lock is an URI.
> > Any indirectly locked resource moved out of a locked source collection 

> > into a depth-infinity locked target collection remains indirectly 
> > locked but is now within the scope of the lock on the target 
> > collection (the target collection's lock token will thereafter be 
> > required to make further changes).
> The term 'lock scope' is undefined yet. Why not simply say that the
> resource is locked?
> > If a lock request causes the URL of a resource to be added as an 
> > internal member URL of a depth-infinity locked collection then the new 

> > resource MUST be automatically added to the lock. This is the only 
> > mechanism that allows a resource to be added to a write lock. Thus, 
> > for example, if the collection /a/b/ is write locked and the resource 
> > /c is moved to /a/b/c then resource /a/b/c will be added to the write 
> > lock.
> It is undefined yet what it means for a resource to be added to a lock.
> I think the resource is simply locked.
> 
> - From section 7.6:
> > A COPY method invocation MUST NOT duplicate any write locks active on 
> > the source.
> Lock duplication is undefined.
> > A successful MOVE request on a write locked resource MUST NOT move the 

> > write lock with the resource.
> Moving a lock is undefined.
> 
> - From section 9.11:
> > For a successful response to this method, the server MUST remove the 
> > lock from the resource identified by the Request-URI and from all 
> > other resources included in the lock.
> Removing a lock from a resource (or from anything else) is undefined.
> The lock is deleted. That's it.
> 
> 
> Some of the undefined phrases mentioned above appear more than once in
> the text. In these cases, I have quoted only the first appearance.
> 
> Furthermore, I think that section 7 could be made significantly clearer
> (and shorter) if it concentrated on the general fact that the state of a
> write locked resource MUST not be modified by a request that does not
> supply the locktoken or was not issued by the lock creator, rather than
> listing lots of special cases that follow directly from this rule
> (together with section 6.1, of course). For example, the sections 7.4
> and 7.6 could be dropped completely, as far as I can see.
> 
> Also, I would prefer to drop all text that might raise the idea that
> there is something special about empty resources. IMHO, they are not
> more remarkable than resources with content length 42. (Well, even less,
> for those who know the magic of the number 42 :))
> 
> Finally, as I already stated in a previous mail, I would prefer the text
> concerning lock-null resources to be moved to an appendix.
> 
> Regards,
> Manfred
> 
> 
> 
> 
> 
> 
> 
> 
> 
>