Subject: rfc2518bis-14: locking terminology

From: Manfred Baedke <[email-masked]>
Date: Wed, 15 Mar 2006 23:48:49 +0100

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 15 Mar 2006 23:05:13 -0500

I agree with all the points Manfred makes in this email, as well
as the points that he made in his earlier review message.

Cheers,
Geoff

---

From: "John Barone" <[email-masked]>
Date: Thu, 16 Mar 2006 08:03:17 -0800

Comments, in-line... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Manfred Baedke
Sent: Wednesday, March 15, 2006 2:49 PM
To: [email-masked]
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:

> was addressed. The lock MAY cover other URIs mapped to the same 
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.

[John] Agree; this simplifies the wording.

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

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

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

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

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

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

[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 :))

Regards,
Manfred

---

From: Manfred Baedke <[email-masked]>
Date: Thu, 16 Mar 2006 17:35:47 +0100

John Barone wrote:

Comments, in-line...

-----Original Message-----

Hi,

- Section 6.9:

- From section 7.3:

- From section 7.4:

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.

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

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

- From section 7.6:

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?

- From section 9.11:

[John] Agreed

Regards,
Manfred

---

From: "John Barone" <[email-masked]>
Date: Thu, 16 Mar 2006 09:21:01 -0800

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

  
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:[email-masked]] 
Sent: Thursday, March 16, 2006 8:36 AM
To: John Barone
Cc: [email-masked]
Subject: Re: rfc2518bis-14: locking terminology

John Barone wrote: 

Comments, in-line... 

-----Original Message-----

Behalf Of Manfred Baedke

To: [email-masked]

Hi,

6.1:

- Section 6.9:

resource as well.

- From section 7.3:

- From section 7.4:

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. 

  

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

is locked?

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

lock.

operations.

- From section 7.6:

the source.

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:

[John] Agreed

Regards,

Manfred

---

From: Manfred Baedke <[email-masked]>
Date: Thu, 16 Mar 2006 19:24:46 +0100

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

[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

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

---

From: "John Barone" <[email-masked]>
Date: Thu, 16 Mar 2006 12:55:10 -0800

"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?"
 
[John] I still don't agree.  The basic question is if you copy a resource
has a lock, does the target resource have a lock (albeit with a different
lock-root).  The answer is "no" it doesn't, if the target is not under a
locked parent; that should be clearly stated somewhere.  Similarly a locked
resource that is MOVED, does it still have a lock?  The answer here is also
"no" it doesn't, if the target is not under a locked parent; this should
also be clearly stated somewhere.  Why not clear up ambiguity with
definitive statements?  Argue as you might, clearly there are those who
believe there is ambiguity, otherwise this language wouldn't have been
added.  BTW, this language, or something similar was in the previous 2518
spec., and I don't see a compelling reason to remove it now.
 
-John 

  _____  

From: Manfred Baedke [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 10:25 AM
To: John Barone
Cc: [email-masked]
Subject: Re: rfc2518bis-14: locking terminology

John Barone wrote: 

 

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

---

From: Manfred Baedke <[email-masked]>
Date: Fri, 17 Mar 2006 10:00:33 +0100

John Barone wrote:
> 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?".
> 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?"
>  
> [John] I still don't agree.  The basic question is if you copy a 
> resource has a lock, does the target resource have a lock (albeit with a 
> different lock-root).  The answer is "no" it doesn't, if the target is 
> not under a locked parent; that should be clearly stated somewhere.  
> Similarly a locked resource that is MOVED, does it still have a lock?  
> The answer here is also "no" it doesn't, if the target is not under a 
> locked parent; this should also be clearly stated somewhere.  Why not 
> clear up ambiguity with definitive statements?  Argue as you might, 
> clearly there are those who believe there is ambiguity, otherwise this 
> language wouldn't have been added.  BTW, this language, or something 
> similar was in the previous 2518 spec., and I don't see a compelling 
> reason to remove it now.
>  
> -John 
> 
> 

First of all, this part of my original mail was about _how_ things are 
stated, not _if_ they are stated.
There are some operations that can, by definition, be performed with a 
lock. You can create it. You can delete it. Section 6.1 defines what 
that means. But since it is not defined, you can't eat it, you can't 
take it around the block, and no, you can't move or copy it!

Second of all, when you COPY a resource A which is locked by the lock L, 
the destination resource B may of course also be locked by L, namely if 
it's a member resource of the resource which the lock root is mapped to. 
This follows immediately from 6.1.4.
So generally, after the COPY is performed, B may or may not be locked by L.

Regards,
Manfred

Regards,
Manfred

> 
> ------------------------------------------------------------------------
> *From:* Manfred Baedke [mailto:[email-masked]]
> *Sent:* Thursday, March 16, 2006 10:25 AM
> *To:* John Barone
> *Cc:* [email-masked]
> *Subject:* Re: rfc2518bis-14: locking terminology
> 
> 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 
>> 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 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 
>> ... 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.
> 
> 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?".
> 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?
> 
> Regards,
> Manfred
>