[apps-discuss] New information relating to draft-ietf-appsawg-file-scheme

[Graham Klyne <[e-mail]>]

Yesterday, in discussion with one of the original authors of RFC 1738, I learned 
something about file:// URIs that I had not previously realized.

The upshot of this for me, in particular with references to Mark Nottingham's 
comment 
(https://mailarchive.ietf.org/arch/msg/apps-discuss/pZG6iMoerYpa5qq6BkHa8j0Nfjo) is 
that there may be parts of this spec that go beyond the clarification exercise 
required to maintain file:// URI scheme as a standard-track specification.

I offer a new (not detailed) review with suggestions for elements that might be 
dropped, in the hope that what remains is truly just a clarification rather than 
a modification of the RFC1732 description of file:// URIs.

(My own experience and use of file:// URIs is not affected by what I learned, 
and in my previous reviews have assumed that contributions relating to UNC files 
in particular were based on appropriate knowledge or experience.)

...

I have learned that the intent of including a hostname component was *not* to 
allow some kind of cross-host file access to be invoked, but to act as a signal 
to software using the URI that was not running on the specified host that the 
corresponding resource was not dereferencable.

This is supported by, or at least consistent with, a close reading of the 
relevant text in https://tools.ietf.org/html/rfc1738#section-3.10:

[[
    A file URL takes the form:

        file://<host>/<path>

    where <host> is the fully qualified domain name of the system on
    which the <path> is accessible, and <path> is a hierarchical
    directory path of the form <directory>/<directory>/.../<name>.
]]

Also, RFC 1630 is more explicit that the file scheme is for *local* file access. 
  The following from https://tools.ietf.org/html/rfc1630 is much clearer about 
this than RFC1738:

[[
file

    The other URI schemes (except nntp) share the property that they are
    equally valid at any geographical place.

    There is however a real practical requirement to be able to generate
    a URL for an object in a machine's local file system.

    The syntax is similar to the ftp syntax, but in this case the slash
    is used to donate boundaries between directory levels of a
    hierarchical file system is used.  The "client" software converts the
    file URL into a file name in the local file name conventions.  This
    allows local files to be treated just as network objects without any
    necessity to use a network server for access.  This may be used for
    example for defining a user's "home" document in WWW.

    There is clearly a danger of confusion that a link made to a local
    file should be followed by someone on a different system, with
    unexpected and possibly harmful results.  Therefore, the convention
    is that even a "file" URL is provided with a host part.  This allows
    a client on another system to know that it cannot access the file
    system, or perhaps to use some other local mecahnism to access the
    file.

    The special value "localhost" is used in the host field to indicate
    that the filename should really be used on whatever host one is.
    This for example allows links to be made to files which are
    distribted on many machines, or to "your unix local password file"
    subject of course to consistency across the users of the data.

    A void host field is equivalent to "localhost".
]]


Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-06 again in 
light of this, I have the following comments:

...

Section 1:

[[
This document defines a syntax that is compatible with most extant
    implementations, while attempting to push towards a stricter subset
    of "ideal" constructs.  In many cases it simultaneously acknowledges
    and deprecates some less common or outdated constructs.
]]

I don't think "deprecates" is right here, as it doesn't discourage any 
behaviours specifically allowed by RFC1732.  (cf. Mark's comment.)

...

Section 1.2:

It now seems to me that the role of a host name in UNC name is quite different 
to its (original) role in a file:// URI.  In light of this, should this section 
be dropped?

...

Section 2:

[[
       file-auth      = [ userinfo "@" ] host
]]

The inclusion of "userinfo @" is an extension to previous *specifications* of 
the file URI.  As such, I question whether this change should be included. 
Dropping it doesn't affect compatibility with RFC3986.

...

Section 3:

[[
    This specification neither defines nor forbids a mechanism for
    accessing non-local files.  See SMB [MS-SMB], NFS [RFC7530], NCP
    [NOVELL] for examples of protocols that can be used to access files
    over a network.  Also see Appendix C.2 for a non-normative discussion
    on translating non-local file URIs to and from UNC strings.
]]

Given the new information noted, this seems extraneous to me.  Suggest dropping.

...

Section 3.1:

There is an option to include the host name even for local files, as an 
indication that the same file should not be expected to exist on other hosts.

I think the default position, in practice, is to not specify a host name.  But 
if the applications expects that the full absolute URI may be passed to another 
system it may make sense to include it to avoid dereferencing the value in an 
inappropriate context.

...

Section 3.2:

Given the new information noted, this section seems extraneous to me.  Suggest 
dropping.

...

Section 4:

Given the new information, the discussion of encoding when sending a file URI to 
a different system seems less relevant.  I would be inclined to drop all but the 
first paragraph of this section.

...

Section 6:

If the userinfo option is removed (see above), the final paragraph becomes moot. 
  Suggest drop.

...

Appendix A:

The characterization of "local" and "non-local" files isn't really germane. 
Suggest drop the sub-categorization and just list the examples.

...

(I'm not reviewing Appendices B and C at this time, as they aren't affected by 
my new perspective.)

...

#g
--