RE: rfc2518bis-14: locking terminology

"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.
 
 
 
[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.
 
 
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.
 
-John


 
 



  _____  

From: Manfred Baedke [mailto:manfred.baedke@greenbytes.de] 
Sent: Thursday, March 16, 2006 8:36 AM
To: John Barone
Cc: w3c-dist-auth@w3.org
Subject: Re: rfc2518bis-14: locking terminology


John Barone wrote: 

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