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

From: Graham Klyne <[email-masked]>
Date: Thu, 01 Jan 2015 16:30:52 +0000

On 01/01/2015 06:37, Murray S. Kucherawy wrote:
> The BCP for registering schemes appears not to require an RFC, only Expert
> Review.

<reviewer hat on>

As reviewer, I look for significant support or implementation if the scheme is 
destined for permanent registration.

Specifically, from https://tools.ietf.org/html/rfc4395#section-2:

    New URI schemes SHOULD have clear utility
    to the broad Internet community, beyond that available with already
    registered URI schemes.

    ... a URI
    scheme definition itself MUST be clear as to how it is expected to
    function.

In practice, I would take publication as an IETF-stream RFC, especially 
standards-track, as providing a strong indication that a level of consensus or 
usage exists.  Without that, I expect to have other evidence of widespread 
support/use.

In the past, I have pushed back against permanent registrations from the 
independent stream, as it lacks the same level of community support or 
conviction.  I would prefer to see an individual (non-WG) IETF-stream 
submission.  But in all this, I'm open to discussion, especially with IESG 
members who may be able to garner evidence of support that I'm not seeing.

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.

</off>

#g
--

> On Wed, Dec 31, 2014 at 8:51 PM, Matthew Kerwin <[email-masked]>
> wrote:
>
>> On 21 December 2014 at 05:55, Larry Masinter <[email-masked]> wrote:
>>
>>>> This opens a call for adoption for draft-kerwin-file-scheme, to be
>>> processed by APPSAWG.
>>>
>>> I don't think apps area should take up kerwin-file-scheme as an
>>> independent work item, not because the work isn't important but because
>>> apps-discuss is too congested to manage the discussion (no responses to my
>>> Dec 9 comments
>>> https://www.ietf.org/mail-archive/web/apps-discuss/current/msg13462.html
>>> ). In general, APPSAWG shouldn't take up URL-scheme permanent
>>> registrations? Or should it? This should be addressed in the scheme
>>> registration BCP.
>>>
>>>
>> Sorry for not responding sooner, I've been a bit overwhelmed with real
>> life, and there's quite a back-log of comments and messages to aggregate
>> and process.
>>
>> Regarding adoption of URL schemes by this WG, what alternatives would you
>> propose? I could instead try to make it an individual submission, but this
>> particular scheme has a lot of political and emotional history, and there
>> seems to be more and more work involved with developing the spec, so I'd
>> rather have much more buy-in through the whole process (such as you get
>> from a working group). I don't think it's big enough to warrant spinning up
>> its own WG, and I'm not aware of any others that would be more appropriate
>> than here.
>>
>
> The BCP for registering schemes appears not to require an RFC, only Expert
> Review.
>
> The guideline I've had in mind both for schemes and media types is this: If
> there's a lot of development work to be done on the format of what's to be
> registered, or if Standards Track status seems to be worthwhile or even
> necessary, then a working group (this one or a new one) makes sense.  On
> the other hand, if it's mostly just documenting and then registering
> something already quite well understood, I think the independent stream is
> worth considering.  Even better: If the required documentation could simply
> be included in the registration template, then just do that, and then
> there's no need to produce an RFC through any stream.
>
> An individual submission requires AD sponsorship, and I don't think this
> has been shopped to any ADs yet (has it?).
>
> All that said, one of the earlier threads about this work certainly made me
> think there's a non-trivial number of issues that need attention before
> this one could be done right, so working group attention (this or a new
> one) is warranted.  If we want to spin off a WG for it, that's for Barry to
> consider (anyone feel like writing a charter?).
>
> All THAT said, Larry's earlier message (URI cited above) does still need a
> reply, I believe.  If this draft does get adopted, that will be necessary
> before we can progress the document.
>
> -MSK
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jan 2015 09:20:34 -0800

On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne <[email-masked]> 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.
>

Thanks for chiming in, Graham.

Can I take this to mean that as wide adoption increases, your expectation
of community discussion and possibly even RFC publication also increase?
Such guidance would be useful in deciding which way to guide these thing in
the future, especially since there's been such a surge in them lately.

-MSK

---

From: Graham Klyne <[email-masked]>
Date: Thu, 01 Jan 2015 18:01:48 +0000

> the future, especially since there's been such a surge in them lately.

Murray,

I don't think adoption is in question (if I understand correctly what you mean 
by "adoption").  I come across file: URIs quite often, if (by their nature) in 
localized contexts.  The main concern I see is that past attempts to better 
document the file: URI scheme have failed to coalesce sufficient consensus about 
what such a document should say (and not say).

