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

Matthias Wimmer <m@tthias.eu> Mon, 01 July 2019 22:53 UTC

Return-Path: <m@tthias.eu>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085212014B for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 15:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tthias.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWhaXvXKiwPX for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 15:53:44 -0700 (PDT)
Received: from jade.amessage.eu (jade.amessage.eu [78.47.103.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5621200CE for <xmpp@ietf.org>; Mon, 1 Jul 2019 15:53:44 -0700 (PDT)
Received: from [IPv6:2a02:810d:4bc0:7852:988c:b442:ddcc:b97a] (unknown [IPv6:2a02:810d:4bc0:7852:988c:b442:ddcc:b97a]) by jade.amessage.eu (Postfix) with ESMTPSA id E14F94238383; Mon, 1 Jul 2019 22:53:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tthias.eu; s=dkim; t=1562021588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XihZ65awNJSuPhzJ+4d6GPFoX0GcsfPePW55OC1hkow=; b=AU8vUKu9+Axsqep1s+/O5juW91x7yEJ8THtToJwu5GLY8EakmQzS5ZaCMSonhvntt/SwlJ PsrHR7HDo+sAf7mU3OJlI1pUO6MSCk3WW6XbGDT7xrTMdXIxmtHsrqYVl6rs+I5TJBd2Bb FPgQZNZzC7rcsLQgUn5TmAiANTC2cjk=
Date: Tue, 02 Jul 2019 00:53:36 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <CALaySJKcozQ7sQJvQHMVq2m9mFT2=jXc5wVd=pqMWSZK_=Qr7A@mail.gmail.com>
References: <20190630214921.40238B81D6A@rfc-editor.org> <CALaySJJ0t58BgMYE6G9XLFc-ydskvV6CS48d9++8xBfNZ_cLDg@mail.gmail.com> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com> <CAKHUCzwg6sPtN0Dp6zPfKT75+DbfE0xies3Wv7GujXes6jY0Ng@mail.gmail.com> <CALaySJKcozQ7sQJvQHMVq2m9mFT2=jXc5wVd=pqMWSZK_=Qr7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ"
Content-Transfer-Encoding: 7bit
To: xmpp@ietf.org, Barry Leiba <barryleiba@computer.org>, Dave Cridland <dave@cridland.net>
CC: Joe Hildebrand <hildjj@cursive.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, XMPP Working Group <xmpp@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>, RFC Errata System <rfc-editor@rfc-editor.org>
From: Matthias Wimmer <m@tthias.eu>
Message-ID: <A706356F-9902-4CF9-88E2-D96D1FDE5F67@tthias.eu>
Authentication-Results: ORIGINATING; auth=pass smtp.auth=m@tthias.eu smtp.mailfrom=m@tthias.eu
Archived-At: <https://mailarchive.ietf.org/arch/msg/xmpp/eEyZE6PIGXe_02zUOYXVfbqTkJQ>
Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2019 22:53:48 -0000

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 <barryleiba@computer.org>:
>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 <dave@cridland.net> wrote:
>
>>
>>
>> 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
>>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.