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

[Peter Saint-Andre <[e-mail]>]

>From Barry's perspective, the short answer is: Hold For Document Update.
This is a bigger can of worms than an erratum can address...

Peter

On 7/1/19 4:53 PM, Matthias Wimmer wrote:
> I'd also like to point to http://unicode.org/reports/tr46/#Notation
> 
> According to the definition there labels are not only separated by
> U+002E but also three other types of full stops as well.
> 
> This definition has also been in RFC3490 section 4 (IDNA2003) but I
> cannot find it explicitly in IDNA2008. Not even in the list of things
> that have changed.
> 
> For the given example of 商业.中国 I think a Chinese user would more
> likely enter 商业。中国 because while entering Chinese characters there
> is no key on the keyboard, that would enter a Western full stop. So to
> enter 商业.中国 he would have to change his keyboard layout at least twice.
> 
> 
> Regards,
> Matthias
> 
> Am 2. Juli 2019 00:16:00 MESZ schrieb Barry Leiba <[e-mail]>:
> 
>     More evidence that correcting this properly goes to “Held for
>     Document Update”.  There needs to be proper discussion and arrival
>     at consensus, beyond the scope of an errata report.
> 
>     Barry
> 
>     On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
> 
> 
>         On Mon, 1 Jul 2019 at 14:18, Barry Leiba
>         <[e-mail] <mailto:[e-mail]>> 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/xmpp
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp
>