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

From: RFC Errata System <[email-masked]>
Date: Sun, 30 Jun 2019 14:49:21 -0700 (PDT)

The following errata report has been submitted for RFC7622,
"Extensible Messaging and Presence Protocol (XMPP): Address Format".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5769

--------------------------------------
Type: Technical
Reported by: Florian Schmaus <[email-masked]>

Section: 3.2.1

Original Text
-------------
An entity that prepares a string for inclusion in an XMPP domainpart
slot MUST ensure that the string consists only of Unicode code points
that are allowed in NR-LDH labels or U-labels as defined in
[RFC5890].

Corrected Text
--------------
An entity that prepares a string for inclusion in an XMPP domainpart
slot MUST ensure that the string consists only of Unicode code points
that are allowed in NR-LDH labels or U-labels as defined in
[RFC5890], or the DNS label separator "dot" (U+002E, FULL STOP).

Notes
-----
The current specification forbids the inclusion of dots (".") in the domainpart, since they are not allowed in NR-LDH nor U-labels. But they should be allowed, as otherwise a DNS name could never be put into an XMPP domainpart (which is commonly done).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7622 (draft-ietf-xmpp-6122bis-24)
--------------------------------------
Title               : Extensible Messaging and Presence Protocol (XMPP): Address Format
Publication Date    : September 2015
Author(s)           : P. Saint-Andre
Category            : PROPOSED STANDARD
Source              : Extensible Messaging and Presence Protocol
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Jun 2019 18:23:35 -0400

This report seems basically correct to me, though I'm not sure the
suggested fix is the right one, so let's have some discussion first:

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?  Characters valid for those are also valid
for R-LDH labels and A-labels as well, so it seems a bit of a
confusing way to define it (in particular, "xn--" are all valid
characters in U-labels, but my sense is that we do not want labels in
XMPP "domainpart" to actually be A-labels... right?).  Similarly, do
we intend to allow R-LDH labels in XMPP "domainpart"?  The characters
are valid, so they would be allowed by the cited text.

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?

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

Barry

---

From: Florian Schmaus <[email-masked]>
Date: Mon, 1 Jul 2019 07:56:11 +0200

On 01.07.19 00:23, Barry Leiba wrote:
> 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.

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

> so it seems a bit of a

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.

> as suggested in the errata report?

I think so. 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.

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

- Florian