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

[Stephen Farrell <[e-mail]>]

Hiya,

On 03/01/15 20:46, Sam Ruby wrote:
> 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.

My suggestion: a) reference the IANA registry for schemes and b) the
same for port numbers and then c) list which subsets of those the
additions to 3986 (*) in the w3c document cover. That is, I don't think
you need to try provide additional rules/text for all schemes but you
do need to specify which you cover.

(*) I'm assuming a sensible model where [1] ends up as a set of
additional specifications on top of 3986 (or on top of 3986+errata
or on top of a 3986bis if one ends up being needed).

   [1] http://www.w3.org/TR/url/

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

That's a good plan. It's (welcome) news to me though, but good to
hear. Are the editors of [1] and that draft in contact already?

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

That depends on who you are I guess:-) For me, that is not the best
way (nor easiest) to participate.

Cheers,
S.

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