RE: rfc2518bis-14: locking terminology

Comments, in-line... 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 2:49 PM
To: w3c-dist-auth@w3.org
Subject: 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.

[John] I agree, this section should be dropped; in fact, all references to
bindings should be removed from this spec.


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

[John] Agree; this simplifies the wording.


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

[John] I do not agree with this.  It's important to clearly state what the
lock behavior is on a collection.  This section is reiterating the
collection behavior outlined in the opening paragraphs of section 7. (point
2), and clarifies the distinction between depth 0 and depth infinity locks.
I think this section is important, and needs to remain as is. 


> With a depth-infinity lock, the root of the lock is directly locked
No, since the root of the lock is an URI.

[John] If the root of a lock is a collection, it's important to make clear
that that collection is locked, along with all it's decendents.  I think
this statement should stay (but perhaps reworded to be more precise).


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

[John] The point is that you need to now use the lock token of the target
collection to perform subsequent operations (that require a lock token).
Yes 'scope' is undefined, but is useful in describing the parent lock by
which the resource is now indirectly locked.  Perhaps 'scope' should be
defined earlier in the section (7.4).


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

[John] within the 'scope' of the lock target :)   This paragraph does seem
redundant with the bullet point above it.  The point here, again, being that
the resource is now iderectly locked, by virtue of the lock on the target
parent, and thus a different lock token must be used to perform subsequent
operations.


- From section 7.6:
> A COPY method invocation MUST NOT duplicate any write locks active on 
> the source.
Lock duplication is undefined.

[John] Here, simply state that LOCKs are not copied, as, say dead properties
would be.


> A successful MOVE request on a write locked resource MUST NOT move the 
> write lock with the resource.
Moving a lock is undefined.

[John] I think it's important to state this here, otherwise you might think
the LOCK is moved with the resource.  Simply state that LOCKs are not moved
with a resource, as, say dead properties would be.


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

[John] Agreed



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 Thursday, 16 March 2006 16:06:24 UTC