Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt

From: [email-masked]
Date: Tue, 19 Apr 2016 22:23:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ART Area General Applications Working Group of the IETF.

        Title           : The file URI Scheme
        Author          : Matthew Kerwin
	Filename        : draft-ietf-appsawg-file-scheme-07.txt
	Pages           : 19
	Date            : 2016-04-19

Abstract:
   This document specifies the "file" Uniform Resource Identifier (URI)
   scheme, obsoleting the definition in RFC 1738.

   It defines a common syntax which is intended to interoperate across
   the broad spectrum of existing usages.  At the same time it notes
   some other current practices around the use of file URIs.

Note to Readers (To be removed by the RFC Editor)

   This draft should be discussed on the IETF Applications Area Working
   Group discussion list <[email-masked]>.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 20 Apr 2016 15:43:36 +1000

Hi everyone,

I've pushed out an -07 version of the file URI draft. It's substantially
different from 06, mostly in removing a bunch of text from the main body
(some of which is now located in appendices).

As mentioned, or at least hinted, in my email replies, I've adopted most of
the changes recommended by Dave Crocker and Graham Klyne in their reviews.
There are still a couple of 'fixmes' though:

* I haven't touched Dave's suggestion that I cut back the Encoding section.

* The Security Considerations mentions possible issues from case-sensitive
aliasing, but still hasn't got anything addressing Julian Reschke's advice
to include encoding/Unicode normalization.

* There are a couple of places in the text where the normativity of
statements isn't clear. These are marked by a "(?)"

* I'm not sure how to address Mark Nottingham's questions about fitting in
with WWW specs like FETCH, URL, and Origin.

Other than that, I personally feel like this is the best version of the
draft I've submitted. The main spec body is down to four pages (about 8
pages with headers and references), and it's really clear what is defined
(a normative syntax) and what is not (all the optional/non-standard stuff
in the appendices.)

I think it's definitely a substantial enough change to warrant being put
back to WGLC.

Further reviews are, as always, appreciated. Assuming no blockers emerge
I'll try to keep future changes very small and manageable.

Cheers

On 20 April 2016 at 15:23, <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Graham Klyne <[email-masked]>
Date: Thu, 21 Apr 2016 00:18:33 +0100

Hi Matthew,

I think the main body of the document is a lot crisper now.  I have a couple of 
comments from a fairly quick scan.  The main substantive comment is that local 
access can occur when the file URI contains a host name which is the same as 
that for the host from which access is being attempted.

I've not done a detailed read through of the appendices - much of the material 
there is outside my experience.

...

Section 2:

[[
    Some file systems allow directory objects to be treated as files in
    some cases.  This can be reflected in a file URI by omitting the
    trailing slash "/" from the path.  Be aware that merging a relative
    URI reference to such a base URI as per Section 5.2 of [RFC3986]
    could remove the directory name from the resulting target URI.
]]

I think the second sentence is wandering into local implementation details.  I'd 
suggest focusing more on the idea that the trailing slash should be included in 
URIs that refer to directories.

...

Section 3:

[[
    A file URI can be dependably dereferenced or translated to a local
    file path only if it is local.  A file URI is considered "local" if
    it has no "file-auth", or the "file-auth" is the special string
    "localhost".
]]

There's also the case when the hostname resolves to the local host.

#g
--

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 21 Apr 2016 14:06:54 +1000

Hi Graham,

Thanks for the review again.

On 21 April 2016 at 09:18, Graham Klyne <[email-masked]> wrote:

> Hi Matthew,
>
> I think the main body of the document is a lot crisper now.  I have a
> couple of comments from a fairly quick scan.  The main substantive comment
> is that local access can occur when the file URI contains a host name which
> is the same as that for the host from which access is being attempted.
>
>
You know what, I think you're right, and I've been suffering from
confirmation bias. I just tested it again, and both Chromium and Firefox do
treat my machine's network name the same as "localhost". Windows and IE do
it the way I've documented in the draft, but it seems they're the only
ones. (If only I'd had mnot's test suite ...)

I'll change all the appropriate parts to say the right thing.

I've not done a detailed read through of the appendices - much of the
> material there is outside my experience.
>
>
Appendices A and B are the generally useful ones.

...
> I think the second sentence is wandering into local implementation
> details.  I'd suggest focusing more on the idea that the trailing slash
> should be included in URIs that refer to directories.
>
>
I preferred stating the use-case and the potential problems it causes,
rather than making a judgement call. I'm not 100% invested in it, though,
and can cut it back if it's too far the wrong way.

...
> There's also the case when the hostname resolves to the local host.
Yep, I will include that when I make the change.

​Cheers

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 21 Apr 2016 08:35:26 +0200 (CEST)

On Thu, 21 Apr 2016, Matthew Kerwin wrote:

> treat my machine's network name the same as "localhost".

They treat _any_ name as localhost as far as my tests show (on Linux). And so 
does curl.

Figuring out your own name and making sure the name in the file:// URI is one 
of those is really tricky (and slow) business.

-- 

  / daniel.haxx.se

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 21 Apr 2016 16:47:52 +1000

On 21/04/2016 4:36 PM, "Daniel Stenberg" <[email-masked]> wrote:
> They treat _any_ name as localhost as far as my tests show (on Linux).
And so does curl.
>
> Figuring out your own name and making sure the name in the file:// URI is
one of those is really tricky (and slow) business.

Urgh. Last time I checked (some number of months ago) Chrome used the
hostname to access a samba share. I think that was in Windows.

Perhaps it's best to just keep the semantics of RFC 1738, as Graham's been
saying all along.