Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

[Brian E Carpenter <[e-mail]>]

Andrew,

On 07-Jul-21 08:05, Andrew Cady wrote:
> On Tue, Jul 06, 2021 at 02:45:41PM -0400, Michael Richardson wrote:
>>
>>     >> So why do the browser implementers have such difficulties with
>>     >> processing this?  Running code wins.
>>
>>     > There is no difficulty implementing it the way that I say to do
>>     > it!
>>
>>     > The difficulty (or rather, refusal) is implementing it the
>>     > broken way that the standard says to do.
>>
>> Well, each time I read your (multiple) posts, I see you describing
>> what I think that the standard already says.  Obviously, I'm wrong.
>>
>> You also seem to be disagreeing with Brian's text, which is why
>> I'm confused.  Maybe you could just make a pull request to Brian's
>> document?
> 
> The problem isn't with the changes Brian made.  Those changes were
> needed and good.  (By the way, thanks Brian.)
> 
> The problem is in what was left unchanged.  Brian did not break with
> rfc6874 but that break is what is needed.  We need to propagate the fix
> back to all relevant RFCs.
>  
> 
> Specifically, these definitions must change:
> 
>     ZoneID = 1*( unreserved / pct-encoded )
>     IPv6addrz = IPv6address "%25" ZoneID
> 
> 
> These definitions can be used instead:
> 
>     ZoneID = 1*( unreserved )
>     IPv6addrz = IPv6address "%" ZoneID
> 

Thanks for making a concrete proposal. My belief back when
we did RFC6874 was that this would not be acceptable in the
URI world. I'd be glad to test this belief again.
 
> By the way, there is a relevant mistake of fact in rfc6874:
> 
>     According to URI syntax [RFC3986], "%" is always treated as an
>     escape character in a URI,
> 
> The "always" part is untrue.  It is only treated that way where BNF says
> "pct-encoded".  Inside of square brackets it must instead be treated as
> an error.  Pct-encoded data is not allowed there. 

Well, it *is* allowed in a URI precisely because RFC6874 formally updates
RFC3986. I agree that the production for IPv6address in RFC3986 doesn't
include pct-encoded. However, RFC3986 section 2.4 says:

"Because the percent ("%") character serves as the indicator for
percent-encoded octets, it must be percent-encoded as "%25" for that
octet to be used as data within a URI."

As I recall the discussion nine years ago, that statement was taken
literally to mean *anywhere* in a URI. You are probably correct that a
strictly ABNF-driven parser wouldn't apply the escape mechanism except
within pct-encoded, but what do real-world parsers do?

Personally I'd be happy if we could make the change you suggest, but
we'd need to hear from the implementers.

   Brian