Re: more 'file' suggestions for draft-hoffman-file-uri

On Sep 20, 2004, at 11:03 PM, Larry Masinter wrote:
> I don't think "file" is any more ambiguous now than
> it was then. Some files are local disk files, and others
> are remote. All of the implementations of "file:" that I
> know about go through the "file system interface" which
> is a well-known concept shared across multiple platforms.

Right, the key is that file identifies resources as named by the
user's file system interface.

>> In the first paragraph, I think this can be safely deleted:
>>     This scheme, unlike most other URL schemes, does not designate a
>>     resource that is universally accessible over the Internet.
> I think this is a crucial idea, although perhaps this sentence doesn't
> capture it. But it's not a good idea to delete it, it's important to
> fix it. "file:" lacks an important property of most other URI schemes.
> I think the thing missing is the uniformity of identification rather
> than "universal access", but that can be fixed.

The identification is uniform -- it just isn't always used correctly.
"file:/etc/hosts" identifies the filesystem entry "hosts" under the
directory entry "etc" under the root of the file system of the user's
machine, even if that machine happens to be running Windows and there
is no file by that name (i.e., "not found").  That is a fine identifier
if you happen to be making references from a Unix manual, and is still
a valid URI for a Windows user even though it isn't useful for 
a representation.

I think the warning should be that "file" refers to filesystem names
from the perspective of the user of a reference, rather than in relation
to a globally-defined naming authority, so care should be taken
to ensure that such references are actually intended to be in relation
to the user's filesystem interface.

> No, certainly not. I think we should preserve and encourage
> uniformity of meaning for 'file:'. My only hesitation is whether
> we should drop the pretense of 'host', since it is almost always
> omitted.

That would break existing data and software where it isn't omitted.
I don't like that at all.  Just make the authority component optional
and deprecate (but don't disallow) "//localhost".

The theory was that a smart filesystem interface with automounting
could make use of a file URI with a hostname. I think that is also
the basis of Win32 UNC names, but I can't remember if they actually
work that way on MSIE or not.


Received on Tuesday, 21 September 2004 07:00:41 UTC