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

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jul 2019 09:18:16 -0400

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

> > Characters valid for those are also valid
> > for R-LDH labels and A-labels as well,
>
> Not every code point which is valid for U-labels is allowed in A-labels.

Of course; the point is the other way around: because A-label
characters are valid, A-labels could be put there.  Do we want that?
Clearly, 商业.中国 is OK.  Is this text meant to allow
xn--vhqr8o.xn--fiqs8s ?  The text certainly says no, explicitly, but
"this means that" doesn't follow from the list of characters that are
allowed.  The text seems odd in that regard.

> I think R-LDH labels should not be explicitly disallowed, as this would
> mean that the PRECIS profile for XMPP addresses needs to become aware of
> the semantic of the string, instead of simply checking and performing on
> operations codepoints. But there is probably no use case for R-LDH
> labels in domainparts.

But that's already necessary because of what the text says about A-labels.

> > 2. Earlier, in Section 3.8, is this text that seems rather odd to me:
> >
> >    If the domainpart includes a final character considered to be a label
> >    separator (dot) by [RFC1034]
> >
> > When I look at RFC 1034, I see that there's no mention of label
> > separator at all, and no set of characters that are considered to be
> > so.  It simply says:
> >
> >    When a user needs to type a domain name, the length of each label is
> >    omitted and the labels are separated by dots (".").
> >
> > Is there a reason for that specific text in Section 3.2, or are we
> > just looking for the 'DNS label separator "dot" (U+002E, FULL STOP)'
> > as suggested in the errata report?
>
> I think so.

That's an "Is it A or B" question, so "I think so" doesn't answer it.
So I'll change the question and just ask if there's a reason to use
that text in Section 3.2 that cites 1034.  I think Peter is the best
person to answer that, as he wrote the text and might remember why it
was said that way.