I am optimistic that we have a good chance of achieving consensus for some RFC 
publication based on the current draft (which draws from the previous work).  My 
sense is that most of the active participants in the current debate would see a 
less-than-perfect document as preferable to no document at all.  Exactly what 
form that publication should take is less clear:  app-wg or individual 
submission (IETF stream) both seem OK to me.

For me, the real value in moving towards a consensus specification for file: 
URIs is that it would provide a common file naming framework for software 
libraries that unify local and web access to resources.  The capability is 
substantially achievable today based on the available and informal 
specifications, but there are a number of problematic edge cases (like Windows 
drive letters) that can cause interop problems.  We may not resolve all of these 
problems to everyone's satisfaction, but I'm hopeful we can make some progress 
in the right direction.

HTH.

#g
--

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Jan 2015 13:15:32 -0500

--On Thursday, 01 January, 2015 18:01 +0000 Graham Klyne
<[email-masked]> wrote:

>...
> For me, the real value in moving towards a consensus
> specification for file: URIs is that it would provide a common
> file naming framework for software libraries that unify local
> and web access to resources.  The capability is substantially
> achievable today based on the available and informal
> specifications, but there are a number of problematic edge
> cases (like Windows drive letters) that can cause interop
> problems.  

Of course, the more we move in the direction of what sounds to
me like a desire to use "file:" to reference resources that may
be either local or remote ("web access"), potentially with
multiple web locations, the closer we get to "file:" meeting the
design criteria of persistence and location-independence that
characterize URNs.

I'm not commenting right now on whether I think that would be
good or bad (not sure I even have an opinion given how widely
things that appear to be URIs with a scheme of "file" are used),
but these waters are muddy already and I think that, if we
decide to muddy them further, it should be with our eyes open.

  john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jan 2015 10:17:00 -0800

On Thu, Jan 1, 2015 at 10:01 AM, Graham Klyne <[email-masked]> wrote:

> I don't think adoption is in question (if I understand correctly what you
> mean by "adoption").  I come across file: URIs quite often, if (by their
> nature) in localized contexts.  The main concern I see is that past
> attempts to better document the file: URI scheme have failed to coalesce
> sufficient consensus about what such a document should say (and not say).
> [...]
>

Actually, my question was more general, and not specific to this particular
document.  I'll rephrase:

Can I take this to mean that, as wide adoption of a given a scheme (or
media type, though I know that's not what you review) increases, your
expectation of community discussion and possibly even RFC publication
defining that scheme also increases?

-MSK

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 02 Jan 2015 16:28:32 +0900

Hello John,

On 2015/01/02 03:15, John C Klensin wrote:
> be either local or remote ("web access"),

I'll let Graham confirm (or deny) this, but it seems to me that you are 
misunderstanding him. I think he is speaking about URIs in general 
providing the framework, with http/s: for web access and file: for local 
access.

Regards,   Martin.

potentially with

---

From: Graham Klyne <[email-masked]>
Date: Fri, 02 Jan 2015 13:18:20 +0000

> design criteria of persistence and location-independence that

Hmmm.   I'm not sure I see this.  I think file: URIs are still location 
dependent, but the location may depend on the context of use rather than the URI 
string alone.  (To clarify:  I have used file: for local resources and http: for 
remote resources, so not expecting to use file: for both.)

What I was referring to was writing software that can handle local and remote 
resources through a common interface, using URIs as an over-arching scheme for 
referencing both.  I've worked on applications that using implementation of this 
idea over the past couple of years, so its not a new capability - just not (yet) 
very portable.

#g
--

---

From: Sean Leonard <[email-masked]>
Date: Fri, 02 Jan 2015 05:51:15 -0800

On 1/1/2015 9:20 AM, Murray S. Kucherawy wrote:
> On Thu, Jan 1, 2015 at 8:30 AM, Graham Klyne <[email-masked] 
> <mailto:[email-masked]>> 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

---

From: Graham Klyne <[email-masked]>
Date: Fri, 02 Jan 2015 13:55:19 +0000

> defining that scheme also increases?

Ah, thanks, I think I get your question now :)

Short answer: No (or not specifically).

Longer answer:

My reference to "adoption" as well as "consensus" is a recognition that, where 
there are non-standardized URI schemes out there in the wild which are widely 
used, and which are not otherwise controversial, it is probably appropriate per 
the "utility" requirement to include them in the permanent registry.

