Re: Locking a Resource or Locking a URL?

   From: Yaron Goland <yarong@microsoft.com>

   O.k. I'm completely lost. Let's try this again.

   I have a resource which is available through two names, http://foo/bar and
   http://iggy/pop. Someone requests and receives an exclusive write lock
   against http://foo/bar. I assert that the immediate consequence is that
   http://iggy/pop is ALSO write locked by the same principal.

Good, this means we can rule out #2 as being clearly wrong.
I believe we also agree that #1 is true (after all, that's what
the spec says).

So all that's left (and that was the actual intent of this thread),
is to determine if it is legal for an RFC-2518 compliant server to allow
a *different* resource to appear at http://foo/bar after a
"LOCK http://foo/bar" request has been issued.

I believe the answer is "yes", since RFC-2518 only talks about
what it means when a resource is locked, so if a server associates
a different (unlocked) resource with a URL (or if some extended protocol
allows a client to associate a different resource with a URL),
then this does not violate locking behavior as defined in
RFC-2518.

Another way of phrasing this is that the URL(s) currently used
to reference a resource are *not* a property or attribute of the
resource, so changing the URL that is used to reference a resource
does *not* violate any locks that might be on that resource.

Both references and versioning introduce mechanisms for the client
to explicitly modify the association of a specific resource with
a specific URL, and I believe this subtlety is at the heart of
our disconnect on advanced collection locking.

Yaron: We may need to add this to our "Minneapolis Poolside Agenda"
if email isn't cutting it (and yes, I *always* bring my cool markers
to IETF conferences :-).

Cheers,
Geoff

   > -----Original Message-----
   > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
   > 
   > ...  the question of what gets locked when you lock a resource.
   > 
   > There are (at least :-) three interpretations:
   > 
   > (1) You are locking only the resource.
   > 
   > (2) You are locking what appears at a given URL (i.e. if 
   > the resource
   > currently selected at that URL also appears at another 
   > URL, then the
   > lock does not apply to accesses through that other URL).
   >
   > (3) You are locking both the resource and the fact that 
   > the resource appears at the given URL.
   > 
   > ...
   > In this message, I would like to confirm that nobody 
   > believes that
   > (2) is the correct interpretation.  In particular, I 
   > would like to
   > confirm that if /a/x.html and /b/y.html happen to be the 
   > same resource
   > (by some quirk of the server, say), and /a/x.html is locked, then
   > a PUT to /b/y.html would fail without the appropriate lock token.

Received on Friday, 26 February 1999 12:30:51 UTC