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

Florian Schmaus <flo@geekplace.eu> Mon, 01 July 2019 16:41 UTC

Return-Path: <fschmaus@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 7A7B2120634 for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 09:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, 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 1Y9t7MJtuFdH for <xmpp@ietfa.amsl.com>; Mon, 1 Jul 2019 09:41:23 -0700 (PDT)
Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) (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 CFEA512062F for <xmpp@ietf.org>; Mon, 1 Jul 2019 09:41:22 -0700 (PDT)
Received: by mail-wm1-f66.google.com with SMTP id v19so187111wmj.5 for <xmpp@ietf.org>; Mon, 01 Jul 2019 09:41:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=1xXt8ck8n0viHyv5JZL7/QyrhUq8guODigZeftGewAI=; b=unLuBDJNdgLPhJNfczK7HJz1oU9uF8RHSMbo9yFPQst2wqWaUZhCgtLegYIU9V0IZN HEGUiP4b69NrG9otp2RQcuQbRSFnsWlGJoJzpf5c1T4J4Kl8BQH6dguHQU4FnjuU21tA f5BPRYIe2I2lqNv8CadRvfOWDiKS3b4xJd3JH9zYEQyYONIcifAKIMh4Ojq6l1uxIx/K vO6SqM7jvZyRTrCokH5SmQlEvzbUFvkV/A7VKKilP69P5pavafVmY319tZ8wp5m/Zhz/ cUPq76SdfKLG/+N49PVIzTof1VBBwtQeNWlw3z81ja2cWzffC9AWHkYXabjElFsbWQdL nW4A==
X-Gm-Message-State: APjAAAVhFOESp0kwzgHifZ+iG1uq4dHDdUgO473Tpe6fc+DTcrf0TZKS H5225HmJeMnN0v2+CPHWBXZy9tnQorPMOg==
X-Google-Smtp-Source: APXvYqz7KOW3T74s1Ahkd/aze9lOS/xfaSsCC473vv8+eiOTapHQ+bMXhqY7ANlLckfIjMP8C9My+Q==
X-Received: by 2002:a1c:ac81:: with SMTP id v123mr103127wme.145.1561999280634; Mon, 01 Jul 2019 09:41:20 -0700 (PDT)
Received: from [172.18.114.23] ([46.183.103.8]) by smtp.googlemail.com with ESMTPSA id x8sm28779096wre.73.2019.07.01.09.40.41 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 09:41:19 -0700 (PDT)
To: Barry Leiba <barryleiba@computer.org>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Peter Saint-Andre <stpeter@stpeter.im>, Joe Hildebrand <hildjj@cursive.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, Adam Roach <adam@nostrum.com>, xmpp@ietf.org
References: <20190630214921.40238B81D6A@rfc-editor.org> <CALaySJJ0t58BgMYE6G9XLFc-ydskvV6CS48d9++8xBfNZ_cLDg@mail.gmail.com> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com>
From: Florian Schmaus <flo@geekplace.eu>
Openpgp: preference=signencrypt
Autocrypt: addr=flo@geekplace.eu; prefer-encrypt=mutual; keydata= mQENBEw8UF4BCAC4H+pf0bJjP8iUvOXtyfM052WptOwK+YCVWx5y8TExQ6u2WuKnsLC5AhdQ qChyLU08zIkno2dvfhyRxxMqhUPmo60ckn6AjLrif28vZiHJRWCfJTipxL2mZO0xNW68d23k 9G4f7+hzNyjWV5SpFG2qg4DWKmwIonZHZMZAK3NtWK7h+3uIVXk32Veuseh/qACZRI63EuQH e+BhnHDFLbb7gYhm78tuzVobU1mEqiNSA783BpxoVUSCEine1/qB5kObmq9Nno0cwnPui8GS sAUmNItKC270UdwLimFdCnV8qEbVEVj+Nh+nE+LVMdNZJa95x/4HHz9oIj8TGc1/RNiXABEB AAG0IkZsb3JpYW4gU2NobWF1cyA8ZmxvQGdlZWtwbGFjZS5ldT6JAVcEEwEIAEECGwMFCwkI BwMFFQoJCAsFFgMCAQACHgECF4ACGQEWIQQTV7AYZbJQPBhFPSCMrCqWeFSONQUCWzoxDQUJ EsBHrwAKCRCMrCqWeFSONWwyB/9GdtTjAryks1OR5kbhSKiw132im4/Z0eDs681qHJlG/lyC uPORV+ru0fxxSNY4QxydG7+pJtJfaTtEn2562ziqr/peqtLdWw+F5RctJbiJD+TPEdAUdxA0 FlTdQoaGz3sC9NxVfYXDGTGGTvC2GUjI2PWgM6RCH1UA3/eWtDogypl4eXHJpjMwDclUxi/X rQjd65gCEAAt5YK+lF3cnvrVzc4AWHoVShVfPePyKAhJOdvFZn9f+3uRcNv5OsZUVZ8ZwAWv dqDp2MO1pjOTyO7aFc2sISjoXc5DQ+74F6e41/KyDImH6ims3mE5taD0RpgDfDxOMxaNvIGU MrzrmFbiuQENBEw8UF4BCADoJRRtsvwu0qPbYKZGxa+sJ44zDX8oLBr/UD8aESTPi7nXtc5V FRQ7v66JEKkKTYq9T/J29P5HsdxMomiR5pbaRUaAjeENscxzXY8BZTZVzSotqQ6ZHyOeGqkK XhNNVUx7pFZF1AO46bk8Ob++6jEFNCSIUNgiDsFggGwd3ngPLrpDblQQujC5pAT9JB6X+OnE 41cYSS5rCbDPaBKHtIyTftcCPwjsgic0qKMhXgthR86Qmna4ZUeHN9+8cEszk/LSEJysDv4Q +j9HiezRQxFXgKjsMyTdD8TAo3uVpZXc7vOrGagi7agK4QAMuozmbwVbOohYvR0w6mZmYEsE uh9fABEBAAGJATwEGAEIACYCGwwWIQQTV7AYZbJQPBhFPSCMrCqWeFSONQUCWzoxIwUJEsBH xQAKCRCMrCqWeFSONQdGB/9qe949moyhflZf/Gj8B4D7RQ+8z4taoo3LBbxl9Kp0gz2C0wgh kkeHDVt2Kf8yiRLkH9DdFnqowYb19qWHJ3+1dmUU2S8VWk24NYDE7svgw2lQOE8/pItXTG/C m9s7Rp8DHcTE1dqPwIGR7LhLtt/+U/NMZi8+cr/AiYlUCD88NcHEScqnO6srTzEWFye2BYRp m3ayR/DN2gJTIdWSqODT/yN07cFphYozg5aIgGzzy4nGGQnm5sLNmsvmu1oY2aAaK5LafqzA 60zEcnRKmX/MsGK7SiOHPIQrot33gjvhnhrtDcVfna26fTvdjkpZoczmpsQhjZdj0kU3VDyP yNkluQENBFdWjtMBCAC9XPyeOKXvBPiwMMqAZIXiqTpy7uKmElD1RpXYl/0ZC+oEvXhlYZE5 sAm3uRN3hulH86wNAP1lvV5nSRa/r4pPr1I8zqzfl1EN0CmVdeIR77UZOhfgLtEKRmUUf3YK 2ZIjVJ9zhYfBZpuuRd6ckoUzZsp2MgdID2ezxcpuBNL8EVkr15p5sEkEU+pqY/QUuXY1MCtf Cs0q4RWUO9UOiAX2tCbMVvDAxtItBEVIwJ5p94glK3tfaBfHE6787KbN5a5AV3vgKVGjlKHA FPr8yY+F5lj9fKjxCjgkga3nwz0vF+FX/8BbErBHU/gUgnFzbwZxq/+XtQxK297k5hc6kEVH ABEBAAGJArsEGAEIACYCGwIWIQQTV7AYZbJQPBhFPSCMrCqWeFSONQUCWzoxOAUJB6YJZQGJ wL0gBBkBCABmBQJXVo7TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXQ5Nzc1MDU5RjNBMjFEQ0UxNkJFNEZCQUUyMjM5QTdFOEY1ODUy MDUyAAoJECI5p+j1hSBS7FsIAJVU3gkZdex8Tj+vwHeLdtupi5iGtcnkijnFyhC7Fbkzn83y Jj2QsYVpPGVC1X2zDFoqoV15GTqBnYoL3QayMZM4zglTP81nBSNbrOai2RYFnTMNv2ivgWPN j38y07+T0Z+boJ+0xrsTT5QYkk75cv8X694YhyaHTcljDwK56dhY+9i/h9cfPZON/cwWoymA PUxNsVqovUfFF+eX9gmZHjzqjEdsdcS5eXb1kr8sdXIhwYRfPeZutTzuKHEYzw1bIidxZeX8 +Q+qbZxC/IOTpE/JC++IAdABExtuZaaABirXXqXNTZPPROcF8Rfo9IoBuJ5s/2zR2j664fB/ p5JQyRwJEIysKpZ4VI41iYkIALMQ/+GvcUhdr0H8iYb1HeijZ2eTQRAv3j7cEAK+8dbBslYr b8eG7pO6swnuhXzEwuxSqoq1UA50sa7L++cN0oJk7S0FDkhVb7vDU1BNQ1DXTeiNbQpvLqXB Y7/drAwHGMo6PS4IkEhzBZfs7FP/Tewpr8LC9i4FdlzDcCxj5rHUVS/+aerd8KZtRKmXmes7 gBxZ+Klwj8eizPmLp4lRxwVjOLQxOSEielhWiuzSzlZGvz5RmBqumVc0sUSB/GTBKYpcIhP/ mBKGNutYkMzCK/JJ5LID/MCpsRsjH8Syd5aRg4shE0aeh1KV9WF/YiQPC/V03LO5Fx2JULpg wmAlqFE=
Message-ID: <21ad3ebb-a1c7-61f8-ac96-65a9c3b721b8@geekplace.eu>
Date: Mon, 01 Jul 2019 18:40:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CALaySJKztZ40OLNL6Jsvt1wzFgjYzqxUNq3Xj60KwOkAvJGxZA@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/xmpp/1xbiPkV60uLMG4Fw6Rh4wzQxBTg>
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 16:41:25 -0000

On 01.07.19 15:18, Barry Leiba wrote:
>>> 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?

I do believe that this is the wrong question. We want to allow every
code point that is allowed in U-labels to be in XMPP domainparts. And
since I believe that every valid code point in an A-label is also a
valid code point of a U-label (could be wrong here), this means that
people could use 'xn--vhqr8o.xn--fiqs8s' as domainpart in their JID.
Thought it is probably not sensible to do so.

If RFC 7622 where to allow U-labels but explicitly disallow A-labels,
then we once again would need to perform a more costly operation on the
String because it would require to check the semantic.


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

I see. Personally I would simply remove that requirement, since a PRECIS
preparation function can not tell if it is an A-label or just an
hostname which mimics an A-label.

FWIW I'd also remove the "In addition, the string MUST be encoded as
UTF-8 [RFC3629]." requirement, since it bears no benefit. But I am
drifting away from the topic.

>>> 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 am sorry, I believe there is a specific reason for that: It is
probably to normalize DNS names:

- example.org
- example.org.

are both the same DNS name.

> I think Peter is the best
> person to answer that, as he wrote the text and might remember why it
> was said that way.

Yep. I am also looking forward to some further comments on this from others.

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

One more refinement of my proposed replacement text (sorry!). I am not
sure why the RFC currently explicitly mentions NR-LDH labels. AFAIKT all
code points in NR-LDH labels are also valid code points in U-labels. I
suppose it could be because U-labels are required to contain at least
one non-ASCII character. But then explicitly mentioning NR-LDH labels
appears to cause unnecessary complexity. It is probably enough and
easier to comprehend if the text simply states:

  An entity that prepares a string for inclusion in an XMPP
  domainpart slot MUST ensure that the string consists only of
  - code points allowed in U-labels as defined in [RFC5891]
  - . U+002E (FULL STOP, DNS label separator "dot")
  - : U+003A (COLON)
  - ] U+005B (LEFT SQUARE BRACKET)
  - [ U+005D (RIGHT SQUARE BRACKET)

- Florian