But I still have a preference for seeing RFC publication, or open standard 
publication, as that provides some evidence of "clear utility to the broad 
Internet community" [http://tools.ietf.org/html/rfc4395#section-2.1].  Absent 
that, I will look for, or ask for, other indicators, such as widespread adoption.

#g
--

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 4 Jan 2015 21:55:31 +1000

On 2 January 2015 at 23:51, Sean Leonard <[email-masked]> wrote:

> 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.
>
> ​[...]
>
>
>
> 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?
>
>
RFC 1738 is marked "obsolete," even if that's not entirely true, and thus
some members of the internet community (rightly or wrongly) believe that
file: is orphaned. In fact, that fact was what triggered me to start
writing it in the first place.

Then, when I first attempted to write the draft, I essentially took the
text from 1738 and wangled it the way Paul Hoffman did with 4248 and 2466
to basically clarify the status without changing anything, and no one was
happy with that. The attempt to satisfy everyone's desire to see something
<s>better</s> more thorough and up to date (including mine)  is what lead
to the text you see today.

​Short doesn't mean less to argue about, when short means holes in the
definition. More ambiguity = more to argue about. I'd have thought that was
self evident with file: in particular (try typing the same UNC-flavoured
file: URL into both Chrome and Firefox and see how long it takes them to
disagree violently.)

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

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 4 Jan 2015 23:31:12 +1000

So, finally getting around to replying to this...

On 20 December 2014 at 10:45, Sam Ruby <[email-masked]> wrote:

> ​​
>
> The area I've chosen to focus on first is host names -- something that is
> particularly thorny.  The RFCs you reference don't quite capture all of the
> necessary behavior.  I encourage you to explore the following URIs.  In
> particular, I recommend exploring these with the Chrome browser:
>
> file://2130706433/foo
>

That's just silly. Sure, there's a code path for that in Chrome; does that
mean every implementation out there must also parse decimal strings as
big-endian IPv4 addresses?

> file://[2001::1]/foo

I thought this already worked with RFC 3986..? See the "IP-literal"
construct in <https://tools.ietf.org/html/rfc3986#section-3.2.2>, which is
used in "host".

> file://
> ​​
> ０Ｘｃ０．０２５０．０１/foo
>
> Note that the last one is using Unicode wide characters.  An alternate
> representation would be as follows:
>
> file://\uFF10\uFF38\uFF43\uFF10\uFF0E\uFF10\uFF12\uFF15\
> uFF10\uFF0E\uFF10\uFF11/foo
>
>
There are no wide chars in a URI. That would be an IRI.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 10 Jan 2015 21:40:14 +0100

>construct in <https://tools.ietf.org/html/rfc3986#section-3.2.2>, which is

