Re: [apps-discuss] presumption that RFC3986 is correct

[Sam Ruby <[e-mail]>]

On 01/03/2015 01:56 PM, Stephen Farrell wrote:
>
> Hi Sam,
>
> On 03/01/15 17:54, Sam Ruby wrote:
>>
>> I intend to work with implementors, providing patches and/or new
>> implementations along the way.  And I'll continue to document and
>> publish findings.  One such place I have published such work is at the
>> W3C:
>>
>>    http://www.w3.org/TR/url/
>
> I have at least one question about how you (or W3C, or any of us)
> plan to head towards some reasonable level of completeness with
> that work. (This may be a bit of an aside in the current discussion,
> or maybe not, I'm not sure.)
>
> The draft at the URL above includes [1], which is a risibly small
> and fixed (?) subset of an IANA registry. [2] What's the plan for
> making that sensible? I would assume pointing at the IANA registry
> is the simple and obvious fix there, but am puzzled as to why that
> hasn't been done in the few years this text has been around.
>
> Is that just an oversight? Or is your work really only covering
> exactly that particular subset of schemes? Or something else?

This is a valid question, and the subject of an open bug:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233

So the short answer is: it is a known issue, and suggestions are welcome.

The longer answer isn't all that much longer.  Given that every modern 
programming language (and for that matter, every browser) will have a 
part of their runtime library a concept of either a URI or a URL, and a 
method to parse a string into such a structure, the question you pose is 
equivalent to: "how should URI.parse methods handle unknown schemes"?

Possible answers include: treat the content as hierarchical, and treat 
the content as opaque.  There may be other answers.

What there probably needs to be is a sane default, and a way to register 
new schemes.  At the moment, the URL Working Draft treats unknown 
schemes as opaque.  The bug suggests that hierarchical might be a better 
choice.

As to registration, at the moment that is undefined.  The spec literally 
says "..." at this point:

   http://www.w3.org/TR/url/#url-writing

The hope is to work together with the authors of the following 
Internet-Draft:

   https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg

This is mentioned in bullet 3 of the following section:

   https://tools.ietf.org/html/draft-ruby-url-problem-00#section-4

Meanwhile, patches are welcome!  It may be that there are certain URI 
schemes that defy conventional classification (file: certainly comes to 
mind, there may be others) that need to be specified explicitly in the 
specification.

The easiest way to participate is to propose tests in the form of input 
strings, base strings, and expected results.  That data will be added to:

https://github.com/w3c/web-platform-tests/blob/master/url/urltestdata.txt

And I'll use that data to update:

https://url.spec.whatwg.org/interop/test-results/

Should you feel inclined to suggest changes to the URL spec, I'd 
encourage you to look at the following which contains an incomplete but 
significantly reworked parser:

https://specs.webplatform.org/url/webspecs/develop/

That repository has a bunch of other things, including the evaluation 
scripts and a reference implementation.  More information can be found here:

https://github.com/webspecs/url#the-url-standard

> Thanks,
> S.

- Sam Ruby

> [1] http://www.w3.org/TR/url/#relative-scheme
> [2] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml