- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 04 Mar 1999 01:17:28 -0800
- To: "Slein, Judith A" <JSlein@crt.xerox.com>
- cc: w3c-dist-auth@w3.org
>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 think it might be useful to take a step back and ask why any of the
"operations on the reference" are being applied to the same URL as the
"operations on the target of the reference". This is the same relationship
that exists between the source of a CGI script and the URL(s) that cause
the CGI script to be executed.
In other words, create/write/lock the reference at URL "R", have it
contain the instructions for
{URL set not including R} --> target URL
and let the server take care of the magic of making it so.
The ambiguity goes away. Furthermore, a smart definition would
allow the reference to be defined according to the media type (with
one type being the preferred standard), thus allowing extensions
to author smarter, more flexible alternatives (like mod_rewrite rules).
....Roy
Received on Thursday, 4 March 1999 04:19:37 UTC