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

[Andrew Cady <[e-mail]>]

On Thu, Jul 08, 2021 at 09:56:43AM +1200, Brian E Carpenter wrote:
> On 07-Jul-21 19:39, Ted Hardie wrote:
> >
> > The difficulty with this approach is that it requires you to treat
> > the % with different semantics depending on where it occurs in the
> > URI. 
> >
> > From a specification perspective, that's a major change from the
> > philosophy in the development of URIs which were attempting to be,
> > well, uniform.  From a practical perspective, it may look easy when
> > you use a parser with a specific order of operations, but it ends up
> > ossifying that order into the base spec.  That may not be a great
> > thing (or possibly, given the breadth of schemes which might use
> > this production).
>
> Exactly my point, Ted, but Andrew disputes it.

I acknowledge that you can't pct-decode unreserved characters on a
first pass before parsing out the IPv6 literal field and still use the
unencoded % as syntax within that field.

Yet even a parser that _does_ decode unreserved before parsing still
won't ever mix up the _boundary_ of the IPv6 address based on whether %
is within it.  So why does it matter?

Either an implementation has been updated to support the fe80 address
syntax or not.

If not, the fact those addresses won't work doesn't matter.  It only
matters whether a failure mode is harmful.  It looks like the failure
mode is at worst IPv6 parse constructing an unzoned fe80 address that
can't be connected to, and in practice probably a parse error like "URL
using bad/illegal format or missing URL".

If the implementation has been updated, the update can simply include
not decoding %25 within the square brackets.