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==--