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

>    The scheme emerged when the term file was relatively well-understood
>    as implying certain typical characteristics of a resource, such as
>    being a finite bit sequence manipulated as a unit, stored on a
>    relatively non-volatile storage device, organized with other files in
>    a hierarchical or record-based "file system"

This isn't so. At the time the 'file:' scheme was invented, there many
widely used distributed file systems, and we were all
aware of them -- AFS and NFS, and earlier systems,
that mapped file name syntax into remote access protocols.
I'd even implemented some remote access file-system redirectors.

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.

> 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 reason being, once you swap URL with URI, one must ask if 
> "universal accessibility over the Internet" is really implied by most 
> other resource identification schemes.

Most resource identification schemes for URIs have -- and should have --
uniform meaning, not dependent on local context.


> And maybe change this...
> 
>     A file URL takes the form:
> 
>     file://<host>/<path>
> 

>     Any URI having a scheme component consisting of "file", case-
>     insensitively, is a file URI.

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.


>     This standard does not mandate any particular mapping between
>     the components of a file URI and the file itself, nor any means
>     of accessing the file.

I think this is a bad direction, and that we should try to
narrow and standardize the interpretation of file: URIs,
because it is a useful concept for which there is a basis
for moving forward and making things more uniform. Disclaiming
responsibility goes in the wrong direction.

Larry
-- 
http://larry.masinter.net

Received on Tuesday, 21 September 2004 06:03:54 UTC