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

[Ted Hardie <[e-mail]>]

Hi Brian,

On Wed, Jul 7, 2021 at 3:17 AM Brian E Carpenter <
[e-mail]> wrote:

> 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.
>
>
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).

I'd also like to draw your attention to RFC 8820, which updates RFC 3986 to
give best practices in defining structure and semantics in URIs.  Its
guidelines, specifically in section 2, may help guide your thinking here.

As a practical matter, I suggest you ask for a slot in the upcoming
DISPATCH/ART area open meeting; that will help get a different community
focused on your proposal.

best regards,

Ted Hardie


> > 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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>