Re: [apps-discuss] Potential issues in RFC 3986

[Sam Ruby <[e-mail]>]

On 01/02/2015 10:37 AM, Julian Reschke wrote:
> On 2015-01-02 16:18, Sam Ruby wrote:
>> ...
>>> I fully accept that there may be desirable agent behaviours that are not
>>> covered here, and that an additional document may be desired to describe
>>> these, particularly where the behaviours impact interoperability.
>>
>> I would like to discuss that topic too.
>>
>> Whether that document is separate or not will depend on the outcome of
>> the discussion as to whether RFC 3986 matches current, deployed
>> applications.
>> ...
>
> It could be separate, even if we find out that we want to update RFC 3986.

Agreed.

The case where being separate would be made more difficult would be the 
case where the IETF did not agree to update RFC 3986.

>> ...
>>> For me, the question of what URI.parse *does* goes beyond what the core
>>> URI spec needs to define.  But I agree about operating system specific
>>> behaviours of file: URIs being outside the desirable scope of that core
>>> spec.
>>
>> Can I get you to explain what you mean by this.  We can ignore operating
>> system specific behaviors for the moment.  I would think that the basic
>> operation of identifying the scheme, path, fragment, etc for a given
>> input is exactly what a URI spec needs to define.  Why do you think
>> otherwise and/or what am I missing?
>> ...
>
> RFC 3986 does that for valid URIs, as far as I can tell. If you take the
> non-normative regexp in the appendix into account, it even des that for
> many more strings.

If you limit it to pure US ASCII inputs, it certainly gives precise 
answers.  The question is whether it gives accurate answers.

>> ...
>>> In a brief sampling, I couldn't see any divergence which is likely to be
>>> resolvable by changing the URI spec.
>>
>> I encourage you to spend more time with that data.  An example of a
>> concrete problem is handing of hosts in a UTS-46 compliant manner.
>> ...
>
> Which test, specifically?

Most of the tests in the range of 242..263 deal with IDNA issues in some 
manner or another.  A particularly fun one is test 261:

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

<aside>ordinal test numbers may change over time.  The hash, however, 
will not</aside>.

I encourage you to scan the text of RFC 3986 for the term "IDNA".  In 
the decade between when RFC 3986 was published and today, things have 
progressed a bit here.

> Best regards, Julian

- Sam Ruby