RE: Locking a Resource or Locking a URL?

I really think it's a mistake to understand the question whether a LOCK
locks just the reference or just the target or both as a question about
whether it's a resource or a URI or both getting locked.

A reference is a resource, as is its target.  They are just two different
resources.  The issue the design team was addressing was which resource(s)
get(s) locked when you send a LOCK request with a request-URI that
identifies a reference.

I think the design team agreed that the most intuitive behavior in this case
would be for both the reference resource and the target resource to be
locked.  The design team let some other consistency considerations over-ride
the law of least surprise in this case.  We ended up with the position that
for redirect references, just the reference gets locked; and for direct
references, just the target gets locked.

----------

I want to say that Geoff's examples are not really relevant to this
question.

We never explicitly addressed the question what happens if you submit a LOCK
request with a request-URI that has buried in it somewhere a segment that
identifies a reference.  This is a different case, and I don't think it is
relevant to the question whether, if the request-URI as a whole identifies a
reference, the reference or the target or both should get locked.

Here's an example.  We have URI /x/y/z.html.  Suppose /x/ identifies a
reference, whose target is collection /a/.  Suppose /x/y/z.html also
identifes a reference, whose target is /a/y/c.html.  It's like this:

/x/ references collection /a/
/a/ contains collection y/
y/ contains reference z.html
z.html references ordinary resource c.html

I think Geoff is arguing that neither the reference /x/ nor its target /a/
gets locked.  That's fine.  It makes perfectly good sense to say that
neither /x/ nor /a/ gets locked, but both /x/y/z.html and /a/y/c.html do get
locked.  (Or, as the spec currently says for direct references, the only
thing that gets locked is /a/y/c.html.)

In Goeff's example, /x/y/z.html is *not* a reference, so the collections
spec has nothing to say about it.  But /x/ is a reference, so we can
perfectly well say that when a LOCK request is submitted on /x/y/z.html,
neither the reference identified by /x/ nor its target (identified by /a/)
gets locked.

--Judy

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 11:35 PM
> To: w3c-dist-auth@w3.org
> Subject: Locking a Resource or Locking a URL?
> 
> 
> 
> One of the key topics in the recent thread on the Adv. 
> Versioning Collection
> protocol was 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 my message in the Adv. Coll. thread, I gave arguments for why
> (3) does not work in the context of references and versioning.
> 
> 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.
> 
> There also is the question of whether lock discovery would detect this
> implicit lock on /b/y.html.  This question has two parts ... what do
> you think the spec currently says, and what did the spec authors
> intend?
> 
> Cheers,
> Geoff
> 
>

Received on Friday, 26 February 1999 11:45:53 UTC