Locking URIs rather than Resources

Before I jump into the fray I want to make sure that I actually understand
the proposal. One sentence in particular gave me pause for thought. Geoff
stated that "...a LOCK request *never* requires a lock token". I though hard
about this, trying to understand exactly what it meant. Below I lay out my
thinking process so that if I have misunderstood the proposal my error can
be found and corrected.

Imagine user U takes out a depth 0 lock on collection C. Collection C has no
children. The ramification is that no one but U may add a new child to C.
User A then shows up and wants to create a new resource with the URL C/R.
Before creating the resource, however, A would like to first reserve the
name C/R. To this end A takes out a lock on C/R.

In the old system A's request would be rejected. The reason is that in the
old system locks are on resources. Therefore for A to lock the name C/R it
has to create some resource which 'owns' C/R and then lock that resource.
This is where lock-null resources came from. They are the 'stand-in'
resource who holds the name C/R until A is ready to transfer ownership of
the name to its final destination. However creating the lock-null resource
to hold C/R means that the lock-null resource would automatically become a
child of C. U, through its lock on C, has reserved the exclusive right to
create children of C. Therefore A's request to lock C/R is rejected because
the creation of the lock-null resource to hold the name C/R would violate
U's lock on C. (Is it just me or does the previous sound like an Abbott and
Castello routine? Castello: Who has the lock? Abbott: Who has the lock.
Castello: No, who has the lock?!? Abott: Exactly.)

But in the new proposal locks aren't on resources, they are on URIs.
Therefore when A locks C/R it is not locking a resource, it is locking a
name. Names aren't members of collections, resources are. Therefore A can
lock C/R without running afoul of U's lock on C because C/R, even though it
is locked, is still not a member of the collection. When A will run into
trouble is when it attempts, through a COPY, MOVE, PROPPATCH, PUT, MKCOL,
etc. to associate the URL C/R with a resource. By associating a resource
with C/R A will cause that resource to become a member of C. Of course U has
reserved the right to create new members of C, therefore A's request will be
rejected.

The result is that A can lock C/R without submitting a lock token. However
there isn't much A can do with the lock on C/R because doing anything to it
would require associating it with a resource, which U's lock prevents.

Geoff, did I get it right?

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Thu, December 30, 1999 2:33 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Creating a lock-null in a locked collection
> 
> 
> 
> As an addendum to Yaron's response, I'll note that there is a proposal
> that WebDAV locking is better understood as locks on URL's rather than
> on resources.  This not only makes the current WebDAV locking behavior
> easier to motivate (e.g. a resource "loses" a lock after a move
> because it is no longer identified by the locked URL), but removes the
> need to define a "lock null resource".
> 
> One effect of this proposal would be that the answer to Joe's question
> would change, i.e. that a LOCK request *never* requires a lock token.
> A LOCK request can fail (such as when it would collide with 
> an existing
> exclusive lock), but no failure would be resolvable through 
> the addition
> of a lock token.
> 
> FYI, the current state of the lock proposal is:
> 
> 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.  A URL MAY NOT be locked
> with two exclusive locks with the same locktype.
> 
> Cheers,
> Geoff
> 
>    From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
> 
>    The depth 0 lock controls the ability to add level 1 
> children to the
>    collection.
>    A lock null resource is a resource and hence is a member 
> of whatever
>    collections it exists within.
>    Therefore to create a lock null resource as a level 1 
> child of a collection
>    with a depth 0 lock one must have the depth 0 lock.
> 
>    In other words, yes, you must submit the token on the LOCK 
> on /foo/bar.
> 
> 			   Yaron
> 
>    > -----Original Message-----
>    > From: Joe Orton [mailto:joe@orton.demon.co.uk]
>    > Sent: Thu, December 30, 1999 6:45 AM
>    > To: w3c-dist-auth@w3.org
>    > Subject: Creating a lock-null in a locked collection
>    > 
>    > 
>    > I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar 
>    > to create a
>    > lock-null resource, do I need to submit the locktoken 
> for /foo/ in the
>    > LOCK request? Or only in the PUT to /foo/bar later?
>    > 
>    > (Or is it decided that lock-null resources are going to go away?)
>    > 
>    > joe
>    > 
>

Received on Thursday, 30 December 1999 20:26:10 UTC