Subject: Comments on draft-ietf-6man-rfc6874bis-00.txt

From: "Shang Ye" <[email-masked]>
Date: Sat, 26 Mar 2022 19:24:07 +0800

Hi,

Here're some of my comments on this I-D:

Section 3 says:

> According to the text in Section 2.4 of [RFC3986], "%" must
> be percent-encoded as "%25" to be used as data within a URI.
> However, in the formal ABNF syntax of RFC 3986, this only applies
> where the "pct-encoded" element appears.  For this reason, it is
> possible to extend the ABNF such that the scoped address
> fe80::abcd%en1 would appear in a URI as http://[fe80::abcd%en1] or
> https://[fe80::abcd%en1].

The logic of this part seems a bit confusing. I guess the main problem here is whether we should interpret the "%" in an IPv6 scoped address as *data* within a URI. If we do so, then I'm afraid we wouldn't get the logic right here.

But if we don't, then I'd like to suggest several changes in the text:

1. Clarify that the "%" in an IPv6 scoped address is not used as *data* within a URI, but is instead acting as a subcomponent *delimiter* within the address. This way, the text in the I-D wouldn't somehow conflict with that in RFC 3986.

2. If (1) was accepted, add "%" as a reserved character in the "gen-delims" ABNF rule. This makes the I-D consistent with RFC 3986:

> A reserved subset of
> those characters may be used to delimit syntax components within a
> URI while the remaining characters, including both the unreserved set
> and those reserved characters not acting as delimiters, define each
> component's identifying data. (Section 2)
>
> URIs include components and subcomponents that are delimited by
> characters in the "reserved" set. (Section 2.2)

3. If (2) was accepted, clarify that "%" is considered as a reserved character only when used within an IPv6 scoped address. This prevents the I-D from conflicting with RFC 3986 in a way that the "%" in a percent-encoded octet would be affected by the following text:

> If a reserved character is found in a URI component and
> no delimiting role is known for that character, then it must be
> interpreted as representing the data octet corresponding to that
> character's encoding in US-ASCII. (Section 2.2)

Shang

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Mar 2022 09:11:04 +1300

Hi Shang,

Thanks for your input. Some comments below in line:

> The logic of this part seems a bit confusing. I guess the main problem here is whether we should interpret the "%" in an IPv6 scoped address as *data* within a URI. If we do so, then I'm afraid we…

I find the text in RFC3986 very confusing. When we looked at it ten years ago, we naturally interpreted it as the ABNF in RFC6874 defines, i.e. requiring percent-encoding. Andrew Cady argued the opposite a few months ago, and suggested the revised ABNF that is now in RFC6874bis. If the URI parsing obeys the ABNF, either would be OK and we can choose the one we like best.

When I looked at the WGET parser, which is relatively simple to understand, the first thing I realised is that it is *not* following the ABNF in any automated way (like a syntax-driven compiler would, for example). I also looked at the way Firefox parses URLs, which is very hard to understand, but the same is true. From feedback we (the authors) have received, I believe that all browsers are similar: the parsers do what the programmers make them do, rather than mathematically following the ABNF. Further, the WHATWG specifies the agreed behavior in plain English, not in ABNF (https://url.spec.whatwg.org/#host-representation). That is what the browser implementers follow.

So, those confusing words in RFC3986 are just... confusing.

The real-world description of percent-encoding is at https://url.spec.whatwg.org/#percent-encoded-bytes

> 1. Clarify that the "%" in an IPv6 scoped address is not used as *data* within a URI, but is instead acting as a subcomponent *delimiter* within the address. This way, the text in the I-D wouldn't…

I would rather say that the words in RFC 3986 are unclear, but that percent-encoding does not apply to this use of % as a delimiter. That's what our new ABNF says.

> 2. If (1) was accepted, add "%" as a reserved character in the "gen-delims" ABNF rule. This makes the I-D consistent with RFC 3986:

I suspect that this would lead to a lot of discussion about unintended side-effects. Since "%" is primarily an escape character, adding it formally as a delimiter would be dramatic. When is it a delimiter and when is it an escape?

> 3. If (2) was accepted, clarify that "%" is considered as a reserved character only when used within an IPv6 scoped address. 

That is surely the effect of the proposed ABNF? Adding it as a comment seems reasonable, though.

> This prevents the I-D from conflicting with RFC 3986 in a way that the "%" in a percent-encoded octet would be affected by the following text:
> 

To be frank, I don't think RFC3986 matters much today, although from an IETF view we need to formally update it. What matters is getting the above "host-representation" text from WHATWG updated.

Regards
    Brian