Subject: Is this LOCK model correct?

From: Alan Kent <[email-masked]>
Date: Thu, 21 Jun 2001 15:43:17 +1000

I found a discussion of LOCK and BIND in the archives which helped a lot.
But I still am trying to understand fully issues relating LOCK relating
to depth "infinity".

WebDAV talks about moving a resource under one locked collection to under
another locked collection, and the old lock being lost and the new lock
being gained. I am trying to get the semantic model in my head right.
Comments on my model below would be appreciated.

I am trying to work out if you do a LOCK with depth infinity, what is
actually locked. Are the resources locked, or the URI's to the resources?
My reading of various documents (including BIND stuff) indicates resources
are locked, not URIs. However, the concept of LOCK with depth infinity is
URI based.  Moving a resource from under one infinity lock to under another
does change the locks. But what if there is still a binding under the old
tree to the resource, does it maintain its old lock? My guess is yes.

Since some of the lock description is URI based, and other says resources
are locked, I have come to the following model of locking. Please correct
me if its wrong:

- Locks are based on URIs.

- A depth 0 lock puts a lock on that URI only.

- A depth infinity lock identifies the leading path of a URI - any URI with
  additional path components is covered by the lock as well.

- To check if a resource is locked, *all* of the URIs to the resource
  (if multiple bindings exist) must be checked against the locks that
  currently exist.

In my understanding, locks are not really associated directly with
resources because moving things to different URIs does not keep the
lock. So the lock is not independent of the URI - hence locks are
really best thought of as attached to URIs. Resources are locked
if any of the URIs to the resource is locked.

Alan

---

From: "Jason Crawford" <[email-masked]>
Date: Thu, 21 Jun 2001 02:18:26 -0400

<<
Yes, and if those locks conflict then the MOVE request must be rejected.

...

<<
Sounds right.  I believe what you've described is the best model for locks.

URI/binding protection works with this model also.

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 21 Jun 2001 08:38:14 -0400

I totally agree.  The only way to make sense of the 2518
locking semantics is to associate the lock with the URI.  Then
the *effect* of that URI lock is to restrict updates to the resource
currently
mapped to that URI, or in the case of a depth-N lock, any resource
mapped to a URI that has the locked URI as a prefix, and has no
more than N segments following that prefix.

We then overload the DELETE and MOVE methods to not only
unmap the resource at the specified URI, but also delete
the lock associated with that URI (and all locks associated
to an extension of that URI).

We can use the shorthand "write-locked resource"
to mean "a resource whose write access is
limited by a lock", but the lock itself is on a URI, not a resource
(which is why the lock does not move with the resource).

A "lock-null resource" is a mechanism (hack :-) for exposing
a lock when there is no resource currently mapped to a locked URI.

Cheers,
Geoff

-----Original Message-----
From: Alan Kent [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 1:43 AM
To: [email-masked]
Subject: Is this LOCK model correct?

Alan

---

From: "Hall, Shaun" <[email-masked]>
Date: Fri, 22 Jun 2001 10:02:01 +0100

Bits snipped, all IMHO. As usual, corrections please.

> Sent: 21 June 2001 06:43

I think the lock applies to the URIs and any descendant of it.

Imperfect example is a file system implementation. Infinite depth lock is
applied to a directory and all its descendants (sub directories and files).
Oh and of course, as HTTP/WebDAV are "root directory" based, a request with
infinite depth lock on root (if permitted) would lock the entire server. Yes
this does have uses, e.g. an administrator wants to perform a backup but
nobody can make changes in the meantime.

RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs" and
"LOCK request on a resource MUST NOT succeed if can not be honored by all
the URIs through which the resource is addressable."

If you think about it, the first statement makes sense when you consider the
second statement.

However, I think the server applies locks to resources, but our
visualisation is that locks apply to URIs.

> - Locks are based on URIs.

See above.

> - A depth 0 lock puts a lock on that URI only.

Depends on what you mean. A resource can have one or more URIs mapped to it
(RFC 2518 sec 5.1). The resource would be locked and thus all the URIs that
map to it. So no matter what URI (that was mapped to the resource) that was
used by the client, the resource would appear to be locked as far as the
client is concerned. However, none of the descendants would be locked.

>   additional path components is covered by the lock as well.

Correct, although you might want to word it a little different -
"descendants" is probably better.

>   (if multiple bindings exist) must be checked against the locks that

As stated above, a resource MUST NOT be locked if the lock cannot be honored
by all the URIs which address it. You shouldn't have an occurrence where a
resource is locked, but using a URI that maps to it indicates the resource
isn't lock. So in *theory*, you shouldn't have to check all the URIs because
any of the URIs (that map to the locked resource) can be used to discover
that the resource is indeed locked.

> if any of the URIs to the resource is locked.

Of course, its all a lot simpler if your server only supports one URI per
resource. It makes the understanding of locking a lot easier :-)

Regards

Shaun Hall
Xerox Europe

---

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 23 Jun 2001 23:24:34 -0400

From: Hall, Shaun [mailto:[email-masked]]

   RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs"
   and "LOCK request on a resource MUST NOT succeed if can not be
   honored by all the URIs through which the resource is addressable."

   If you think about it, the first statement makes sense when you
   consider the second statement.
   However, I think the server applies locks to resources, but our
   visualisation is that locks apply to URIs.

Note: I will be arguing vigourously that we delete the "locks apply to
resource, not URIs" phrase from the next draft of 2518.  I believe
this statement has proven to be very confusing and misleading.
We should replace this with "a lock is on a URI, and a resource is
locked if it is mapped to a locked URI".

   > - A depth 0 lock puts a lock on that URI only.

   Depends on what you mean. A resource can have one or more URIs
   mapped to it (RFC 2518 sec 5.1). The resource would be locked and
   thus all the URIs that map to it. So no matter what URI (that was
   mapped to the resource) that was used by the client, the resource
   would appear to be locked as far as the client is
   concerned. However, none of the descendants would be locked.

Yes, you'd probably want to supplement this statement to make
sure it is not misunderstood.  Something like: "but the lock
controls access to that resource, even when that resource is
accessed through another URI".

   >   (if multiple bindings exist) must be checked against the locks that

   As stated above, a resource MUST NOT be locked if the lock cannot
   be honored by all the URIs which address it. You shouldn't have an
   occurrence where a resource is locked, but using a URI that maps to
   it indicates the resource isn't lock. So in *theory*, you shouldn't
   have to check all the URIs because any of the URIs (that map to the
   locked resource) can be used to discover that the resource is
   indeed locked.

Yes, the protocol does require that all the locks that affect a
resource (from any URI) appear in the DAV:lockdiscovery property
of that resource, so you just need to look at that property.
Now an implementation may implement that property by a scan
against all locks that exist on a URL that is mapped to that
resource, but that's an implementation choice.

Yes, 2518 largely ignores the use case where one resource is mapped
to multiple URI's (thus there was no BIND method, and
DAV:lockdiscovery did not expose the URI that was locked).  But we'll
fix all that in the upcoming new draft of 2518 (:-).

Cheers,
Geoff