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

[Barry Leiba <[e-mail]>]

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