Re: [Technical Errata Reported] RFC7622 (5769)

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

On Sun, Jun 30, 2019 at 5:49 PM RFC Errata System
<[email protected]> wrote:
>
> 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 protected]>
>
> 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