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

> - A file URI represents a file that is associated with a host.

sounds good so far
 
> - The syntax of a file URI is that of absolute-URI, except that
>   its scheme component must be 'file', case-insensitively.

I think this just confuses things, since it doesn't really say
anything.
 
> - The *typical* syntax of a file URI is more restrictive
>   (no query component, authority is usually empty,
>    path usually starts with "/")

Well, hmmm, the 'authority' is interpreted differently, but
it is either empty, 'localhost', or some other value; in
some implementations, it is a host name in some local name
space. (For example, many Windows implementations treats
the 'authority' component as a UNC host, e.g.,
 file://hostname/path/to/file  =>  \\hostname\path\to\file

> - The authority component of a file URI is considered by this
>   specification to contain a host component exactly as defined
>   by the rfc2396bis grammar. (I don't want there to be any
>   ambiguity about what the "host component" is).

Well, is it ever anything other than empty, 'localhost' or
a host name?
 
> - The host component of a file URI represents the host
>   associated with the identified file.
 
> - The path component of a file URI represents an identifier 
> for the file
>   as would be used in the host's principal file system interface
>   (i.e., the path component of a file URI usually represents a file's
>   "local path" on the host's file system). "File system interface" is
>   assumed to be a well-understood concept.


Actually, I disagree. What it *should* be is a translation of
the local file system's path to a file, in the local character
encoding for the file system, into (hex-encoded) UTF-8, where
"/" is used consistently for directory delimiters, and with
an appropriate platform-specific encoding for other top-level
decorations of the file syntax.

On a windows system
 file:///c:/path/to/file  <=>  c:\path\to\file

On some versions of MacOS that use : for path delimiters,

  hd:directory:dir2:dir3:file  <=>   file:///hd/directory/dir2/dir3/file

While not all current file: URI implementations follow this
exactly, there are multiple, independent interoperable
implementations of this.


> - Other components of a file URI, if defined, are not defined
>   by this standard as necessarily representing anything in particular,
>   but they do contribute to the identification of the file represented
>   by the URI. Thus, a query component present in a file URI may or may
>   not affect how the URI is dereferenced on a particular platform,
>   but even when it does not affect anything, it cannot be assumed,
>   in the absence of a standard stating otherwise, that a file URI with
>   a query component is equivalent to a file URI without one.

I think this is useless. Let's describe what usually works.

I think the query component should be ignored when dereferencing the
resource, but dynamic content of a file may be able to access 
"the URI used to reference it", and take advantage of the
query component in that way.

> - The manner in which a host component represents a host is
>   this: If the component is empty or is "localhost" (what if it is
>   the percent-encoded equivalent of "localhost"?), the component
>   represents the host on which the URI is being interpreted. No
>   guidelines are given for the interpretation of any other values;
>   they may take the form of IP addresses, DNS names, or any other
>   identifier. No guidelines are given for how to dereference such
>   identifiers (hey, I'm just describing current practice).

I see no point in giving 'no guidelines', and you're not
actually 'describing current practice', you're trying to
avoid describing it by disclaiming any knowledge of current
practice.

>  - The manner in which a path component represents a file
>    identifier in a file system interface is this:  If the file
>    system interface implies hierarchical containment, then...
>    (and you can go on to whatever level of detail you want)
> 
> Thoughts?

If you can't tell, I'm in favor of being more proactive, I think
it will be more useful to the community to push toward "best
practice".

Larry

Received on Wednesday, 22 September 2004 05:01:35 UTC