> And yes, "label" and "Label separator" in RFC 7622 should
> probably be qualified with DNS and a reference to the relevant
> specifications should be inserted.
>
> > My sense is that the intended replacement *might* be this, though I'm
> > not sure and need discussion/confirmation:
> >
> >    An entity that prepares a string for inclusion in an XMPP
> > domainpart slot MUST
> >    ensure that the string consists only of NR-LDH labels and U-labels,
> > as defined
> >    in [RFC5890], separated by the DNS label separator "dot" (U+002E, FULL STOP).
>
> I just occurred to me, after submitting the errata of course, that this
> may not be enough. Since domainparts can also act as holder for IPv6
> addresses, we also need to allow ':', '[' and ']', as they are also not
> valid characters in NR-LDH labels and U-labels.
>
> Hence my refined replacement text would be:
>
>   An entity that prepares a string for inclusion in an XMPP domainpart
>   slot MUST ensure that the string consists only of
>   - codepoints allowed in NR-LDH labels and U-labels, as defined in
>     [RFC5890]
>   - . U+002E (FULL STOP, DNS label separator "dot")
>   - : U+003A (COLON)
>   - ] U+005B (LEFT SQUARE BRACKET)
>   - [ U+005D (RIGHT SQUARE BRACKET)

And all that tells me that this is likely to be "Held for Document
Update", if there's more discussion needed to sort out the real intent
and correct fix.  But I'd very much like to hear from Peter and/or Joe
before we settle this.

And, Florian, thanks for making the errata report and for the quick
response to discussion.

Barry

---

From: Florian Schmaus <[email-masked]>
Date: Mon, 1 Jul 2019 18:40:22 +0200

> characters are valid, A-labels could be put there.  Do we want that?

I do believe that this is the wrong question. We want to allow every
code point that is allowed in U-labels to be in XMPP domainparts. And
since I believe that every valid code point in an A-label is also a
valid code point of a U-label (could be wrong here), this means that
people could use 'xn--vhqr8o.xn--fiqs8s' as domainpart in their JID.
Thought it is probably not sensible to do so.

If RFC 7622 where to allow U-labels but explicitly disallow A-labels,
then we once again would need to perform a more costly operation on the
String because it would require to check the semantic.

> But that's already necessary because of what the text says about A-labels.

I see. Personally I would simply remove that requirement, since a PRECIS
preparation function can not tell if it is an A-label or just an
hostname which mimics an A-label.

FWIW I'd also remove the "In addition, the string MUST be encoded as
UTF-8 [RFC3629]." requirement, since it bears no benefit. But I am
drifting away from the topic.

> that text in Section 3.2 that cites 1034.
I am sorry, I believe there is a specific reason for that: It is
probably to normalize DNS names:

- example.org
- example.org.

are both the same DNS name.

> I think Peter is the best

Yep. I am also looking forward to some further comments on this from others.

> and correct fix.  But I'd very much like to hear from Peter and/or Joe

One more refinement of my proposed replacement text (sorry!). I am not
sure why the RFC currently explicitly mentions NR-LDH labels. AFAIKT all
code points in NR-LDH labels are also valid code points in U-labels. I
suppose it could be because U-labels are required to contain at least
one non-ASCII character. But then explicitly mentioning NR-LDH labels
appears to cause unnecessary complexity. It is probably enough and
easier to comprehend if the text simply states:

  An entity that prepares a string for inclusion in an XMPP
  domainpart slot MUST ensure that the string consists only of
  - code points allowed in U-labels as defined in [RFC5891]
  - . U+002E (FULL STOP, DNS label separator "dot")
  - : U+003A (COLON)
  - ] U+005B (LEFT SQUARE BRACKET)
  - [ U+005D (RIGHT SQUARE BRACKET)

- Florian

---

From: Dave Cridland <[email-masked]>
Date: Mon, 1 Jul 2019 23:10:48 +0100

> 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

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.

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. So, again, a SHOULD NOT if not a MUST NOT.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Jul 2019 18:16:00 -0400

More evidence that correcting this properly goes to “Held for Document
Update”.  There needs to be proper discussion and arrival at consensus,
beyond the scope of an errata report.

Barry

On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <[email-masked]> wrote:

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

---

From: Matthias Wimmer <[email-masked]>
Date: Tue, 02 Jul 2019 00:53:36 +0200

I'd also like to point to http://unicode.org/reports/tr46/#Notation

According to the definition there labels are not only separated by U+002E but also three other types of full stops as well.

This definition has also been in RFC3490 section 4 (IDNA2003) but I cannot find it explicitly in IDNA2008. Not even in the list of things that have changed.

For the given example of 商业.中国 I think a Chinese user would more likely enter 商业。中国 because while entering Chinese characters there is no key on the keyboard, that would enter a Western full stop. So to enter 商业.中国 he would have to change his keyboard layout at least twice.

Regards,
Matthias

Am 2. Juli 2019 00:16:00 MESZ schrieb Barry Leiba <[email-masked]>:
>> wasn't going to cause problems. So, again, a SHOULD NOT if not a MUST
>NOT..
>>
>>
>>> > >    If the domainpart includes a final character considered to be
>a
>>> label
>>> > >    When a user needs to type a domain name, the length of each
>label
>>> is
>>> > >    in [RFC5890], separated by the DNS label separator "dot"
>(U+002E,
>>> FULL STOP).
>>> >
>domainpart

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 1 Jul 2019 17:08:16 -0600

>From Barry's perspective, the short answer is: Hold For Document Update.
This is a bigger can of worms than an erratum can address...

Peter

On 7/1/19 4:53 PM, Matthias Wimmer wrote:
> According to the definition there labels are not only separated by
> U+002E but also three other types of full stops as well.
> 
> This definition has also been in RFC3490 section 4 (IDNA2003) but I
> cannot find it explicitly in IDNA2008. Not even in the list of things
> that have changed.
> 
> For the given example of 商业.中国 I think a Chinese user would more
> likely enter 商业。中国 because while entering Chinese characters there
> is no key on the keyboard, that would enter a Western full stop. So to
> enter 商业.中国 he would have to change his keyboard layout at least twice.
> 
> 
> Regards,
> Matthias
> 
>     More evidence that correcting this properly goes to “Held for
>     Document Update”.  There needs to be proper discussion and arrival
>     at consensus, beyond the scope of an errata report.
> 
>     Barry
> 
>     On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> 
> 
>         On Mon, 1 Jul 2019 at 14:18, Barry Leiba
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         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
> 
>         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.
> 
>         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. So, again, a SHOULD NOT if not a MUST NOT.
>          
> 
>             > >    omitted and the labels are separated by dots ("..").
>             > >
>             [email-masked] <mailto:[email-masked]>

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 2 Jul 2019 09:25:44 +0200

On 02.07.19 00:10, Dave Cridland wrote:
> On Mon, 1 Jul 2019 at 14:18, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 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.

> wants them to be different, I'm willing to mud-wrestle them for it, and

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.

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 2 Jul 2019 07:51:05 -0600

On 7/2/19 1:25 AM, Florian Schmaus wrote:
> On 02.07.19 00:53, Matthias Wimmer wrote:
> Thanks for pointing this out. From RFC3490:
> 
>    1) Whenever dots are used as label separators, the following
>       characters MUST be recognized as dots: U+002E (full stop), U+3002
>       (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
>       (halfwidth ideographic full stop).
> 
> We may want to consider adding a mapping rule from those to U+002E in
> the domainpart.

There's a reason IDNA is defined in terms of labels. If we update or
replace RFC 7622, we should do the same.

Peter

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 9 Jul 2019 14:02:21 +0200

> which I interpret as "use U-labels of your DNS name in the domainpart

While I have not personally experienced problems there definitely were
reports of people struggling with using A-labels during an XMPP summit
in Brussels. In particular they were struggling with using U-labels in
some and A-labels in other places. Many servers do not perform any
normalization in this regard when processing JID-slots. This caused
problems when e.g. the server configuration contained A-labels, but the
client configuration was done with U-labels, or vice versa.

The intend of 7622 (in particular Section 3.2.1) as I recall it was that
A-labels would generally be valid in JIDs. 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.

---

From: Florian Schmaus <[email-masked]>
Date: Tue, 9 Jul 2019 14:25:50 +0200

>> which I interpret as "use U-labels of your DNS name in the domainpart
=
> 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

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

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 9 Jul 2019 15:14:23 +0200

> The question here is: Do you mean A-label or "a string which is (also) a
Maybe you want to enlighten me what the distinction is you make here,
and how it is useful?
I can only imagine that it is one of intent. Yet, I'm having a hard time
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.

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

Regards,
Florian

---

From: Florian Schmaus <[email-masked]>
Date: Mon, 22 Jul 2019 10:54:59 +0200

> Maybe you want to enlighten me what the distinction is you make here,

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.

> 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