Re: [Technical Errata Reported] RFC7622 (5769)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============4271133336734730288==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn
Content-Type: multipart/mixed; boundary="SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n";
 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]>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>

--SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable

On 09.07.19 15:14, Florian Zeitz wrote:
>>> The intend of 7622 (in particular Section 3.2.1) as I recall it was t=
hat
>>> 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"?
>>
> Maybe you want to enlighten me what the distinction is you make here,
> and how it is useful?

Of course. As I wrote in a previous mail, I want to avoid PRECIS for the
domainpart to require anything more heavyweight besides what is most of
the time a codepoint-by-codepoint validation routine. Otherwise
implementations have to perform a semantic analysis of the given string
in order determine if they are dealing with a DNS Name consisting of
only A-labels or an IPv4/v6 address, or something which is potentially
forbidden. I think that adds unnecessary complexity and is overkill, as
validating XMPP implementations would perform that on every inbound JID
they encounter.

> I can only imagine that it is one of intent. Yet, I'm having a hard tim=
e
> imagining people creating labels that consist of 'xn--' followed by a
> valid punycode encoding of IDNA-valid codepoints, but insisting these
> are not an A-label.
>=20
>>> 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 stri=
ng
>> 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).
>>
> It seems to me that you are implying that software should not convert
> something that looks like an A-label to a U-label either?
> I.e. each label of a domainpart always has to remain in the
> representation provided by the user?

Not at all. I am only talking about what is allowed on the wire. We are
also in the fortunate situation that domainparts do not require ASCII
compatible encoding (ACE), and users are used to enter the IDNA/U-label
representation of a DNS name in their XMPP (client) software. Whether or
not software checks if the entered string into its UI is an A-label, is
not part of what I am considering. Although if I would, then I'd
probably argue that users do usually not enter ACE / A-label into UIs.
How often have you entered xn--ber-goa.de into your browser? Of course,
it potentially can not hurt if the software tries to convert those to
U-labels. But that is not a concern of the wire protocol which RFC7622
describes, although a note about this would probably be helpful.

- Florian


--SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n--

--S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl01eeNfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3
NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF
IFK7Cgf/eJd7cz88WOW75KyrX/lYgEI/EMsYu20m3aBlKQih9uSf/RY+4xBuSynO
U/h4ujRoUneH51QHweenkmM+nE1FqfShLZtOOMIcnZMuplM5Y+e4U11FYiu2Mvv3
3DoczO2xfYed9Upp2rZtBK03mowvoo+VVlkoo5l53YT8+kMx8ek6grd7ZzarNIJV
fn36Y6MEfX8zCU54GDD+totzBXLxmwHxi9I9s0tN82w9UEXUz4bQQZKAFTNBIxad
v858k3KWRJz/c0r0SVj1/wmuUFkrKvSg5WBN9u5/Tc/n/ZgMSmkjZWMk8diIRwbc
ESg+Ot7scfBnx7aWufVSaDmYSYbjCQ==
=Mb/z
-----END PGP SIGNATURE-----

--S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn--


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

--===============4271133336734730288==--