W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: Locking URIs rather than Resources

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 31 Dec 1999 16:34:47 -0500
Message-Id: <9912312134.AA16809@tantalum>
To: w3c-dist-auth@w3.org

   From: jamsden@us.ibm.com

   Is y a lock-null resource in your example below?

In the "URL locking" proposal, there is no such thing as a lock-null
resource.  A lock is on a URL.  At any given moment, a URL may or may not 
identify a resource.  A lock can be placed on a URL independent of whether
or not that URL currently identifies a resource.

So there is a lock on the URL /x/y, but there is no resource identified
by /x/y (lock null or otherwise).

   It seems
   according to your definition below that the URL lock scheme would have the
   same behavior as 2518.

In most ways, but not in this case (i.e. whether or not the sequence:
 LOCK /x; Depth:0
 LOCK /x/y
succeeds or fails.

   If y is a lock-null resource:
     LOCK /x; Depth:0
     LOCK /x/y

     LOCK /x/y
     LOCK /x; Depth:0
   In the first sequence, the LOCK /x/y request fails (assuming the lock token
   is not specified or the user is not the owner of the lock) because x is
   locked and y can't be created in x either as a name or resource with /x/y
   bound to it.

But if locks are on URL's, then "LOCK /x/y" never creates a resource
(lock null or otherwise), so no modification is made to the state of
/x, so no lock token is required.

   The second sequence, both methods succeed because x isn't locked, so y can
   be created, lock-null or not.   Now x can be locked with depth:0 because
   there are no conflicting locks. What am I missing?

The only thing you are missing is that a depth:0 lock on /x is not relevant
to placing a lock on /x/y.

   Or are you just saying
   that LOCK doesn't require a lock token?

Yes, because a LOCK never modifies the state of any resource, so a lock
request can never require a lock token to succeed.

   Why the special case? 

No special case.  Just follows from the definition of a write lock.

   What happened
   to your proposal to remove lock-null resources?

I am still against lock null resources.  I am willing to accept locks
on URL's, and locks on URL's that currently do not identify a resource.

   Now consider the case where y isn't a lock-null resource, but an existing
   resource. The first sequence could succeed without a lock-token on /x
   because locking /x/y doesn't change the state of /x in any way. The second
   sequence would also succeed. Is this what you meant?

This is true, but not the use case I was referring to (i.e. where /x/y
does not currently identify a resource).

   If we don't have lock-null resources, how will names be reserved? Don't
   worry about the issue?

You can reserve names, but you don't use lock-null resources to do so.

   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.

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.

   A user not owning the lock on
   /x/y.htm could DELETE /b/c.htm since that URL isn't locked.

Correct.  The DELETE of /b/c.htm modifies the state of /b and causes
/b/c.htm to no longer identify a resource.

   What about LOCK  /b/c.htm?

That is fine.

   Say some other user would like this URL to remain fixed, but
   doesn't want to change the contents of the resource.

If by "fixed" you mean ensure that it identify the same resource,
then you would LOCK it (and this wouldn't change the contents of the

   Would that fail due to
   a conflict with the lock on /x/y.htm? Probably should.

Not at all.  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.

   Now what if a user
   not owning the lock does a PUT on /b/c.htm. According to the definition
   below, this would fail even though the URL isn't locked. So the user can do
   a delete, but not a put on /b/c.htm. Sounds a little confusing.

I don't see why.  Being able to add or remove something from a
collection is very different from being able to modify its state.

   Looks like
   the lock is on both the name and the resource in some way.

A lock is on a URL.  The *purpose* of a lock on a URL is to control:
- what resource is identified by that URL
- the state of the resource identified by the URL.


   "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/30/99
   10:26:21 PM

   Sent by:  w3c-dist-auth-request@w3.org

   To:   w3c-dist-auth@w3.org

   Subject:  Re: Locking URIs rather than Resources

   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
   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).


      From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

      Before I jump into the fray I want to make sure that I actually
      the proposal. One sentence in particular gave me pause for thought.
      stated that "...a LOCK request *never* requires a lock token". I though
      about this, trying to understand exactly what it meant. Below I lay out
      thinking process so that if I have misunderstood the proposal my error
      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
      User A then shows up and wants to create a new resource with the URL
      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
      old system locks are on resources. Therefore for A to lock the name C/R
      has to create some resource which 'owns' C/R and then lock that
      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
      the name to its final destination. However creating the lock-null
      to hold C/R means that the lock-null resource would automatically become
      child of C. U, through its lock on C, has reserved the exclusive right
      create children of C. Therefore A's request to lock C/R is rejected
      the creation of the lock-null resource to hold the name C/R would
      U's lock on C. (Is it just me or does the previous sound like an Abbott
      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
      lock C/R without running afoul of U's lock on C because C/R, even though
      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,
      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
      reserved the right to create new members of C, therefore A's request
   will be

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

      Geoff, did I get it right?


      > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
      > 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.
Received on Friday, 31 December 1999 16:34:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC