Context dependant (was Re: Comments on 26 August draft

TAG,

On Tue, Aug 27, 2002 at 05:09:39PM +0100, Williams, Stuart wrote:
> > ==========================================
> > 
> > 2.3.1  There's a problem here.  As the section points out, 
> > file:/etc/passwd is highly context-sensitive, but then it says it's OK 
> > to use it if you're confident you're on the right operating system? 
> > I.e. you claim the concept of the resource is "this computer's password 
> > file"?  I think this sucks, and I think what we're trying to say is that 
> > you *shouldn't* use this kind of thing outside of a single-computer 
> > environemnt, i.e. you shouldn't EVER publish file:/ URIs on the Web
> > 
> > ===========================================
> 
> I think we need to be careful about this one. I made some mistakes about
> file: URI earlier in a thread on context independent URI [1,2].
> 
> file: URI can have an authority part [RFC1738] eg.
> file://example.org/etc/passwd and indeed the authority can be an Internet
> Domain Name... so as it was pointed out to me, the file: scheme is no more
> or less context dependent than the http: scheme.
> 
> I think that the kind of URI that we're trying to discourage are URI that
> dereference different resources depending on the context in which they are
> used. So, http://localhost/index.html would be as good (or as bad depending
> on POV) as file:/index.html or file://localhost/index.html.

Yes, we definitely need to be careful here. 8-) I don't think that the
issue is as straightforward as that wording suggests.  "dereference
different resources depending on the context .." is perfectly fine IMO,
so long as what is identified takes this context-sensitivity into
account.  So "file:/etc/passwd" is fine to publish on the Web, when it
is used to identify "the /etc/passwd file".  If it were used to try
to identify "the local password file", then that would create problems
and so should definitely be discouraged.

Also, identification can be inherrently indirect.  For example, "the
nearest gas station".  That is a resource in its own right, though
dereferencing it will redirect to other resources depending upon the
context in which it is deferenced.  I also see no problem with this.

So what I might have said in 2.3.1 would be something like this
(using the newly proposed definition for URI);

"Each valid use of an absolute URI identifies one resource, but the
resource itself may be defined in a context-sensitive manner.  For
resources of this type, the result of dereferencing them varies
depending upon the context in which they are dereferenced.  For example,
"http://example.org/nearest/gas/" may identify "the nearest gas
station", but the results of deferencing it, including the ultimately
identified resource (perhaps indicated with a HTTP 301 redirect
response) will vary depending upon the geographical location of the
dereferencer (and perhaps other information)."

("ultimately identified resource" is weak - is there a better term in
existence?)

Then I'd go on to describe the file:/etc/hosts issue;

"For those URIs without an authority, such as news: URIs, most file:
URIs, etc.., it is important that what they identify be consistent in
all contexts.  For example, "file:/etc/passwd" makes a poor identifier
for the generic concept of a "password file" because in many contexts
(i.e. most non-Unix operating systems) the passwords are not maintained
in a file named "/etc/passwd"."

I think the principle in 2.3.1 is fine (though "concept" seems
superfluous), but I think it takes on a slightly different (and clearer,
IMO) meaning given my proposed text above.

Thanks.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Tuesday, 27 August 2002 17:07:28 UTC