Re: [xmpp] [Technical Errata Reported] RFC7622 (5769)

[Florian Schmaus <[e-mail]>]

On 02.07.19 00:10, Dave Cridland wrote:
> On Mon, 1 Jul 2019 at 14:18, Barry Leiba <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > > 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)
>     >   Those are potentially longer strings then DNS labels are allowed to
>     >   be.
> 
>     OK, so there's more to it than that.
> 
> 
> Hold your horses - I'm not sure that's actually true.
> 
> In particular:
> 
> 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 the
> subject of a DNS request - see, for
> example, https://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 商业.中国 the same as xn--vhqr8o.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 § 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