Re: [Technical Errata Reported] RFC7622 (5769)

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

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX
Content-Type: multipart/mixed; boundary="8rICfo8CI0pzmhBA1uEE2T5CxRpyhZUVc";
 protected-headers="v1"
From: Florian Schmaus <[email protected]>
To: Dave Cridland <[email protected]>, Barry Leiba <[email protected]>
Cc: Joe Hildebrand <[email protected]>,
 Alexey Melnikov <[email protected]>, XMPP Working Group
 <[email protected]>, Peter Saint-Andre <[email protected]>,
 RFC Errata System <[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>
In-Reply-To: <CAKHUCzwg6sPtN0Dp6zPfKT75+DbfE0xies3Wv7GujXes6jY0Ng@mail.gmail.com>

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

On 02.07.19 00:10, Dave Cridland wrote:
> On Mon, 1 Jul 2019 at 14:18, Barry Leiba <[email protected]
> <mailto:[email protected]>> wrote:
>=20
>     > > 1. Is this bit of text intended to say that "domainpart" has to=

>     > > *consist of* NR-LDH labels and U-labels, rather than to contain=

>     > > characters valid for those?
>     >
>     > XMPP domainparts may contain
>     > - IPv4/v6 addresses
>     > - DNS names
>     > - "Hostnames" (more or less arbitrary XMPP service identifiers)
>     >=C2=A0 =C2=A0Those are potentially longer strings then DNS labels =
are allowed to
>     >=C2=A0 =C2=A0be.
>=20
>     OK, so there's more to it than that.
>=20
>=20
> Hold your horses - I'm not sure that's actually true.
>=20
> In particular:
>=20
> a) I don't think that IPv4/IPv6 addresses actually belong there. Some
> existing client libraries and servers can handle that, but it's not
> clear it works outside a single server (ie, with S2S links). At best,
> this would be a SHOULD NOT in my opinion. For a start, most of the rest=

> of the langauge makes no sense, since it assumes these things can be th=
e
> subject of a DNS request - see, for
> example,=C2=A0https://tools.ietf.org/html/rfc6120#section-3.2

Even assuming that IPv4/v6 addresses in domainparts would not work
outside a single server, they are useful in test deployments and the
like, and hence it does not appear to be sensible to strictly forbid
them in domainparts.

You obviously do not need a DNS lookup if you already have an IP. I do
not think that RFC6120 needs to explicitly mention that, but maybe it
does not hurt either.

> b) Arbitrary labels are syntactically the same as U-Labels. If anyone
> wants them to be different, I'm willing to mud-wrestle them for it, and=

> nobody should want that.

Depends on your definition of "arbitrary labels" I guess. Are they
allowed to contain other code points besides those valid in U-labels?
How long are they allowed to be? U-labels come with an indirect length
restriction. POSIX limits the maximum hostname, which is sometimes used
as domainpart, to 255 bytes, but this would exceed the maximum of 63
bytes of a DNS label.

> 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--vhqr=
8o.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 disallowing
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


--8rICfo8CI0pzmhBA1uEE2T5CxRpyhZUVc--

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

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

iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0bBvhfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3
NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF
IFKU4Af+PN2SDzQiYUX641uVjxh85u/+T4+WBy/Nl3MtPOx+mPYINKE5n2ayGTX5
B/1PqdZotl8Ur2LkMDwDNKSpV5M+B9nNpo/mjepXLwf90Pj0O/DoflYyS9bAbfey
ucMFU0fPohlI+RrjjEYcd74w52s42RhcDbUOcwPVOfL7x3IhGTvBj/JzDdcGRDKW
bpKLWyw6CbWuBoDqRxdWpCFONWZMZV00PuMoGJx1BCs3vBWXO+s1yqaA4+j3qE+O
2Bzd746EKsJMy5bAkX49ZW7sS31Mwjbqu36E0DmvxA4+zi0WpX6Cs9JBOkEFtQ+N
WfEsWNHkGwgiGRepQU+wj+P+mP7l4w==
=ubUC
-----END PGP SIGNATURE-----

--93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX--


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

--===============6875148501655620215==--