With the RFC 3986 grammar it would parse as

  ["URI", [
    ["scheme", [
      ["ALPHA", [], 0, 1],
      ["ALPHA", [], 1, 2],
      ["ALPHA", [], 2, 3],
      ["ALPHA", [], 3, 4]], 0, 4],
    ["hier-part", [
      ["authority", [
        ["host", [
          ["IP-literal", [
            ["IPv6address", [
              ["h16", [
  ...
              ["h16", [
  ...
      ["path-abempty", [
        ["segment", [
          ["pchar", [
  ...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Sam Ruby <[email-masked]>
Date: Sat, 10 Jan 2015 15:57:05 -0500

[never saw Matthew's reply.  still can't find it.  weird]

>> construct in <https://tools.ietf.org/html/rfc3986#section-3.2.2>, which is

My point was that it works with RFC 3986, but doesn't work with 
draft-kerwin-file-scheme.  I encourage you to look at section 2.2 of RFC 
4291.

There is a very simple fix for this.  I believe that what you want to 
refer to instead is section 2 of RFC 6874.

- Sam Ruby

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 11 Jan 2015 09:31:38 +1000

>       ["ALPHA", [], 3, 4]], 0, 4],

Doesn't it match the pattern `[ *5( h16 ":" ) h16 ] "::" h16`? I.e. zero of
the (h16 ":") part, then h16="2001", "::", h16="1"

​Is that what you're saying? If so, is that somehow wrong?​

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 11 Jan 2015 09:38:39 +1000

On 11 January 2015 at 06:57, Sam Ruby <[email-masked]> wrote:

> ​
> ​
> ​
How does it not work? Consider that I may not be an IPv6 guru, and possibly
[2001::1] means something to you that it doesn't to me.

> refer to instead is section 2 of RFC 6874.
It says "...and importing the "userinfo", "host", "path-absolute", and
"query" rules from [RFC3986] (as updated by [RFC6874].)"

---

From: Sam Ruby <[email-masked]>
Date: Sat, 10 Jan 2015 18:52:16 -0500

On 01/10/2015 06:38 PM, Matthew Kerwin wrote:
> On 11 January 2015 at 06:57, Sam Ruby <[email-masked]
> <mailto:[email-masked]>>wrote:
>
>             On 20 December 2014 at 10:45, Sam Ruby
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 file://[2001::1]/foo
>
>
>             construct in
>             <https://tools.ietf.org/html/__rfc3986#section-3.2.2
>             <https://tools.ietf.org/html/rfc3986#section-3.2.2>>, which is
>             used in "host".
>
>     draft-kerwin-file-scheme.  I encourage you to look at section 2.2 of
>     RFC 4291.
>
> How does it not work? Consider that I may not be an IPv6 guru, and
> possibly [2001::1] means something to you that it doesn't to me.
>
>     There is a very simple fix for this.  I believe that what you want
>     to refer to instead is section 2 of RFC 6874.
>

That's section 2.  My comment relates to Appendix A.  Sorry if I wasn't 
clear before.

- Sam Ruby

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 11 Jan 2015 00:55:34 +0100

* Matthew Kerwin wrote:
>?Is that what you're saying? If so, is that somehow wrong??

Yes, that is how it matches, and no, that is not wrong.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 11 Jan 2015 10:10:53 +1000

> That's section 2.  My comment relates to Appendix A.  Sorry if I wasn't
Oh, I see. Well, Appendix A isn't my text, it's a copy-paste from the
reference <http://msdn.microsoft.com/en-us/library/gg465305.aspx>

The easier fix is to drop the appendix altogether.

That said, [2001::1] still matches the MS UNC syntax. RFC 6874 adds some
percent stuff for zones, but that doesn't seem relevant to any example
you've provided here.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 11 Jan 2015 01:10:58 +0100

>refer to instead is section 2 of RFC 6874.

Per https://tools.ietf.org/html/draft-kerwin-file-scheme-13 the string
parses as

  ["file-URI", [
    ["f-scheme", [], 0, 4],
    ["f-hier-part", [
      ["auth-path", [
        ["f-auth", [
          ["host", [
            ["IP-literal", [
              ["IPv6address", [
                ["h16", [
                  ["HEXDIG", [
                    ["DIGIT", [], 8, 9]], 8, 9],
                  ["HEXDIG", [
                    ["DIGIT", [], 9, 10]], 9, 10],
                  ["HEXDIG", [
                    ["DIGIT", [], 10, 11]], 10, 11],
                  ["HEXDIG", [
                    ["DIGIT", [], 11, 12]], 11, 12]], 8, 12],
                ["h16", [
                  ["HEXDIG", [
                    ["DIGIT", [], 14, 15]], 14, 15]], 14, 15]], 8, 15]],
7, 16]], 7, 16]], 7, 16],
        ["path-absolute", [
          ["segment-nz", [
            ["pchar", [
              ["unreserved", [
                ["ALPHA", [], 17, 18]], 17, 18]], 17, 18],
            ["pchar", [
              ["unreserved", [
                ["ALPHA", [], 18, 19]], 18, 19]], 18, 19],
            ["pchar", [
              ["unreserved", [
                ["ALPHA", [], 19, 20]], 19, 20]], 19, 20]], 17, 20]],
                  16, 20]], 7, 20]], 5, 20]], 0, 20]

where `host` comes from RFC 3986. I do not see anything in the draft
calling for a different interpretation of `IPv6address` than what RFC
3986 calls for, so I am not sure what does not work here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: t.petch <[email-masked]>
Date: Mon, 12 Jan 2015 11:24:53 +0000

Meanwhile, back at the ranch, I remain an enthusiastic supporter of the
adoption of this I-D by APPSAWG.

Any URI scheme requires skills in the general issues of URIs (characters
used, percent encoding, etc) and in the issues of resolution for the
specific scheme and while there are other places where URIs surface in
the IETF, I think that this is the only place where both skills are
present.

I see the objective, were it to be codified as such, as updating the
file: scheme from the level of RFC1738 to the level of RFC3986 and not
attempting to go beyond that.

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "Matthew Kerwin" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>; "Larry Masinter"
<[email-masked]>
Sent: Thursday, January 01, 2015 6:37 AM
Subject: Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme

> before we can progress the document.

------------------------------------------------------------------------
--------