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

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

Andrew,

On 09-Jul-21 17:19, Andrew Cady wrote:
> 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.

We really need to hear from implementers about this. Assuming that we
have a constructive discussion during the upcoming 6MAN session,
outreach to implementers should be the next step, IMHO.

     Brian