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

Graham Klyne <gk@ninebynine.org> Fri, 15 April 2016 11:15 UTC

Return-Path: <gk@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 787E212D565 for <apps-discuss@ietfa.amsl.com>; Fri, 15 Apr 2016 04:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SkNOfdnDLdln for <apps-discuss@ietfa.amsl.com>; Fri, 15 Apr 2016 04:15:04 -0700 (PDT)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A23D12D688 for <apps-discuss@ietf.org>; Fri, 15 Apr 2016 04:15:04 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1ar1iD-0004JB-gN; Fri, 15 Apr 2016 12:14:57 +0100
Received: from modemcable171.142-37-24.static.videotron.ca ([] helo=[]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1ar1iC-00052t-MB; Fri, 15 Apr 2016 12:14:57 +0100
Message-ID: <5710CD2D.6040103@ninebynine.org>
Date: Fri, 15 Apr 2016 12:14:53 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Matthew Kerwin <matthew@kerwin.net.au>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E267A.2070801@ninebynine.org> <CACweHNDry0HaLUqTCRh7tpR6VwgmJnaaa9mLoKqRHV6j8j2AdQ@mail.gmail.com>
In-Reply-To: <CACweHNDry0HaLUqTCRh7tpR6VwgmJnaaa9mLoKqRHV6j8j2AdQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/zdjSysIM4281eskiq0Ybu5eMw5Q>
Cc: Dave Crocker <dcrocker@bbiw.net>, Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] New information relating to draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2016 11:15:06 -0000

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 
(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:


    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:


    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

    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 


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.)