Re: Brian Haberman's Discuss on draft-ietf-xmpp-6122bis-23: (with DISCUSS)
Brian Haberman <[email protected]> Wed, 10 Jun 2015 13:55:00 -0400
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
Hi Peter, On 6/10/15 1:22 PM, Peter Saint-Andre - &yet wrote: > Hi Brian, thanks for the review. > > On 6/10/15 8:28 AM, Brian Haberman wrote: >> 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. > > My apologies, I forgot that RFC 6874 updated RFC 3986 in this regard. If > we keep this text, I agree that we should point to RFC 6974. Agreed. > > RFC 6122 had this text: > > ; 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 ']'), which was not > ; the case in RFC 3920 > > We could, I suppose, remove this text entirely since it was meant to > give implementers notice about the change from RFC 3920 to RFC 6122. > However, I think it's always good to keep implementation notes of this > kind. So, looking at this again, I think I would change it to: > > ; the IPv4address and IP-literal rules are > ; defined in RFC 3986 and RFC 6874 respectively, > ; and the first-match-wins (a.k.a. "greedy") > ; algorithm described in Appendix B of RFC 3896 s/3896/3986/ > ; applies to the matching process > ; > ; note well that reuse of the IP-literal rule from > ; RFC 6874 implies that IPv6 addresses are enclosed > ; in square brackets (i.e., beginning with '[' and > ; ending with ']'), which was not the case with > ; the definition of the XMPP address format in > ; RFC 3920 > > However, I might want to move the last paragraph to an implementation > note (not an ABNF comment) so that we have a proper reference to RFC 6874. I agree that a proper reference to 6874 would be useful. Is there any need to mention the potential for a literal to include the zone id? Brian _______________________________________________ xmpp mailing list [email protected] https://www.ietf.org/mailman/listinfo/xmpp
signature.asc
(application/pgp-signature, 481 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVeHn5AAoJEBOZRqCi7goqbQkIAMplwuAIkGbC4rvA4vEtl/bO 2iW0fevBDIAAqSdIlEgW5p4dLtjQBTwyJKEEuRlPBaZoagKDwo2fZFeAJshHoBZb Hl0n1hpSx/FI8ZhNmus/8e1JUaXjTdh3d881eAWgSgYs9TmHEwd2LcWbnZwbX2Mu CDZ2koU86jIEj3uhNHqDNs1B1GXt5FzqVg647uJacUs/Ju4Z1oDP4UIvZvrSeZsC 5pMT+/8JAw3F0AVyguNWuQW3lQK2jsZV8qRbmHL05N7uZANl73BYcLEiWMv6Malf xLkpDMYVvOyK34tqKkNI2EPBs+42/NW99bd6zPkB85cBzpFmqXmjGH3OvfqCgNU= =VQEu -----END PGP SIGNATURE-----