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

[Florian Schmaus <[e-mail]>]

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

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

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.

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

- Florian

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