Subject: What is actually locked?

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Apr 2004 21:04:31 +0200

Julian wrote:

> Lisa Dusseault wrote:
>
>> A - Issues relating to 2518 features
>> 1. Can you UNLOCK a URI that binds to a locked resource, when that URI
>> wasn't directly locked? If not, what's the error?
>
> I can't see any language in RFC2518 and/or BIND saying that you can't,
> so you can. UNLOCK removes the lock identified by the lock token header
> from the resource identified by the request URI, so the actual URI 
> being
> used for UNLOCK is irrelevant.
>
>> 2. Can you LOCK a URI that binds to a locked resource, when that URI
>> wasn't directly locked? If not, what's the error?
>
> You can, as long both locks are compatible (that is, none of them is
> exclusive). So the situation here is exactly as if you use the same
> request URI.

To me the above show some communication issues. It continues:

>> 3. In If header evaluation, does a URI "match" a lock token, when that
>> URI wasn't directly locked but the underlying resource was locked with
>> that token?
>
> The If header matching description
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.4.4>)
> talks about resources, not URIs, thus it's not relevant which URI you
> provide as long as it identifies the right resource.
>
>> 4. What exactly does lockdiscovery show on a locked binding? On a 
>> locked
>> resource accessed through an unlocked binding? Does 'lockdiscovery' 
>> look
>> exactly the same on every binding to a locked resource?
>
> Yes. The lock belongs to the state of the resource, so PROPFIND returns
> the same operation no matter which binding you use.
>
>> 5. What does creationdate refer to, I assume it's the creationdate of
>> the underlying resource (not the creation date of the binding)? If the
>
> Yes.
>
>> underlying resource, is there any way to tell when a binding was
>
> No.
>
>> created? and vice versa?

It seems Julian is talking about locking always being on the resource, 
regardless of what binding was used. This imply it is completely 
irrelevant what binding has happend, what URI is used etc to reach the 
resource. If the resource is locked it is.

Now, Lisa, you seem to either not agree with this view, or that the 
document doesn't specify this clearly enough.

Can you (Lisa) clarify?

    paf

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 21:30:34 +0200

Patrik Fältström wrote:

 > ...
> ...

Correct. IMHO this follows clearly from RFC2518 (specifically the 
introduction of locking (section 6) and write locks (section 7))...:

"The ability to lock a resource provides a mechanism for serializing 
access to that resource. Using a lock, an authoring client can provide a 
reasonable guarantee that another principal will not modify a resource 
while it is being edited. In this way, a client can prevent the "lost 
update" problem."

"A write lock MUST prevent a principal without the lock from 
successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, 
DELETE, or MKCOL on the locked resource. All other current methods, GET 
in particular, function independently of the lock."

BTW: at some point in the previous discussions it was claimed that 
RFC2518 uses the terms "URI" and "resource" interchangeably, and thus 
there was no explicit distinction. I disagree with that point of view. 
If there are places where RFC2518 is sloppy in this regard, we should 
identify those and try to fix them in RFC2518bis.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Apr 2004 21:38:56 +0200

> identify those and try to fix them in RFC2518bis.

If anyone remember, please let the list know.

    paf

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 5 Apr 2004 12:53:10 -0700

Patrik asked: "Now, Lisa, you seem to either not agree with this view, 
or that the document doesn't specify this clearly enough. Can you 
(Lisa) clarify?"

Yes, I've had various discussions where it seemed that if one binding 
to a
resource was locked then other bindings also had to appear locked, and
I've had other discussions where it seemed the other way.  Reading the
specification might lead a person to one conclusion, but it might lead 
them
to the other conclusion.  By now I've read the spec many times, but I 
recently
reread it carefully and tried to do so with an open mind, and I found 
that it
is unclear -- it is difficult to integrate statements from different 
sections of
the draft to come to a conclusion.  It's not merely that this is more 
work for
the reader of the spec, but it is also prone to parsing and integration 
errors.

Some of the details resulting from the lock model are even more 
definitely
unclear.  For example, can a client use UNLOCK on a binding that isn't 
the
one that was locked?  If not, what's the error?  The spec must say 
whether
a server MUST support UNLOCK on all bindings to a locked resource.

It's my belief that interoperability will suffer from the readability 
problems
in this specification.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Apr 2004 22:20:44 +0200

Lisa Dusseault wrote:

> or that the document doesn't specify this clearly enough. Can you (Lisa) 
> clarify?"
> 
> Yes, I've had various discussions where it seemed that if one binding to a
> specification might lead a person to one conclusion, but it might lead them

Well, in fact the BIND spec says almost nothing about locks; so I'm not 
sure where you see the ambiguity. BIND doesn't in any way change the 
locking model defined in RFC2518; and that locking model is about 
*resources* being locked. So yes, if a resource is locked through one of 
it's bindings, the lock will be visible (and active) for all other 
bindings as well -- again, that's a basic property of the model; 
additional bindings give you additional access paths to a single 
resource, but you're always manipulating / discovering the resource itself.

If you can point to a section in the BIND spec that suggests otherwise, 
*please* do so.

> Some of the details resulting from the lock model are even more definitely
> unclear.  For example, can a client use UNLOCK on a binding that isn't the
> one that was locked?  If not, what's the error?  The spec must say whether

The spec says in it's introduction that additional bindings just add 
additional access paths to the same resource, and that HTTP methods 
access the resource itself. Thus the access path doesn't matter, and 
UNLOCK must work on each of the bindings to the resource.

> It's my belief that interoperability will suffer from the readability 

I think the introduction section is very clear about all of this:

"A method is addressed to a URI, and the server follows the mapping from 
that URI to a resource, applying the method to that resource."

What else do we need to say here?

Regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 5 Apr 2004 14:55:06 -0700

Perhaps more to the point, the issue is irrelevant because it
deals with a server-side implementation instruction rather than
interoperability between client and server.  The client should
be relying on the answers it gets back from the server, not on
an obscure requirement on how to implement locks within the server.

Regardless of how the server implements those locks, it will
respond with success or fail such that the client will be informed
whether or not it needed the lock token.  The client never needs
to know whether the URI corresponds to a binding, so adding
bind-specific requirements merely obfuscates the protocol.

....Roy