Re: [IPv6] [Last-Call] Artart last call review of draft-ietf-6man-rfc6874bis-02

I like this thread put IDNA as a very bad example of not using
UTF-7 or (percent encoded) UTF-8.

Rob Sayre wrote in
 <CAChr6SxZvrdh-OTB-dwEbABQcpoYKJiWd=JUBpku=cnW4K=X-Q@mail.gmail.com>:
 |On Mon, Mar 27, 2023 at 1:39 PM Brian E Carpenter <
 |[email protected]> wrote:
 ...

RFC 3986 says

   When a URI is dereferenced, the components and subcomponents[.]
   must be parsed and separated before the percent-encoded octets within
   those components can be safely decoded

So

      host        = IP-literal / IPv4address / reg-name

is ey itself, and since reg-name

   reg-name      = *( unreserved / pct-encoded / sub-delims )
      unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
      pct-encoded   = "%" HEXDIG HEXDIG
      sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                      / "*" / "+" / "," / ";" / "="

must not contain [, as does

      IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet

this entire thread only applies to

      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

which is an isolated part in between a pair of brackets.
And in there the percent denoting an address scope of RFC 4007 is
not allowed.
To me it is nonetheless isolated, and the hyphen-minus os not
allowed by itself, too.  So this thread is about parsers which
mistakenly think that a percent-sign in between the isolated pair
of IP-literal indicating brackets denotes percent encoding, and
these parsers are to made valid ones by letting them fail for the
invalid hyphen-minus instead of the (likely) falsely decoded IPv6
scope which follows the percent-sign.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art