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.

My main point here is the use of undefined terminology, though I indeed
think that section 6.1 will be perfectly clear on the distinction
between a depth 0 and a depth infinity lock as soon as 6.1.4 uses the
term 'member' instead of 'internal member'. 7.4 contains nothing new,
and a list of special cases can never be as concise as the general
principle itself.

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

My point here is that URIs cannot be locked. Resources can be locked,
but the root of the lock is not a resource.

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 the term lock scope was defined, section 6.1 would be the right
place IMHO. But since we already have the lockscope element (which is
something completely different), this would be very confusing. One can
always replace the wording "resource x is in the scope of lock y" with
"resource x is locked by lock y".

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.

Well, copying locks is as undefined as lock duplication.

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.

How could one think that a lock could be moved if it is not defined
what this could mean?

- 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