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

[Andrew Cady <[e-mail]>]

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






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.