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

Re: Locking URIs rather than Resources

From: <ccjason@us.ibm.com>
Date: Fri, 31 Dec 1999 18:22:06 -0500
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
Message-ID: <05256858.00804FA6.00@D51MTA03.pok.ibm.com>

     Now some locking questions. If LOCK applies to the name, not the
     /x/y.htm is locked, and /b/c.htm is bound to the same resource as
     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

Geoff, you agreed that "/b/c.html" is not locked.  In this case I think
preferably say the "the resource at" either/both URI's is locked... but
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.

       What about LOCK  /b/c.htm?

   That is fine.

Hmmm.  Jim said they are the same resource.  I don't think he meant a
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
at that URI.  I think you must have assumed he meant a shared lock when you
that is fine.

   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
   since other access rights or locks can come into play.

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.
Received on Friday, 31 December 1999 18:22:21 UTC

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