John Barone wrote:
"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. "
 
[John] OK, I can see that; however section 6.1.4 does not make the distinction between depth 0 and depth infinity locks.  This section needs to be cleaned up to make that distinction, and spell out the exact bahavior in both cases.  Maybe combining what's in section 7. bullet 2 and what's currently in section 6.1.4.

Agreed that section 6.1 should define lock depth.
 
 
[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.
 
[John] If the target URI for a depth infinity lock request is a collection, the collection IS most certainly locked.  But to your point, if the language in section 6.1.x is cleaned up, this entire section can be removed.

The target URI of a lock request will never be a collection, but the URI of a collection. An URI is an URI and a resource is a resource. As defined in 6.1, resources can be locked. URIs can't.
 
Move/Copy behavior...
 
Well, copying locks is as undefined as lock duplication
 
How could one think that a lock could be moved if it is not defined what this could mean?
 
... by the same token, what does it mean to duplicate or move live or dead properties; those operations aren't defined either for properties, and yet you MUST/SHOULD do it.  I don't see the harm here, in fact I think it's a very good idea to explicitly state this in the spec. to remove ambiguity.  I think the copy/move MUST NOT statements should be kept either in a 7.x section, or wrapped into a revised 6.1.4 section.
Well, if the spec does not define what it means to move a property, then it should either correct this or stop to use this terminology.

Section 6.1 defines what a lock is. This is done by giving a set of "axioms", propositions using the term 'lock' which are true by convention. It should be possible to read the spec without the slightest idea what a lock could be. Let us assume that we have no such idea and read section 6.1. Then we have an understanding of what a lock is, but we would be very surprised if someone spoke of 'moving locks'. We would say something like: "Hey, wait, how can you move it if it does not even have a location?".

If one thinks that it makes sense to move a lock, he simply has an understanding of the term 'lock' that does not match the definitions in this specification. If the specification never mentioned 'moving locks', why would any reader think that this term even had a meaning?

Regards,
Manfred