Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme

[Sean Leonard <[e-mail]>]

On 1/1/2015 9:20 AM, Murray S. Kucherawy wrote:
> On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     In the case of file:, I have no doubt that the scheme is both
>     widely supported and widely used.  The problems with the current
>     specification have been widely discussed, over a long period.  But
>     I would have reservations about permanent registration if there is
>     no clear community consensus about how the scheme may be used or
>     is expected to function.
>
>
> [...]
>
> Can I take this to mean that as wide adoption increases, [...an RFC 
> should result...]

Let's be clear about file: URI. The file scheme *is* permanently 
registered in the URI Schemes database 
<http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-2>. 
The reference is RFC 1738 (December 1994). Until this or any other 
document supplants it, RFC 1738 is in force.

The full text of RFC 1738 is:

    The file URL scheme is used to designate files accessible on a
    particular host computer. This scheme, unlike most other URL schemes,
    does not designate a resource that is universally accessible over the
    Internet.

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

    For example, a VMS file

      DISK$USER:[MY.NOTES]NOTE123456.TXT

    might become

      <URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

    As a special case, <host> can be the string "localhost" or the empty
    string; this is interpreted as `the machine from which the URL is
    being interpreted'.

    The file URL scheme is unusual in that it does not specify an
    Internet protocol or access method for such files; as such, its
    utility in network protocols between hosts is limited.



It's short, sweet, and to the point. Sure it leaves a lot unspecified, 
but short = less to argue about. :) Does anyone take issue with the RFC 
1738 text?

Sean