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

Barry Leiba <barryleiba@computer.org> Mon, 01 July 2019 22:16 UTC

Return-Path: <barryleiba@gmail.com>
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 65E5912014B for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 15:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 l3dKH-Otoxag for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 15:16:15 -0700 (PDT)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3D21200E7 for <xmpp@ietf.org>; Mon, 1 Jul 2019 15:16:14 -0700 (PDT)
Received: by mail-io1-f44.google.com with SMTP id m24so32509142ioo.2 for <xmpp@ietf.org>; Mon, 01 Jul 2019 15:16:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DOKAFEi2wVI/mcB1ICO4PRAFvyRqYprxcyJSUNevxko=; b=mlfxfiUicC0WUsnelK1aIDxTzlkHx/KRmiqq0dYnxgCczMJIMy9a6HI/rgXEJslKHO BwAWvDkI+Ggz9mDtP9qFDOgrYmfRAuL7ywzE2wpfL4DDwWyxF15Vm3baCS95x7ylbLaI olaN4GBfwQ/ZaQBWh5YelQiuFfSXSgz5Ar1eoC/5dudv1nHM6y9TJNxApB5cdDnmidhT Cr/MFJ/3LM+CG5Xe+GBab3dt8D5hL9Dp+SExas0Rfxw0LZX8lkETLesfAQhHybC2VJKO QHFdIEQNcCj5cAJI3IyAcTdRjLUZXzuXEZjwLWNE/T4e0QdPUzP2PtoQsIx6uFahWEkv psrQ==
X-Gm-Message-State: APjAAAVVBu5nVjyzWSRuh13ni8dpIArJyQniME+/0D0SIP2ctlacsMUF cN/KjdzZvYRQaY6glRlqIY9gm7i6X3ywBx3cEBE=
X-Google-Smtp-Source: APXvYqyxFxkHmIs3CPGp62p1H0haaoNYLP6D8oInD57EFzkXZDYJS8913+aKRQ20xlAs6eEUfCtHKggp1nog1xe5/jM=
X-Received: by 2002:a5d:88c6:: with SMTP id i6mr29813369iol.107.1562019372525; Mon, 01 Jul 2019 15:16:12 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAKHUCzwg6sPtN0Dp6zPfKT75+DbfE0xies3Wv7GujXes6jY0Ng@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 01 Jul 2019 18:16:00 -0400
Message-ID: <CALaySJKcozQ7sQJvQHMVq2m9mFT2=jXc5wVd=pqMWSZK_=Qr7A@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, Florian Schmaus <flo@geekplace.eu>, Joe Hildebrand <hildjj@cursive.net>, Peter Saint-Andre <stpeter@stpeter.im>, RFC Errata System <rfc-editor@rfc-editor.org>, XMPP Working Group <xmpp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4ee78058ca5f95d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xmpp/Y1yI7Do-fXxW9B-iVF7IW6zARNU>
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:16:19 -0000

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