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.
- [xmpp] [Technical Errata Reported] RFC7622 (5769) RFC Errata System
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Barry Leiba
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Schmaus
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Barry Leiba
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Schmaus
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Dave Cridland
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Barry Leiba
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Matthias Wimmer
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Peter Saint-Andre
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Schmaus
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Peter Saint-Andre
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Zeitz
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Schmaus
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Zeitz
- Re: [xmpp] [Technical Errata Reported] RFC7622 (5… Florian Schmaus