rfc2518bis-14: locking terminology

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

Received on Wednesday, 15 March 2006 22:48:52 UTC