Re: [Technical Errata Reported] RFC7622 (5769)
Florian Schmaus <[email protected]> Tue, 9 Jul 2019 14:25:50 +0200
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============7740425023140012890== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16 Content-Type: multipart/mixed; boundary="pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs"; protected-headers="v1" From: Florian Schmaus <[email protected]> To: [email protected] Message-ID: <[email protected]> Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769) References: <[email protected]> <CALaySJJ0t58BgMYE6G9XLFc-ydskvV6CS48d9++8xBfNZ_cLDg@mail.gmail.com> <[email protected]> <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com> <CAKHUCzwg6sPtN0Dp6zPfKT75+DbfE0xies3Wv7GujXes6jY0Ng@mail.gmail.com> <[email protected]> <[email protected]> In-Reply-To: <[email protected]> --pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 09.07.19 14:02, Florian Zeitz wrote: > Am 02.07.19 um 09:25 schrieb Florian Schmaus: >>> c) I don't think we want A-Labels. It's just going to cause confusion= - >>> is=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as=C2=A0xn--vh= qr8o.xn--fiqs8s? They always look up the >>> same in DNS, after all, by definition. I can't see why we'd think >>> allowing them wasn't going to cause problems. >> >> I can not remember that I ever ran into problems caused by A-labels in= >> domainparts. And hence I assume that the cost of explicitly disallowin= g >> them isn't worth the gain. If we can, we should not make the PRECIS >> operations on the domainpart to require anything besides the >> "inspection" of every code point, with as less as possible context >> around the inspected code point involved. >> >> Note that instead of forbidding A-labels / ACE in domainparts, RFC7622= >> currently states in =C2=A7 5. >> >> XMPP applications MUST support IDNA2008 for domainparts >> >> which I interpret as "use U-labels of your DNS name in the domainpart >> (if applicable)". >> >> - Florian >> =3D >=20 > The intend of 7622 (in particular Section 3.2.1) as I recall it was tha= t > A-labels would generally be valid in JIDs. The question here is: Do you mean A-label or "a string which is (also) a valid A-label"? > However, software would be > required to process (user) input containing A-labels so that any > JID-slots would only contain U-labels on the wire. Exactly. This is an important insight: Any string which is a valid A-label may be valid in the domainpart of a Jid. However, if this string got derived from an U-label, then you did something wrong. As JID domainparts constructed from DNS names which contain U-label(s) should conserve the U-label presentation (and not use the ACE/A-label form). - Florian --pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs-- --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0kh85fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFJmVQgAuidS5Q7HQD1x7OyStyv6wh6JrZieHbk5oTRiHQHLt7AJRrfX5Vg8B2It bDy31WGkrgkYsZDoM5Y1FGz5Xtsn2XAcrT6CqcnwqsVEl9D1A34c6lO4CIMr+Bcr ygDg5aOmJKg5wxpYefIg9WN35QpIDcxV4JW0T5nbS5MzJysi9wjnnILBYsdu5mUz NF00wgplMtHRZGw3Qu4qe8ykSN8xJ1n7eFOWdljS7I3gqgebSImbi2kF6EhV7Oxb U29xYTxAn5d8F4kBJpTXc1KyTahOHkPGuYZrWPUmmCjpSLrY+lLV6NM3LbRHslIn ec/Flx8nWKEPywbTVJZchq1a/CTtKw== =bLp/ -----END PGP SIGNATURE----- --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16-- --===============7740425023140012890== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xmpp mailing list [email protected] https://www.ietf.org/mailman/listinfo/xmpp --===============7740425023140012890==--