Re: Next steps for rfc6874bis

[Carsten Bormann <[e-mail]>]

On 2021-08-18, at 15:18, Philip Homburg <[e-mail]> wrote:
> 
> In your letter dated Wed, 18 Aug 2021 08:39:41 +1200 you wrote:
>> On 17-Aug-21 22:30, Philip Homburg wrote:
>>>> Andrew offered ABNF to back up his assertion, I can't point to it from my
>>>> phone but you'll find it upthread somewhere. Whether real world parsers can
>>>> respect it is a question for the parser authors.
>>> 
>>> If I got it correct he is basically saying that RFC 3986 is wrong. 
>>>> From https://mailarchive.ietf.org/arch/msg/ipv6/ocNXw2Tl7YnOXOVjnUJ_VS7PI88/
>>> "That is a bug.  The '%' must be treated as the syntactic delimiter it is.
>> 
>> Well, the issue is that the prose in RFC3986 isn't really consistent
>> with the ABNF, where the pct-encoded construct is precisely defined and used.
>> A parser that strictly follows the ABNF will only apply percent encoding
>> (and decoding) where the ABNF tells it to, not to the whole string. That's
>> exactly the point we need to discuss with the implementers in WHATWG.
> 
> I checked some running code:
> https://f%31.example.com/
> is accepted by Chrome, Firefox, and Safari as https://f1.example.com/.

Correct, reg-name includes pct-encoded.

> Curl doesn't do percent processing and seems to be clearly wrong here.

Indeed.

> https://192.168.1.%31/
> is accepted by Chrome, Firefox, and Safari as https://192.168.1.1/.

Incorrect.

> Curl doesn't do percent processing and tries to resolve '192.168.1.%31'.

Correct.

> https://[2001:0DB8::%31]/
> is accepted by Chrome as https://[2001:0DB8::1]/

Incorrect, IPv6address does not include pct-encoded.

> It is rejected by Firefox and Safari as invalid.

Correct.

> Curl doesn't do percent processing and possibly treats it as a zone ID.
> 
> So it seems that curl violates Section 3.2.2 of RFCC 3986, because that
> section explicitly calls for percent processing for 'registered' names.
> 
> Chrome is consistent and applies percent processing to both IPv4 and IPv6
> literals even though the RFC does not explictly require that.

It’s not that it doesn’t require that; it does not allow that.

> Firefox and Safari seem inconsistent in applying percent processing to
> IPv4 literals but considering IPv6 literals with percents as invalid.

Of course, the problem as usually is that ABNF is being used to describe the input to a process (pct-decoding), when implementers are quite likely to apply it to the output of the process.  But at least RFC 3986 appears to be self-consistent here.

>> We (the IETF) are "they". Unfortunately, there's another "they", the
>> implementers, and in the end the implementers win, because running
>> code trumps rough consensus.
> 
> So it seems that the running code does random things unrelated to the
> RFC. And there is not a lot of agreement in the running code.
> 
> Best to avoid this mess and pick a new separator for zone IDs.

Note that, when fixing this, there is absolutely no reason to change 4007 from “%” — note that 4007 doesn’t have square brackets either.  6874bis could (continue to) introduce square brackets and a new delimiter with that.  Choosing, say, / would probably be not too wise, but just about anything else that cannot go into IPv6address (HEXDIG, :, .) is fair game.

Grüße, Carsten