Subject: Locking URIs rather than Resources

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Thu, 30 Dec 1999 17:25:26 -0800

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:[email-masked]]
> Sent: Thu, December 30, 1999 2:33 PM
> To: [email-masked]
> 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)" <[email-masked]>
> 
>    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:[email-masked]]
>    > Sent: Thu, December 30, 1999 6:45 AM
>    > To: [email-masked]
>    > 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
>    > 
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 30 Dec 1999 22:26:21 -0500

I agree with all aspects of Yaron's interpretation of the "URL locking"
proposal.  It illustrates the fact that in this proposal, a LOCK (and UNLOCK)
request never fails due to the absence of a Lock-Token header.

A benefit of this approach can be seen if you invert the order in which the
locks are issued, namely, instead of:
  LOCK /x; Depth:0
  LOCK /x/y
you request:
  LOCK /x/y
  LOCK /x; Depth:0

In the current 2518 model, the first sequence would fail (for the reason
cited by Yaron) while the second would succeed (I believe ... with 2518,
you probably could make good arguments for both failure and success of the
second sequence).

In contrast, the proposed URI locking model treats these sequences
simply and identically: they both succeed, and they both end up in the
same state - with a Depth:0 lock on /x and a Depth:infinity lock on
/x/y.  In this state, if you want to do a PUT to /x/y and /x/y does
not identify a resource, you need both lock tokens (reasonably enough,
since you are modifying the state of both /x and /x/y).

Cheers,
Geoff

			   Yaron