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

On Mon, 1 Jul 2019 at 14:18, Barry Leiba <barryleiba@computer.org> wrote:

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

> > > 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
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp
>