Brian Haberman's Discuss on draft-ietf-xmpp-6122bis-23: (with DISCUSS)

Brian Haberman has entered the following ballot position for
draft-ietf-xmpp-6122bis-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be a relatively straightforward DISCUSS and may not result in
any changes to the document...

I see this definition in the draft:
domainpart   = IP-literal / IPv4address / ifqdn
                     ;
                     ; the "IPv4address" and "IP-literal" rules are
                     ; defined in RFC 3986, and the first-match-wins
                     ; (a.k.a. "greedy") algorithm described therein
                     ; applies to the matching process
                     ;
                     ; note well that reuse of the IP-literal rule from
                     ; RFC 3986 implies that IPv6 addresses are enclosed
                     ; in square brackets (i.e., beginning with '[' and
                     ; ending with ']')

RFC 3986 was updated by RFC 6874 to allow zone identifiers in address
literals when the address is not globally scoped.  Was this considered in
the drafting of this update?  RFC 6874 updates the ABNF to be:

      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
      ZoneID = 1*( unreserved / pct-encoded )
      IPv6addrz = IPv6address "%25" ZoneID

I suspect you will get varying results depending on how many implementers
follow the Updates chain of 3986.