Subject: Re: Locking URIs rather than Resources

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 1 Jan 2000 11:15:24 -0500

From: [email-masked]

   <ja/> Now some locking questions. If LOCK applies to the name, not the
   resource, /x/y.htm is locked, and /b/c.htm is bound to the same
   resource as /x/y.htm, is /b/c.htm locked too? Probably not.

   <gmc/> Correct.  But modifying the resource identified by /b/c.htm
   does require the lock token for the /x/y.htm lock.  This does not make
   /b/c.htm locked.

   <jc/> Geoff, you agreed that "/b/c.html" is not locked.  In this case I
   think we'd preferably say the "the resource at" either/both URI's is
   locked... but only one of those URI's is locked.  My point is that we
   should probably come up clearer vocabulary/notation for making a
   distinction between the URI and the resource.  For example, we used to
   say the URI was protected and/or the resource was locked.

I agree.  If we say that a URL is locked, then we need a term to
describe a resource that is identified by a locked URL.  Let's try
just using the word "protect".  So a locked URL "protects" the
resource that it identifies.  If it does not (at a particular moment)
identify a resource, it does not (at that moment) protect any resource
(i.e. there is no "lock null resource").

So in the example above, we would say that the resource identified by
/b/c.html is protected by the lock on /x/y.htm.

   <ja/> What about LOCK  /b/c.htm?

   <gmc/> That is fine.

   <jc/> Hmmm.  Jim said they are the same resource.  I don't think he meant a
   null-mapped resource.  That being the case, I think you mean to say
   that the second lock can only be placed if it doesn't conflict with
   the lock already acting on the resource at that URI.  I think you must
   have assumed he meant a shared lock when you said that is fine.

Actually not.  I was using the "exclusive" aspect of a lock to be
completely URL based.  So you couldn't have two exclusive locks on the
same URL (i.e. you can't have a depth:infinity exclusive lock on /x
and an exclusive lock on /x/y), but you *could* have a resource that
is protected by two exclusive locks.

Although this simplifies LOCK/UNLOCK implementation for a server, I 
(believe I) agree that a client would rather the "exclusive" aspect
of a lock apply to the resource.  So a particular resource can only
be protected by one exclusive lock of a given type.  This modifies
the last line of the latest locking proposal, which would now state:

"A lock can be placed on a URL with a LOCK request.  This URL is called
 the "lock base".  If the lock is Depth:N, then a lock is induced on
 any URL that consists of the lock base extended by N or fewer
 segments.  Only an authorized holder of a lock token for a locked URL
 can modify either the state of the resource identified by the URL, or
 which resource is identified by the URL.  If a locked URL identifies a
 resource, the lock "protects" that resource.  A resource may not be
 protected by two exclusive locks with the same locktype."

This would then change my answer to Jim's question.  The revised
definition would not allow an exclusive write lock on /x/y.htm and
one on /b/c.htm, since that would result in a resource being protected
by two exclusive locks of the same type.

   <gmc/>  One user has /x/y.htm locked.  The other user has /b/c.htm
   locked.  That means you can't modify that resource unless you have both
   lock tokens.  In this model, a LOCK prevents a certain kind of change
   to something, but does *not* guarantee the ability to make such a change,
   since other access rights or locks can come into play.

   <jc/> I agree with what you said about not guarantee'ing a right to change,
   but what about requiring two tokens?  As far as I know, the situation
   you outlined can only happen if shared locks are used.  In that case,
   only one lock token is required.

Yes, for the situation where two URL's identify the same resource.
But there still will be operations that will require the use of
multiple lock tokens.  An example would be the original scenario
described by Yaron, where:

- /x identifies a collection
- /x/y does not identify a resource
- there is a depth:0 exclusive write lock on /x
- there is an exclusive write lock on /x/y

In order to do a "PUT /x/y", you would need a Lock-Token for both
the /x lock and the /x/y lock, since you are modifying the state of
both /x and /x/y.

Cheers,
Geoff

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 3 Jan 2000 01:22:48 -0800

I think the existing proposals are kind of crufty, because there is no
sensible abstraction that people can understand and expand on.  They either
have the yucky lock-null, or they introduce a new kind of object (a URL)
that is not a resource, the "atom" (basic building block) of web
applications.

Here are the fundamental issues I see:

1) are the list of names in a collection logically part of the collection,
or do they live in some separate space outside the domain of resources?
(I'm using the word name the way jra uses "binding"--the relationship
between a containing collection and a particular resource which is given a
unique name within that collection).

To me the answer must be that they are a part of the collection.  The only
type of object that can be identified within this model is a resource.  You
are going to have (in a real system) access control on resources, and not a
separate access control model for names.  There are too many concepts in the
world of the web to introduce another type of object other than a resource.
Every filesystem in the world stores the list of filenames as a part of the
directory, and locks & access control on the directory affects all names
within.  Let's stick with current usage unless we have compelling reasons to
deviate.

2) what kind of locks are there?

IMHO, there must be two kinds of locks--name locks and resource locks.  The
problem with just locking a collection resource is that it is to
coarse-grained--there are lots of applications that will want to just lock a
single name in a collection, and resource locking every collection in a path
will reduce concurrency too much.  I think of this like table level and row
level locks in a database--a lock on the collection is like a table level
lock, locking all names (rows) in that collection.  Another way to think of
a name is like a fragment within the collection document.

3) what about the notion of a lock "depth"?

There is no such thing.  However, depth may be one way that a protocol
request can specify a particular set of locks.

Now that we understand that, what do we do about RFC 2518 LOCK's?  (I'm
using a capitalized LOCK to distinguish the RFC 2518 protocol request from
name locks and resource locks).

The requirements are:

* a LOCK on must prevent the resource from being moved, for compatability
with existing applications.
* a LOCK on must prevent any changes to that resource (updates, deletes,
etc.) if it exists
* a LOCK token must be associated with the locked resource and URL

So, it seems like that the following solution is the right abstraction:

1) add the notion of name and resource locks.  A name lock applies to a
single level name within a collection.  A resource lock applies to the data
identified by a particular URL.  If that URL identifies a collection, a
resource lock locks ALL of the names in that collection, and is blocked by
any name lock within, and vice versa.

2) we introduce the notion of a lock "set".  A lock set is a group of any
number of name and resource locks.  Each lock set as a single associated
lock token.  An RFC 2518 LOCK request applied to an existing non-collection
resource will grant name locks to each name in the path from the root down
to the bottom, and a resource lock on the identified resource, create a lock
set from this group, and grant an identifying LOCK token.  An RFC 2518 LOCK
request applied to a collection will work in the same way, except that if
the depth header is specified, name and resource locks will be given
recursively for each contained resource.  A LOCK request on a URL giving a
nonexistent name in a existing collection will issue only name locks on the
path elements.  If the URL minus the last path element does not refer to an
existing collection, the LOCK request will fail.

3) the activelocks property displays all name locks active for this
collection as well as all resource locks.

4) the "locktype" property is used to distinguish between name and resource
locks.  If locktype "resource" is specified, only the specified resource
lock is granted in that lock set.  If locktype "name" is specified, the
names from root to the resource are locked, if the Depth header is not
specified.  If the URL "/a/b/c.html" is given, negative depth values can be
given to lock fractions of the path.  E.g. if Depth:0 is specified, the name
"c.html" is reserved in collection /a/b, but no other locks are granted.  If
Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)  Only if
locktype is not specified does the LOCK request behave as it point #2
(granting resource & name locks simoultaneously), basically for
compatability with existing applications.

--Eric