From nobody Mon Jul 1 06:18:32 2019 Return-Path: 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 E4CDF1200A1 for ; Mon, 1 Jul 2019 06:18:30 -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 6ptZihvagPZg for ; Mon, 1 Jul 2019 06:18:29 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 736B912023F for ; Mon, 1 Jul 2019 06:18:29 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id k20so2370772ios.10 for ; Mon, 01 Jul 2019 06:18:29 -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:content-transfer-encoding; bh=40dHUy2JzYmngUICh/iWuP/7RjOeXzvylzfvwgX6rfs=; b=cuDByK3LPklgo6usZ6qSYiq6QD77nZu/x+bxWILPg1kvQd+T/QnalfsVy2Diyo+kkn csJqVQOohmdGboz+hfZVd3gyOEAmHg6fwCrotSw9H+yCI0aTTe5+6TymaB5FMgDxwuFY MBeoE3JOn6G9xGmzJrUwh9x9dERbhfyWLD20wJBMtK2tr3ssxTz9ebJRbAuey6RVQstY kRAyXuH4oYnPBy6+/1fAD0tkZsoT8ozCmolJiSRKa+ksdHZViKjRfywY5bFXXCjVF7u3 WdbegRSFRf5rShObKVQ1U5XLOKxmuFNeu5EO1PNiI3o88YAJxJ7upGQpHlrLAYtJl0bC 7NPw== X-Gm-Message-State: APjAAAW0IQf5d9tS8IY00Hj1Igib1S/s4/zS4ic/ZxHbpyhV4nEda5kh 6WDQ0IvSSkdhKnV0KHv7DwXAOyGWo8U1hrw7L0/oFThB X-Google-Smtp-Source: APXvYqzeLhswPFD5ejfDS8ctWj9sg7TSTBUGPCvauxmn6TUA9UdS1HvxS3CoFNFAk8sVDMoKsvAWfJ/LNAF2L3Sw4vs= X-Received: by 2002:a02:b710:: with SMTP id g16mr28491823jam.88.1561987107721; Mon, 01 Jul 2019 06:18:27 -0700 (PDT) MIME-Version: 1.0 References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> From: Barry Leiba Date: Mon, 1 Jul 2019 09:18:16 -0400 Message-ID: To: Florian Schmaus Cc: RFC Errata System , Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , xmpp@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 13:18:31 -0000 > > 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. > > 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, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK. Is this text meant t= o 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 labe= l > > 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, FU= LL 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 From nobody Mon Jul 1 09:41:26 2019 Return-Path: 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 ; 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 ; 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 ; Mon, 1 Jul 2019 09:41:22 -0700 (PDT) Received: by mail-wm1-f66.google.com with SMTP id v19so187111wmj.5 for ; 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 Cc: RFC Errata System , Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> From: Florian Schmaus 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, 1 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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 16:41:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4 Content-Type: multipart/mixed; boundary="BAf3wkN6BTq1fkgLYoXIVoIgzHKFD1d6d"; protected-headers="v1" From: Florian Schmaus To: Barry Leiba Cc: RFC Errata System , Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , xmpp@ietf.org Message-ID: <21ad3ebb-a1c7-61f8-ac96-65a9c3b721b8@geekplace.eu> Subject: Re: [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: --BAf3wkN6BTq1fkgLYoXIVoIgzHKFD1d6d Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable 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-label= s. >=20 > 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 woul= d >> 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. >=20 > But that's already necessary because of what the text says about A-labe= ls. 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 la= bel >>> 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. >=20 > 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 othe= rs. >>> 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 thi= s >> may not be enough. Since domainparts can also act as holder for IPv6 >> addresses, we also need to allow ':', '[' and ']', as they are also no= t >> 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) >=20 > 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 --BAf3wkN6BTq1fkgLYoXIVoIgzHKFD1d6d-- --lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0aN3ZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFI/ogf/fFRu6Zda+V6qB/71mEvTQYl0V/pnrjpR9p8T59+1kpYaDl7SbN7ou2nK ZzMFQs94ay7qylXnJ77FxfNew8vMSM+vPlLOTEEPJpFnyqSwe69E7y1VnoiM2rt8 xONDwUwOf33kMWzIEzqXPEqKWsWoPqLYnkNJNTeE9vbXlS1zp1Ffpeomxjlzamh9 DLv+FZoL6kshW1U1fk4vUSwDlxGiE2ArJru24yr2Qyx+yEd34rvVh55hASIFa2ew K8J/tEdQc3GZIN1j+4rqJIAiAvme8pJ5lmNQmALWfYkH3GdVZTJgd36sslLQpeUt j/rzUorYiW0ED7bD1v7UHnwYq5po0w== =hp0r -----END PGP SIGNATURE----- --lXHNt2LmOr9CMvfwEsF2lozJpNeG9ZHQ4-- From nobody Mon Jul 1 15:11:06 2019 Return-Path: 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 4585E120180 for ; Mon, 1 Jul 2019 15:11:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=cridland.net 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 wwlvfyrtvOKA for ; Mon, 1 Jul 2019 15:11:01 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 B230D1200E7 for ; Mon, 1 Jul 2019 15:11:00 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id p15so25307136eds.8 for ; Mon, 01 Jul 2019 15:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XKD8BJqOxi5w63/dGqcShsSp//YYSrrk8ub+mPpgmnc=; b=M6RW1ePysJfGT8AyLztP+CX/jXBhjqwfvp+Y03pP2CE/6PwHhS9wOYoDCra7zUPvzG va+/hZTehPVVWMhrWiA9I/1WL0z7yFy9rUASEFxfWhPKZD5nNi5Mx2pW4udzmiFgBg/p ByMA1bNQkPDRNBWBke0o9Z45DZ6gGu4k1FspI= 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=XKD8BJqOxi5w63/dGqcShsSp//YYSrrk8ub+mPpgmnc=; b=LWfVut/P3zDBoFqloJ+PtoLxQ/Epor/Yp75bG8n2zcRlqhqYKkDjmBXptBOsS6i/+q wjStQBnQ4gXgPcXxq2JPA72G84Mwnn6Q810eMkU0E6UCLwpl+NMxZqQVHjAwXvaW2brg pCDy7ahSE5utSfpAG/0xMN1wWt4IVUIUy9SpKkfwMpwkAzMp3230QAy7frk0z7QS2Zdy Rkl9Hd3O+60rzLwtYpYtxfmnB8HITdtmou4ehxmxRFPQOqS7NYCFcSsXgItey9CAgHNC 2jmURzln96x7PV5K/ixyZpFLosfx/mGx2CuQB+j1XcsEUL/n4JrqQ1Qz+9eBcJIWoxx+ rEWQ== X-Gm-Message-State: APjAAAV/p7ZYD6tmi3VkRsd/kIba21OM1NVehOqLMIBlkofNeCaAfwYt P5K8lOad+5Wt2xl3gXbutLv43bZ9rXj0MFSzusXXVw== X-Google-Smtp-Source: APXvYqxB0ug30t2g/Z/2aAgqOUETZJWSf2Xv9nIFDlphYjQP2n6aqYixKOl/6uC/qEGacBVuNihSesVC2wLgRlqgB3o= X-Received: by 2002:a17:906:944f:: with SMTP id z15mr25549899ejx.137.1562019058959; Mon, 01 Jul 2019 15:10:58 -0700 (PDT) MIME-Version: 1.0 References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: From: Dave Cridland Date: Mon, 1 Jul 2019 23:10:48 +0100 Message-ID: To: Barry Leiba Cc: Florian Schmaus , Joe Hildebrand , Alexey Melnikov , XMPP Working Group , Peter Saint-Andre , RFC Errata System Content-Type: multipart/alternative; boundary="000000000000245cf6058ca5e70e" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 22:11:04 -0000 --000000000000245cf6058ca5e70e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 1 Jul 2019 at 14:18, Barry Leiba 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 =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD 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, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD 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 o= f > > the semantic of the string, instead of simply checking and performing o= n > > 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 > --000000000000245cf6058ca5e70e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 1 Jul 2019 at 14:18, Barry Le= iba <barryleiba@computer.org<= /a>> wrote:
&= gt; > 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 identifie= rs)
>=C2=A0 =C2=A0Those are potentially longer strings then DNS labels are a= llowed to
>=C2=A0 =C2=A0be.

OK, so there's more to it than that.




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=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as=C2= =A0xn--vhqr8o.xn--fiqs8s? They always look up the same in DNS, after all, b= y definition. I can't see why we'd think allowing them wasn't g= oing to cause problems. So, again, a SHOULD NOT if not a MUST NOT.
=C2=A0
> > 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-label= s.

Of course; the point is the other way around: because A-label
characters are valid, A-labels could be put there.=C2=A0 Do we want that? Clearly, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK.=C2=A0 Is this text me= ant to allow
xn--vhqr8o.xn--fiqs8s ?=C2=A0 The text certainly says no, explicitly, but "this means that" doesn't follow from the list of characters = that are
allowed.=C2=A0 The text seems odd in that regard.

> I think R-LDH labels should not be explicitly disallowed, as this woul= d
> 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-labe= ls.

> > 2. Earlier, in Section 3.8, is this text that seems rather odd to= me:
> >
> >=C2=A0 =C2=A0 If the domainpart includes a final character conside= red to be a label
> >=C2=A0 =C2=A0 separator (dot) by [RFC1034]
> >
> > When I look at RFC 1034, I see that there's no mention of lab= el
> > separator at all, and no set of characters that are considered to= be
> > so.=C2=A0 It simply says:
> >
> >=C2=A0 =C2=A0 When a user needs to type a domain name, the length = of each label is
> >=C2=A0 =C2=A0 omitted and the labels are separated by dots ("= .").
> >
> > Is there a reason for that specific text in Section 3.2, or are w= e
> > 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.=C2=A0 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:
> >
> >=C2=A0 =C2=A0 An entity that prepares a string for inclusion in an= XMPP
> > domainpart slot MUST
> >=C2=A0 =C2=A0 ensure that the string consists only of NR-LDH label= s and U-labels,
> > as defined
> >=C2=A0 =C2=A0 in [RFC5890], separated by the DNS label separator &= quot;dot" (U+002E, FULL STOP).
>
> I just occurred to me, after submitting the errata of course, that thi= s
> may not be enough. Since domainparts can also act as holder for IPv6 > addresses, we also need to allow ':', '[' and ']&#= 39;, as they are also not
> valid characters in NR-LDH labels and U-labels.
>
> Hence my refined replacement text would be:
>
>=C2=A0 =C2=A0An entity that prepares a string for inclusion in an XMPP = domainpart
>=C2=A0 =C2=A0slot MUST ensure that the string consists only of
>=C2=A0 =C2=A0- codepoints allowed in NR-LDH labels and U-labels, as def= ined in
>=C2=A0 =C2=A0 =C2=A0[RFC5890]
>=C2=A0 =C2=A0- . U+002E (FULL STOP, DNS label separator "dot"= )
>=C2=A0 =C2=A0- : U+003A (COLON)
>=C2=A0 =C2=A0- ] U+005B (LEFT SQUARE BRACKET)
>=C2=A0 =C2=A0- [ 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 in= tent
and correct fix.=C2=A0 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
--000000000000245cf6058ca5e70e-- From nobody Mon Jul 1 15:16:20 2019 Return-Path: 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 ; 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 ; 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 ; Mon, 1 Jul 2019 15:16:14 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id m24so32509142ioo.2 for ; 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> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: From: Barry Leiba Date: Mon, 1 Jul 2019 18:16:00 -0400 Message-ID: To: Dave Cridland Cc: Alexey Melnikov , Florian Schmaus , Joe Hildebrand , Peter Saint-Andre , RFC Errata System , XMPP Working Group Content-Type: multipart/alternative; boundary="000000000000d4ee78058ca5f95d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 22:16:19 -0000 --000000000000d4ee78058ca5f95d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable More evidence that correcting this properly goes to =E2=80=9CHeld for Docum= ent Update=E2=80=9D. There needs to be proper discussion and arrival at consen= sus, beyond the scope of an errata report. Barry On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland wrote: > > > On Mon, 1 Jul 2019 at 14:18, Barry Leiba 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 woul= d > 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 =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as xn--vhqr8o.xn--fiqs8= s? 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-label= s. >> >> 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, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK. Is this text mean= t 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 woul= d >> > 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-label= s. >> >> > > 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-label= s, >> > > 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 thi= s >> > may not be enough. Since domainparts can also act as holder for IPv6 >> > addresses, we also need to allow ':', '[' and ']', as they are also no= t >> > 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 >> > --000000000000d4ee78058ca5f95d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
More evidence that correcting this properly goes to = =E2=80=9CHeld for Document Update=E2=80=9D.=C2=A0 There needs to be proper = discussion and arrival at consensus, beyond the scope of an errata report.<= /div>

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 L= eiba <barry= leiba@computer.org> wrote:
> > 1. Is this bit of text intended to say that &qu= ot;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 identifie= rs)
>=C2=A0 =C2=A0Those are potentially longer strings then DNS labels are a= llowed to
>=C2=A0 =C2=A0be.

OK, so there's more to it than that.


Hold your horses - I'm not sure th= at's actually true.

In particular:
<= br>
a) I don't think that IPv4/IPv6 addresses actually belong= there. Some existing client libraries and servers can handle that, but it&= #39;s not clear it works outside a single server (ie, with S2S links). At b= est, this would be a SHOULD NOT in my opinion. For a start, most of the res= t of the langauge makes no sense, since it assumes these things can be the = subject of a DNS request - see, for example,=C2=A0https://tools.ietf.org= /html/rfc6120#section-3.2

b) Arbitrary labels = are syntactically the same as U-Labels. If anyone wants them to be differen= t, 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 j= ust going to cause confusion - is=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B= =BD the same as=C2=A0xn--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.
=C2=A0
> > 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-label= s.

Of course; the point is the other way around: because A-label
characters are valid, A-labels could be put there.=C2=A0 Do we want that? Clearly, =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD is OK.=C2=A0 Is this text me= ant to allow
xn--vhqr8o.xn--fiqs8s ?=C2=A0 The text certainly says no, explicitly, but "this means that" doesn't follow from the list of characters = that are
allowed.=C2=A0 The text seems odd in that regard.

> I think R-LDH labels should not be explicitly disallowed, as this woul= d
> 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-labe= ls.

> > 2. Earlier, in Section 3.8, is this text that seems rather odd to= me:
> >
> >=C2=A0 =C2=A0 If the domainpart includes a final character conside= red to be a label
> >=C2=A0 =C2=A0 separator (dot) by [RFC1034]
> >
> > When I look at RFC 1034, I see that there's no mention of lab= el
> > separator at all, and no set of characters that are considered to= be
> > so.=C2=A0 It simply says:
> >
> >=C2=A0 =C2=A0 When a user needs to type a domain name, the length = of each label is
> >=C2=A0 =C2=A0 omitted and the labels are separated by dots ("= .").
> >
> > Is there a reason for that specific text in Section 3.2, or are w= e
> > 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.=C2=A0 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:
> >
> >=C2=A0 =C2=A0 An entity that prepares a string for inclusion in an= XMPP
> > domainpart slot MUST
> >=C2=A0 =C2=A0 ensure that the string consists only of NR-LDH label= s and U-labels,
> > as defined
> >=C2=A0 =C2=A0 in [RFC5890], separated by the DNS label separator &= quot;dot" (U+002E, FULL STOP).
>
> I just occurred to me, after submitting the errata of course, that thi= s
> may not be enough. Since domainparts can also act as holder for IPv6 > addresses, we also need to allow ':', '[' and ']&#= 39;, as they are also not
> valid characters in NR-LDH labels and U-labels.
>
> Hence my refined replacement text would be:
>
>=C2=A0 =C2=A0An entity that prepares a string for inclusion in an XMPP = domainpart
>=C2=A0 =C2=A0slot MUST ensure that the string consists only of
>=C2=A0 =C2=A0- codepoints allowed in NR-LDH labels and U-labels, as def= ined in
>=C2=A0 =C2=A0 =C2=A0[RFC5890]
>=C2=A0 =C2=A0- . U+002E (FULL STOP, DNS label separator "dot"= )
>=C2=A0 =C2=A0- : U+003A (COLON)
>=C2=A0 =C2=A0- ] U+005B (LEFT SQUARE BRACKET)
>=C2=A0 =C2=A0- [ 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 in= tent
and correct fix.=C2=A0 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
--000000000000d4ee78058ca5f95d-- From nobody Mon Jul 1 15:53:50 2019 Return-Path: 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 ; 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 ; 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 ; 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: References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ" Content-Transfer-Encoding: 7bit To: xmpp@ietf.org, Barry Leiba , Dave Cridland CC: Joe Hildebrand , Alexey Melnikov , XMPP Working Group , Peter Saint-Andre , RFC Errata System From: Matthias Wimmer Message-ID: Authentication-Results: ORIGINATING; auth=pass smtp.auth=m@tthias.eu smtp.mailfrom=m@tthias.eu Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 22:53:48 -0000 ------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd also like to point to http://unicode=2Eorg/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=2E This definition has also been in RFC3490 section 4 (IDNA2003) but I cannot= find it explicitly in IDNA2008=2E Not even in the list of things that have= changed=2E For the given example of =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD I think a= Chinese user would more likely enter =E5=95=86=E4=B8=9A=E3=80=82=E4=B8=AD= =E5=9B=BD because while entering Chinese characters there is no key on the = keyboard, that would enter a Western full stop=2E So to enter =E5=95=86=E4= =B8=9A=2E=E4=B8=AD=E5=9B=BD he would have to change his keyboard layout at = least twice=2E Regards, Matthias Am 2=2E Juli 2019 00:16:00 MESZ schrieb Barry Leiba : >More evidence that correcting this properly goes to =E2=80=9CHeld for Doc= ument >Update=E2=80=9D=2E There needs to be proper discussion and arrival at co= nsensus, >beyond the scope of an errata report=2E > >Barry > >On Mon, Jul 1, 2019 at 6:11 PM Dave Cridland wrote: > >> >> >> On Mon, 1 Jul 2019 at 14:18, Barry Leiba >wrote: >> >>> > > 1=2E 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=2E >>> >>> OK, so there's more to it than that=2E >>> >>> >> Hold your horses - I'm not sure that's actually true=2E >> >> In particular: >> >> a) I don't think that IPv4/IPv6 addresses actually belong there=2E Some >> existing client libraries and servers can handle that, but it's not >clear >> it works outside a single server (ie, with S2S links)=2E At best, this >would >> be a SHOULD NOT in my opinion=2E 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=2Eietf=2Eorg/html/rfc6120#section-3=2E2 >> >> b) Arbitrary labels are syntactically the same as U-Labels=2E If anyone >> wants them to be different, I'm willing to mud-wrestle them for it, >and >> nobody should want that=2E >> >> c) I don't think we want A-Labels=2E It's just going to cause confusion >- >> is =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD the same as xn--vhqr8o=2Exn-= -fiqs8s? They always look up the >same in >> DNS, after all, by definition=2E I can't see why we'd think allowing >them >> wasn't going to cause problems=2E So, again, a SHOULD NOT if not a MUST >NOT=2E=2E >> >> >>> > > 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=2E >>> >>> Of course; the point is the other way around: because A-label >>> characters are valid, A-labels could be put there=2E Do we want that? >>> Clearly, =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD is OK=2E Is this tex= t meant to allow >>> xn--vhqr8o=2Exn--fiqs8s ? The text certainly says no, explicitly, but >>> "this means that" doesn't follow from the list of characters that >are >>> allowed=2E The text seems odd in that regard=2E >>> >>> > 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=2E But there is probably no use case for R-LDH >>> > labels in domainparts=2E >>> >>> But that's already necessary because of what the text says about >A-labels=2E >>> >>> > > 2=2E Earlier, in Section 3=2E8, 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=2E 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 ("=2E")=2E >>> > > >>> > > Is there a reason for that specific text in Section 3=2E2, or are >we >>> > > just looking for the 'DNS label separator "dot" (U+002E, FULL >STOP)' >>> > > as suggested in the errata report? >>> > >>> > I think so=2E >>> >>> That's an "Is it A or B" question, so "I think so" doesn't answer >it=2E >>> So I'll change the question and just ask if there's a reason to use >>> that text in Section 3=2E2 that cites 1034=2E I think Peter is the be= st >>> person to answer that, as he wrote the text and might remember why >it >>> was said that way=2E >>> >>> > 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=2E >>> > >>> > > 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)=2E >>> > >>> > I just occurred to me, after submitting the errata of course, that >this >>> > may not be enough=2E 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=2E >>> > >>> > 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] >>> > - =2E 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=2E But I'd very much like to hear from Peter and/or >Joe >>> before we settle this=2E >>> >>> And, Florian, thanks for making the errata report and for the quick >>> response to discussion=2E >>> >>> Barry >>> >>> _______________________________________________ >>> xmpp mailing list >>> xmpp@ietf=2Eorg >>> https://www=2Eietf=2Eorg/mailman/listinfo/xmpp >>> >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd also like to point to http://unicode=2Eorg/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=2E

This = definition has also been in RFC3490 section 4 (IDNA2003) but I cannot find = it explicitly in IDNA2008=2E Not even in the list of things that have chang= ed=2E

For the given example of =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B= =BD I think a Chinese user would more likely enter =E5=95=86=E4=B8=9A=E3=80= =82=E4=B8=AD=E5=9B=BD because while entering Chinese characters there is no= key on the keyboard, that would enter a Western full stop=2E So to enter = =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD he would have to change his keyboar= d layout at least twice=2E


Regards,
Matthias

Am 2=2E Juli 2019 00:16:00 MESZ schrieb Barry Leiba <b= arryleiba@computer=2Eorg>:
More evidence that correcting this properly goes to= =E2=80=9CHeld for Document Update=E2=80=9D=2E  There needs to be prop= er discussion and arrival at consensus, beyond the scope of an errata repor= t=2E

Barry

On = Mon, Jul 1, 2019 at 6:11 PM Dave Cridland <dave@cridland=2Enet> wrote:


On Mon, 1 Jul 2019 at 14:= 18, Barry Leiba <barryleiba@computer=2Eorg> wrote:
> > 1=2E Is this bit of text inten= ded to say that "domainpart" has to
> > *consist of* NR-LDH labels and U-labels, rather than to contain<= br> > > 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=2E

OK, so there's more to it than that=2E


Hold your horses - I'm not sure that'= s actually true=2E

In particular:

a) I don't think that IPv4/IPv6 addresses actually belong there=2E= Some existing client libraries and servers can handle that, but it's not c= lear it works outside a single server (ie, with S2S links)=2E At best, this= would be a SHOULD NOT in my opinion=2E For a start, most of the rest of th= e langauge makes no sense, since it assumes these things can be the subject= of a DNS request - see, for example, https://tools=2Eietf= =2Eorg/html/rfc6120#section-3=2E2

b) Arbitrary= labels are syntactically the same as U-Labels=2E If anyone wants them to b= e different, I'm willing to mud-wrestle them for it, and nobody should want= that=2E

c) I don't think we want A-Labels=2E It's= just going to cause confusion - is =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5= =9B=BD the same as xn--vhqr8o=2Exn--fiqs8s? They always look up the sa= me in DNS, after all, by definition=2E I can't see why we'd think allowing = them wasn't going to cause problems=2E So, again, a SHOULD NOT if not a MUS= T NOT=2E
 
> > 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-labe= ls=2E

Of course; the point is the other way around: because A-label
characters are valid, A-labels could be put there=2E  Do we want that= ?
Clearly, =E5=95=86=E4=B8=9A=2E=E4=B8=AD=E5=9B=BD is OK=2E  Is this te= xt meant to allow
xn--vhqr8o=2Exn--fiqs8s ?  The text certainly says no, explicitly, bu= t
"this means that" doesn't follow from the list of characters that are
allowed=2E  The text seems odd in that regard=2E

> I think R-LDH labels should not be explicitly disallowed, as this wou= ld
> 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=2E But there is probably no use case for R-LDH<= br> > labels in domainparts=2E

But that's already necessary because of what the text says about A-labels= =2E

> > 2=2E Earlier, in Section 3=2E8, is this text that seems rather o= dd to me:
> >
> >    If the domainpart includes a final character consid= ered to be a label
> >    separator (dot) by [RFC1034]
> >
> > When I look at RFC 1034, I see that there's no mention of label<= br> > > separator at all, and no set of characters that are considered t= o be
> > so=2E  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 ("=2E= =2E")=2E
> >
> > Is there a reason for that specific text in Section 3=2E2, or ar= e we
> > just looking for the 'DNS label separator "dot" (U+002E, FULL ST= OP)'
> > as suggested in the errata report?
>
> I think so=2E

That's an "Is it A or B" question, so "I think so" doesn't answer it=2E So I'll change the question and just ask if there's a reason to use
that text in Section 3=2E2 that cites 1034=2E  I think Peter is the b= est
person to answer that, as he wrote the text and might remember why it
was said that way=2E

> 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=2E
>
> > My sense is that the intended replacement *might* be this, thoug= h I'm
> > not sure and need discussion/confirmation:
> >
> >    An entity that prepares a string for inclusion in a= n XMPP
> > domainpart slot MUST
> >    ensure that the string consists only of NR-LDH labe= ls and U-labels,
> > as defined
> >    in [RFC5890], separated by the DNS label separator = "dot" (U+002E, FULL STOP)=2E
>
> I just occurred to me, after submitting the errata of course, that th= is
> may not be enough=2E Since domainparts can also act as holder for IPv= 6
> addresses, we also need to allow ':', '[' and ']', as they are also n= ot
> valid characters in NR-LDH labels and U-labels=2E
>
> 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 de= fined in
>     [RFC5890]
>   - =2E 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=2E  But I'd very much like to hear from Peter and/or = Joe
before we settle this=2E

And, Florian, thanks for making the errata report and for the quick
response to discussion=2E

Barry

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=2E8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"> _______________________________________________
xmpp mailing list
xmpp@ietf=2Eorg https://www=2Eietf=2Eorg/mailman/listinfo/xmpp

--
Sent from my Android device with K-9 Mail=2E= Please excuse my brevity=2E ------TJ5F2TDZS2JR43BM8D0C7A39AMQPAZ-- From nobody Mon Jul 1 16:08:25 2019 Return-Path: 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 E8531120186 for ; Mon, 1 Jul 2019 16:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=mozilla.com 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 Q_B4gwhJw1mg for ; Mon, 1 Jul 2019 16:08:19 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 98A1D1200CE for ; Mon, 1 Jul 2019 16:08:19 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id k20so6334256ios.10 for ; Mon, 01 Jul 2019 16:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LqqdGwo6ak+aSwwAyHQDyishVfSEB6MDj8VMzYfnsHk=; b=Evp/pxuwE3DxOi03TVP8CJ1bfq3Uj3073SMXUIIOErqP9NzzpXyFglWB8Qwis1Mzm7 jC188a7Zioju2Htzz7wfPVO7raKr3oLxvYEiL0I4Vx7gIduVq1wJXSXvsY0vPnaCxwXQ 3aFfF+1nOwnOpHG3LOYB1PF6V7DK9tUdBA6OU= 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 :content-language:content-transfer-encoding; bh=LqqdGwo6ak+aSwwAyHQDyishVfSEB6MDj8VMzYfnsHk=; b=d/cl+3Jwab3tuFzX+zW5wS/NQCtK/geGVN40RltWEPtbOa3hkVHCpBk+qXS6mTtG5k DxAFSz3rlI9l/mZbGqcvjMquStlmBhO4TweVlHWf0XaMk7iWXfIX8kGncFxC64bWF+/Z 030TBdWJiwVjgrpxX0VMSRWblFFUQaarRXLWQkobuitWq4+sCzEtSarQZt6DUwbH30pL yat+Aem79wUqZPW4rRXsWeB6OrCi7IPudnjOwlKCDjL64yCt2BRA76Mg55UQMK7diCyl XCT7CZ6AV3bm7OuAQnLf54s5fGHqGmm/0i6n/aopwTQT8fl7zyLTDvq/WciS/P9jPDB0 Pa9w== X-Gm-Message-State: APjAAAWZRNYN5yEur/E7QPMENpbN61AsyZoQJojszjOpvd/quLFEhOpd aHESdH8TvQnjH+fZutvpclBXDA== X-Google-Smtp-Source: APXvYqxX2k4rYFL8ivxi/Q+hINluuNhrp7Xliswy7DHXXwOM+X3OMrHi+zfM6Nyv4AH7gx2GEmlpwA== X-Received: by 2002:a6b:901:: with SMTP id t1mr23421989ioi.42.1562022498491; Mon, 01 Jul 2019 16:08:18 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id f4sm28923711iok.56.2019.07.01.16.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 16:08:17 -0700 (PDT) To: Matthias Wimmer , xmpp@ietf.org, Barry Leiba , Dave Cridland Cc: Joe Hildebrand , RFC Errata System , Peter Saint-Andre , Alexey Melnikov References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <18318620-a17c-2760-2586-c0e2ee9cd780@mozilla.com> Date: Mon, 1 Jul 2019 17:08:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 23:08:23 -0000 >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 : > > 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 > wrote: > > > > On Mon, 1 Jul 2019 at 14:18, Barry Leiba > > 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 mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > From nobody Tue Jul 2 00:25:58 2019 Return-Path: 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 9E1AC1201D7 for ; Tue, 2 Jul 2019 00:25:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zXp3ShflQIQJ for ; Tue, 2 Jul 2019 00:25:53 -0700 (PDT) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 F1A4B120183 for ; Tue, 2 Jul 2019 00:25:52 -0700 (PDT) Received: by mail-wm1-f49.google.com with SMTP id g135so1807529wme.4 for ; Tue, 02 Jul 2019 00:25:52 -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=8ND/DZfsodE5nyiWjUcPrgZJU71Mzhnn99fJ6Z99rjE=; b=TntFU96AGb9mhNLeE5XaP0MxsF9tKyOWrnQR6dPN4REcz9qvFOnuWP7PMYeKifIfaM 2AvqLNQr3leAEa4vL+i6OmptCkR097TJWSKT/sC+s7FlGm0a//2yPPD2jiJ54gctg0Te ULH3ine/tM5b5m4B0Q02QdbGE/Axws6hf0zR4CbU6P7jAru9kfU0CZzfTn13dn5mQZv2 PYKC5w5P9YYJPPrTS5QyhtOuQoYcYqC5S2TkkRVauT8PgVXyPK0Gol5Z+h6xYTodRmQH R1eGQxn9KzoMRxsdNj2YFc9V0jW0WZtRxeqLFgc9mM7X7oHJZXYi0J0kTc24YKof14ak NaCQ== X-Gm-Message-State: APjAAAXuB/6jPyGWZWwuZfgfEJL3IWGXFdrt5Q9Lt1B+pmccSLbp4tpR VNZRFCRZ/al1842sIE/gqjk= X-Google-Smtp-Source: APXvYqybpUO1vZxkJBAQKY86FSTaN6Sn55gWCGalTwPFgcic9C4sFskXltRWPV4EHbG0ypZb+GZvHA== X-Received: by 2002:a1c:f009:: with SMTP id a9mr2161993wmb.32.1562052350938; Tue, 02 Jul 2019 00:25:50 -0700 (PDT) Received: from [10.188.34.160] (nat-inf.rrze.uni-erlangen.de. [131.188.6.45]) by smtp.googlemail.com with ESMTPSA id w20sm27639832wra.96.2019.07.02.00.25.49 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jul 2019 00:25:49 -0700 (PDT) To: Dave Cridland , Barry Leiba Cc: Joe Hildebrand , Alexey Melnikov , XMPP Working Group , Peter Saint-Andre , RFC Errata System References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> From: Florian Schmaus 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: <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> Date: Tue, 2 Jul 2019 09:25:44 +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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 07:25:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX Content-Type: multipart/mixed; boundary="8rICfo8CI0pzmhBA1uEE2T5CxRpyhZUVc"; protected-headers="v1" From: Florian Schmaus To: Dave Cridland , Barry Leiba Cc: Joe Hildebrand , Alexey Melnikov , XMPP Working Group , Peter Saint-Andre , RFC Errata System Message-ID: <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: --8rICfo8CI0pzmhBA1uEE2T5CxRpyhZUVc Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 02.07.19 00:10, Dave Cridland wrote: > On Mon, 1 Jul 2019 at 14:18, Barry Leiba > wrote: >=20 > > > 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) > >=C2=A0 =C2=A0Those are potentially longer strings then DNS labels = are allowed to > >=C2=A0 =C2=A0be. >=20 > OK, so there's more to it than that. >=20 >=20 > Hold your horses - I'm not sure that's actually true. >=20 > In particular: >=20 > 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 th= e > subject of a DNS request - see, for > example,=C2=A0https://tools.ietf.org/html/rfc6120#section-3.2 Even assuming that IPv4/v6 addresses in domainparts would not work outside a single server, they are useful in test deployments and the like, and hence it does not appear to be sensible to strictly forbid them in domainparts. You obviously do not need a DNS lookup if you already have an IP. I do not think that RFC6120 needs to explicitly mention that, but maybe it does not hurt either. > 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. Depends on your definition of "arbitrary labels" I guess. Are they allowed to contain other code points besides those valid in U-labels? How long are they allowed to be? U-labels come with an indirect length restriction. POSIX limits the maximum hostname, which is sometimes used as domainpart, to 255 bytes, but this would exceed the maximum of 63 bytes of a DNS label. > c) I don't think we want A-Labels. It's just going to cause confusion -= > is=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as=C2=A0xn--vhqr= 8o.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. I can not remember that I ever ran into problems caused by A-labels in domainparts. And hence I assume that the cost of explicitly disallowing them isn't worth the gain. If we can, we should not make the PRECIS operations on the domainpart to require anything besides the "inspection" of every code point, with as less as possible context around the inspected code point involved. Note that instead of forbidding A-labels / ACE in domainparts, RFC7622 currently states in =C2=A7 5. XMPP applications MUST support IDNA2008 for domainparts which I interpret as "use U-labels of your DNS name in the domainpart (if applicable)". - Florian --8rICfo8CI0pzmhBA1uEE2T5CxRpyhZUVc-- --93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0bBvhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFKU4Af+PN2SDzQiYUX641uVjxh85u/+T4+WBy/Nl3MtPOx+mPYINKE5n2ayGTX5 B/1PqdZotl8Ur2LkMDwDNKSpV5M+B9nNpo/mjepXLwf90Pj0O/DoflYyS9bAbfey ucMFU0fPohlI+RrjjEYcd74w52s42RhcDbUOcwPVOfL7x3IhGTvBj/JzDdcGRDKW bpKLWyw6CbWuBoDqRxdWpCFONWZMZV00PuMoGJx1BCs3vBWXO+s1yqaA4+j3qE+O 2Bzd746EKsJMy5bAkX49ZW7sS31Mwjbqu36E0DmvxA4+zi0WpX6Cs9JBOkEFtQ+N WfEsWNHkGwgiGRepQU+wj+P+mP7l4w== =ubUC -----END PGP SIGNATURE----- --93NntvTPrKgF6FfoR7TdPCTdLStX5y9ZX-- From nobody Tue Jul 2 06:51:32 2019 Return-Path: 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 DED141200B7 for ; Tue, 2 Jul 2019 06:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Aet1d7uS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gDqrs/Pn 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 vrwr6IRFcizv for ; Tue, 2 Jul 2019 06:51:10 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4448112009E for ; Tue, 2 Jul 2019 06:51:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 89B79205B8; Tue, 2 Jul 2019 09:51:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 02 Jul 2019 09:51:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=bLKBGIw2sCmfA/bUDbPobCXcJ1l MtU9ZRKzJ4bx+OV8=; b=Aet1d7uS57giMyUpU12Pv4tT98H1rUDHiGFNV9l9hwV IJgc1FGyxUWOtV/NchLJ3g9dKgfakDIQe7hFcepPsNdB7Oh9lTJO92g6RQOekj4T 69qZefiY2tN3chFm0XnsqedHXF66QEelkWNRNPc3U+Io14qzLjldUu56Jp42i2ha 0QsZOiPJf6y/qGmrFXwphKmjmPywH6+QBNPf0HTWrUndPKLQd412gNbSQCdRu2ql BeajFkK98LvLZ1x5I9wqggAppFsi0Vpj92XWLIQyvqc7b113w1m9qXWLaGzdtyyu B0aFc3oqvd0P4+3/v7nHMvVYlWD5ZKTajQdFV1ukLpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bLKBGI w2sCmfA/bUDbPobCXcJ1lMtU9ZRKzJ4bx+OV8=; b=gDqrs/PnmmeniMsL83ekb4 A1LDVIBXhFEPqgaRBs2f+dYAXHrqGf1YQitYaf9B6AS3Dzmi2pUIyI9tbJjjr95G e7t3BjULxrekdteQ2Grj0I0IQ7y4++V1EMo+jUG8VuBaJ+1jz74UPoCMCwqyOvfO DJV0+/9o1ccNLEQ52YkAuJiYbnSfXgJSPAkS2mfxMz0Ryd6ueOAgnl/Fy+GGKK/+ 4cg9Qg6dz4SHD0uWXrU9iKfQKutO/bpvr7MvLmw1SeZuRjuv+HmLU/cp4mwa3Ho9 jwhSffEZH850x2eXU/ptC6bcWYMCFuKoopJMqsLGe9bx1tzMRmLYc9V0ts+u718A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesghdtrefotdefjeenucfhrhhomheprfgvthgvrhcu ufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqnecuff homhgrihhnpehunhhitghouggvrdhorhhgnecukfhppeejiedrvdehrdefrdduhedvnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimhenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 492C080062; Tue, 2 Jul 2019 09:51:06 -0400 (EDT) To: Florian Schmaus , Matthias Wimmer , xmpp@ietf.org, Barry Leiba , Dave Cridland Cc: Joe Hildebrand , RFC Errata System , Alexey Melnikov References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@stpeter.im; prefer-encrypt=mutual; keydata= mQINBFETDzsBEAC0FOv1N3ZJzIIxN6cKD475KVS9CHDPeYpegcOIPnL5eY1DCHeh/IwS1S7R CePtmiybNoV9FsI4PKUknzXQxA6LVEdAR/LUlhgJKjq+gsgp8lqbEILhg13ecH66HwLS9rar bQkC47T7kL8miIPBFC6E3A4Lq1L+eueO6UcLhKgoYkMxOjdiWrMgKTnVpch5ydLkPm/z0Zo8 zRgqlPuTLeCrXXZYnjHXLVFN2xy04UzOs7P5u5KVfx5Z7uQisr8pXtyLd6SpTZo6SHgKBv15 uz0rqXhsJojiGtOXfWznAjaS5FUOORq9CklG5cMOUAT8TNftv0ktsxaWDL1ELDVQPy1m7mtz o+VREG+0xmU6AjMo/GHblW1UU7MI9yCiuMLsp/HLrFuiosqLVZ85wuLQ2junPe3tK8h15Ucx IXAcpQ1VqIaDQFbeuLOXJTF8YHpHdpHYt/ZM1ll7ZBKGAo8yd7uF7wJ9D3gUazwdz9fFjWV7 oIk7ATwOlFllzmWDn+M2ygbHOGUGMX5hSaa8eDSieiR2QoLdn27Fip7kMBTJ2+GISrfnJTN/ OQvmj0DXXAdxHmu2C4QgmZbkge35n129yzXn9NcqzrGLroV62lL3LgX6cSbiH5i7GgWY6CAP b1pMogV0K475n9FvOSDRiG4QSO5yqKiA3OP5aKrIRp2TNAk4IwARAQABtCZQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPokCOQQTAQIAIwUCURMPOwIbAwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEOoGpJErxa2p6bgQAKpxu07cMDOLc4+EG8H19NWXIVVy bOEvfGuHYZaLKkPrhrMZwJiOwBpyISNRt9qzX1eLCVaojaoEVX6kD8MGc5zKFfiJZy3j7lBW l+Ybr7FfXYy2BbAXKx49e1n6ci9LmBrmVfAEaxtDNPITZ9N9oUAb9vS0nrG036EwteEHAveQ vlDjO7lhz6+Cv7lZQgBj9rZ6khfcQ4S3nSCQaKLQ9Iav4fqxI7SfuPKnx6quHX3JNLGnVo3w l+j/foCK0iTrmtHxCI3kc/bx6g32pRjHEPX0ALMBhmzU2uca+TE0zCEC96mgYXAUCwdnCFWy beIEbt6pz65iML13kAVAq0H/GqncnMGN0MbOatnw1Tdz/vkLojIy7QbPcQ0plUFxv5491xPf IrHhOWdRXp6WUt88fcqhT6MHZpVRtusj2ornKVVn+Y0GLsMMCTcrXJRG7Ao1YV72t/pJpzfG WSaaxolxDIZ6B+76jrIhUhiWgo/4nf+DN6BIlCZQ6j6xxjjx462cu02kuhIILTk2pzaMOufT BWx0uJhZk/KP2Fay/41pX7pvVOwRC4uIlKsLnJKLPS7EDa4BUUxENfd/9LqOGwlII8BbSe98 PLMI8sXkcigc3UXMVda9ll0YhQa+lbP1NaszmnBhwuiCsgnPGbImsJuRzgEEgckwP/dNeyr6 MlFMyfaeuQINBFETDzsBEADBzOsEHpUmhkRUjH9Tek87dn5P/Yh/L/HptgCGk40TL/C+kYdk d3HyteMEf061PNmsS/Rq8k37Fu3VODYb9SPYKxtgksKSYUtIkPKvao09K9QNWPqyWuNf0F+i AjVMUudaEVFJ7bHF310RDwLY5IvLeCXxtvG+Vv/i+g77d2WdPDp+zLJ8306C4yBKjSJV8xW0 cn2fd7NviIEN6cNHTsZNDZVMlgYPrxnwSq8GTEPGC7HsLIwGcx3hIe9QjnPw9CpAmQENpDEy WcxgF5uwo2NJECoDswKz1Nb0gfawF3ZIbD+GcLujTu94iJuVg25jATWm9wTgcfZo4UPllRGX dIb8uWwUFQlLQgd4ROLZZtXNGmHIymJrV2crx53gxup+1j0XqhlzKg8xbImWhEfS9oHZkRK8 VHgmWSIt7TNwNir6N5j3lqwWVBhnu6GzF01sKGNySlqNRbd0fqhakCkK71b8ot8tYTcYG5Lg 10z6HTbgQx2UwLthUjqbblDQ+GLmrOhiWklLXRsnlnPMwnEyFePAnsT5tasy2Cn9qjpttNDa h7PB8iFUi9mtTF/XDVgpFaB5G3CDV7Q2NgbAI6g6QhLIAmXzSP635G83mda0TKXHQXHDyLJT Tn+WVFU7t4m4uLt+0DsWU8jXHQWyUTNG9WPUrXhusDUAPHxFCQ/n/lQVBwARAQABiQIfBBgB AgAJBQJREw87AhsMAAoJEOoGpJErxa2pqfgP/ApN+TRu2bBIgaw1dr3AznSSha84DIpXUDh3 udZvQrGbUtz8/mA+e3iZEN/cmmBw2LGlAuQoJNILTZQ318yTP+E5QU7fJH7FVsohUyvrMfyt 3IMA9jg0Z9MuloLezvIjjMfFeNa0ROgDb/ubOT7JQzi1kwN8Lu3lO80HwqBHXEeOLoislUSn ZajRKvITbKWkZ6PHRjlMw1Wk4oIi6VLHgGgj79zzL3uhML2663m7imShvz1QcHTwvyR5i8cZ bNOEkotZyERiA1p7YHuruS+QvTi3ZPoQbnMUB3a7py9d11bw1+w3LiAUGZE/z5hBWOFxYtw+ w/U/Vx0BwJGYlwU3M2W20uEXe+qxz7wnakygKjmLiD2z4njfKjcNCiV3FmXrpmWgADln1c4j fxDh0NrndrsM8FPDf1TMPtOZgFDkKripc9xkZ/25P6xn27oTOHWKcAC0QhxSH+HuVBBRk8Ag F+zAbDZe4/L6+kanSrycIXW+wCzwBq61aWsz2QhhuKjozVkhk4dRG+CfjzAFjnyxwYERn3uX VKQAwTwcdNcTI9RV98IsNrw9Y4lJEAg6CjNPmiD5+EASycqaOuToRSGukr8sOQLWLPyTnez/ aG8Xf7a+fntWzK2HuDYoSDhJJrylWw/lMklOBm4wtMeNA0zcQH6AQV/GzQVQkSGqrLuMVIV/ Message-ID: <0866fe2c-245f-97bb-7888-21964c83e8f0@stpeter.im> Date: Tue, 2 Jul 2019 07:51:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8EMb5KLazI3bLW9CUJCx1LLKK3LV8bbhR" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 13:51:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8EMb5KLazI3bLW9CUJCx1LLKK3LV8bbhR Content-Type: multipart/mixed; boundary="77M0dQMBnKRCuFcHqdSVqDY1tNBszxpIy"; protected-headers="v1" From: Peter Saint-Andre To: Florian Schmaus , Matthias Wimmer , xmpp@ietf.org, Barry Leiba , Dave Cridland Cc: Joe Hildebrand , RFC Errata System , Alexey Melnikov Message-ID: <0866fe2c-245f-97bb-7888-21964c83e8f0@stpeter.im> Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> In-Reply-To: --77M0dQMBnKRCuFcHqdSVqDY1tNBszxpIy Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/2/19 1:25 AM, Florian Schmaus wrote: > On 02.07.19 00:53, 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 =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD I think= a Chinese user would more >> likely enter =E5=95=86=E4=B8=9A=E3=80=82=E4=B8=AD=E5=9B=BD because whi= le entering Chinese characters there >> is no key on the keyboard, that would enter a Western full stop. So to= >> enter =E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD he would have to change hi= s keyboard layout at least twice. >=20 > Thanks for pointing this out. From RFC3490: >=20 > 1) Whenever dots are used as label separators, the following > characters MUST be recognized as dots: U+002E (full stop), U+3002= > (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 > (halfwidth ideographic full stop). >=20 > We may want to consider adding a mapping rule from those to U+002E in > the domainpart. There's a reason IDNA is defined in terms of labels. If we update or replace RFC 7622, we should do the same. Peter --77M0dQMBnKRCuFcHqdSVqDY1tNBszxpIy-- --8EMb5KLazI3bLW9CUJCx1LLKK3LV8bbhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAl0bYUkACgkQ6gakkSvF rakxbQ//fgiAUWMu+4cBkPnJie4cDjxHe5aHpknfEzx5uZPqejUHBFYWi1C3vuHC 4w9L8yjo3auwkB4K3vVjC0WBOggjfb/MtcsEr7Wr3Z6IvOwzViDow2NjUWuPdx2N c4i2tDlO3Z2h8JHgFuxZCS5EhJL6Pk5cCVxUcYkUrudrC+qEB1huQjpSH4IJzLx4 QuX6hWEPcr4UlU/lSu+Y0AhkFHpZe9LGci/K2RVealfp7TNWrqTXG2kmWnpIfhPL WibszO72Zvv5Jh3OseL7bpvY00+Flnb69kyhCEfsKyqQ4PPNG8G+sAKnhZxxB6A9 YiLJ/H1zdrMBhJuvYyKYRai9XxMiK9vXUqEdpMhSHKYpFKllzFWXubsB7A8q+w4g WvnU5JXUHtLP2QAFmRHMuvWObABGOdE4okRIO3t6xfiKNNnY8flfKk5L51ZqzIri dklI0XrOMSNY7Xu3fZ0nAH+aK/KKqabMNVgY4S7J5xt02e6Z4pRoE9/OIDfDbxdA drDraphzWeD+EilvStWEaeL6XTntulIDbipF0GbxWjgTSIETkyXKtKJYu7XB3Xv+ cfSEr2BeE1BrfsxIPvTgze/v8C1lgR0OugMCmc7uevjRErsB1OZEgR7upXCB3EAA PC7qrAVxN5AjNbIjIJtpKfGkClEe6HP1zihpsI3Uzpp4RTwbilc= =w8Xh -----END PGP SIGNATURE----- --8EMb5KLazI3bLW9CUJCx1LLKK3LV8bbhR-- From nobody Tue Jul 2 08:04:05 2019 Return-Path: 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 8CF58120296; Tue, 2 Jul 2019 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 r1PA3bsyi-fE; Tue, 2 Jul 2019 08:03:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5B7120148; Tue, 2 Jul 2019 08:03:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D506EB81F34; Tue, 2 Jul 2019 08:03:25 -0700 (PDT) To: flo@geekplace.eu, stpeter@mozilla.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, xmpp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190702150325.D506EB81F34@rfc-editor.org> Date: Tue, 2 Jul 2019 08:03:25 -0700 (PDT) Archived-At: Subject: [xmpp] [Errata Held for Document Update] RFC7622 (5769) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:03:45 -0000 The following errata report has been held for document update for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5769 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Florian Schmaus Date Reported: 2019-06-30 Held by: Barry Leiba (IESG) Section: 3.2.1 Original Text ------------- An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890]. Corrected Text -------------- An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890], or the DNS label separator "dot" (U+002E, FULL STOP). Notes ----- The current specification forbids the inclusion of dots (".") in the domainpart, since they are not allowed in NR-LDH nor U-labels. But they should be allowed, as otherwise a DNS name could never be put into an XMPP domainpart (which is commonly done). ----- Verifier notes ----- This is correct as far as it goes, but there's more to the fix than this, so proper discussion, consensus, and document update are needed. There are, for example, other dot characters that need to be allowed as well as U+002E. The bottom line is that Florian is correct that DNS label separators need to be allowed, and the proper fix to the text is deferred to any future document update. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Jul 2 08:07:14 2019 Return-Path: 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 4429F120181; Tue, 2 Jul 2019 08:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 26PYCzWcyJmJ; Tue, 2 Jul 2019 08:07:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC2C120235; Tue, 2 Jul 2019 08:07:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 85DA9B81F48; Tue, 2 Jul 2019 08:07:02 -0700 (PDT) To: swhited@atlassian.com, stpeter@mozilla.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, xmpp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190702150702.85DA9B81F48@rfc-editor.org> Date: Tue, 2 Jul 2019 08:07:02 -0700 (PDT) Archived-At: Subject: [xmpp] [Errata Verified] RFC7622 (4534) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 15:07:12 -0000 The following errata report has been verified for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4534 -------------------------------------- Status: Verified Type: Editorial Reported by: Sam Whited Date Reported: 2015-11-14 Verified by: Barry Leiba (IESG) Section: 3.2.2 Original Text ------------- An entity that performs enforcement in XMPP domainpart slots MUST prepare a string as described in Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in [RFC5892]. Corrected Text -------------- An entity that performs enforcement in XMPP domainpart slots MUST prepare a string as described in Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in [RFC5895]. Notes ----- RFC 5892 is just a list of codepoints; the rules to which it is referring (and that are referred to in the ABNF and other places in the document) are in RFC 5895. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Jul 9 05:02:40 2019 Return-Path: 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 F31AE120442 for ; Tue, 9 Jul 2019 05:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=babelmonkeys.de 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 zFsZUCBmMocx for ; Tue, 9 Jul 2019 05:02:27 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [173.212.225.104]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2B5120453 for ; Tue, 9 Jul 2019 05:02:26 -0700 (PDT) Received: from [IPv6:2001:4dd6:d9d8:0:9778:7831:2c08:4207] (2001-4dd6-d9d8-0-9778-7831-2c08-4207.ipv6dyn.netcologne.de [IPv6:2001:4dd6:d9d8:0:9778:7831:2c08:4207]) by babelmonkeys.de (Postfix) with ESMTPSA id CFF991180157 for ; Tue, 9 Jul 2019 14:02:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=babelmonkeys.de; s=201801; t=1562673743; bh=bDjaZ499r9T8haQBgqCZhY6LDmstq8OOaOfq3WZpNxs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gMo6ctykFxgGsI04RFUjVKa6c+qlX9L+mM3AT1AVuUmDDqYotGW/EEpfvcV4T+cWT kK4cGYOuwqaRNal+V7Hb21sGSDBPQHh38WRkLfzufSZ30KaM9mPwY7WUQloqW2vGl/ ewhcfgGYtIENuY4adwZ4FZW1BqMk/w4J6xDAfUeIbtPOrOHysl67pHyGF0caH0nqwv nujE+iobO5gfKJxaDg9KciGrSJla/FUD6oEC93q3K8GgqTXYfz3HTn7lYr79nvXA9a 7oP0qLk+rMMrRcvHNhK0+fEB0AplbvWeMbxqz7Stbop3zuI2fLG1Hh8zVA0LUhmCxt RIR7a8sCumv3w== To: xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> From: Florian Zeitz Openpgp: preference=signencrypt Autocrypt: addr=florob@babelmonkeys.de; prefer-encrypt=mutual; keydata= mQINBFLs5OwBEADRBcJ2AqblJXr/lhGCINP9rKGCiaTK78bERZYKNP05JBLo6sLQHP2G6m0q M5/iPufZgbWNdZN1E8x3owvY32O06N93rFanoNSIHM8vwv9Jag3eAAZ6AZCJ/0rKGHZqulOU Hoio3CRbbbRn8VQaT1bGy12W7enphJAbdKOOVSWgDrX+u4fGCUaAWg9Hbfp0rcy4Rn0H0jr3 dZXqGcxgJNYYeuJlk65V+rpWEvedG1vOaKzRGNPaweCHWB6vaQB+jtDeQg2dH0x36ICXLvwJ WreEizoE5OcA5st6QMkGVq/plgkUdVD07UdcWWcB7Y9XEALg9ie5iiD+ph9FlbQLWVCKfnUj jVLpNYxq/snG3CF1h60sU2EdK93o85IplvFmlhy5onTPwuRdM1AytgMMP2MbFITKdpYmicxD GoF6USXSAB7UpxF+EF9D+HSpbG90T7Srys2ES3ixstap8SRxErA2aZWknvif8Gt5rktdWHJP ImohQthRaysndO6xD65L32KNYziXLDWgfWApmlWA/iKQwnev8v60dSwrhC0ueA4VJKnaCS4y dLZiUColxiEhzX15iiJ4W03P3Fzk5czUhDuc7dnXUWIaACbmeqJxiqS5f7fk5Ycy/TaEcre3 pFPkxKb7MCZj50D5RoRcAIBsLdikzVJJ6M/s5NctAnnONo88zQARAQABtCZGbG9yaWFuIFpl aXR6IDxmbG9yb2JAYmFiZWxtb25rZXlzLmRlPokCVgQTAQIAQAIbIwcLCQgHAwIBBhUIAgkK CwQWAgMBAh4BAheAFiEEm1mXp9lqB60YgRyDl6FqgGS9LJ4FAlxUNZQFCQtIhCgACgkQl6Fq gGS9LJ5N7RAAppYgXWLzy3mcdo7VlPLAaE8J4fH48X3KWMFPqD+9LSs/DEx1TiAa1DyjXiqw mMx1FKipk6mUPCOck7wLFYyxN34tLKbwLb1U2d2bEBMyxmXFKqU+npqdO5PqZKeUpy5wplR9 XTK0XppCdnor+qskEIDrweydQ8ldcX1X4aGcT9mmHWyVDp6pTC9cDO/vZjCPdNdb8+HxxgrN Ym0+cQjuxTV7kIHW74AfMWr8Sfu4J4gpw1N5lQy7XMaJoPubsCgl416MjYCBInqbhMhRp4I/ jB4GXh/K3LIX3RYkMgzuUp4XmKvstNFl1XNgF8HPvYoZeLSpWAvHEq4eIg4yAXsVpcssBIq8 HfBjZBaAyrWARqYw3bdP1Iqkqzakm+onu5YQcLLQU+wKYYUgE7iMFPuMHhMIY7hdXsL2WPYd vUXZWtTQetQiPryMmQFD0yQK3zvVIcCWuE52D6uC/n9on/gNc1b4nD0gXDvpoWDTXjgobCgI 6I793qORqdzdg7RP83i/vBtYsd5ZoZ05Qpb8fcf/oqmYvAHjinNlKkeG0GPx7Fn7gI0n2js4 VO2r1X+lUijVuaGZVKHW0zBUHqQFKJiRSrcUCBtdmO8KO5PocVsqcqkdxz3mop9wqRVH8b8d 0LuelyS2NJYd8vyYRVWiJIkJFx28TbUIMQrsqKtiCfOLGGK5Ag0EUuzk7AEQAN+o5sHQQRH0 DAC+doo/UZZcB0iKQR8PBTobFsKE+pNfJ6gA7DAr8XWKs/jfLe2VB0EhRH9QrDGgE/H/PuTw SDkHJeruaLR1ofVo0Uh0LVI4/hq8iDAr5SdIVuf5KRqJtcCMZ0FsEFYuWN7e7iwx8Y6EK3eT dEfUAPVvNMdV1pKqK3zGZnQv1+M2Lo5QThf8io2ZcQwRJlPUVET7NNeEWJVdGyiniXsmDik/ m7vx77M6vwMIZlQiJjnOi0Bis/gY62RoJUJ9jPwKH674RG4XWu0H9yDWZf8jKWM4FsSlgNHk 2AiVlFMW/RyTWJYCEMY7T8NxkzT9e7Xb4j2H5MhlBTALzwUqC6X0Og1+PNCAH70biXzijvWX ijtTQvmSAa/d4B1A56EfM318hhPvgX6XbwbytFq4sBCpVY8uYgr+apB81eGiBV8Nq3w72djJ CAW1cRNYwxSkAerwu1gyAmLAC9K5lhXTLspdjdG8n1AFjMCZAfBBDaIAxcVgjj6QVaQgU6cY O8UjHnQzc/8mZSC/tOfpjlL1cApwg1Rw4AaHdS8/4wUk4+WLguCk3G29UW3jOmqbCfwspJ2N 3Mw4aaXAiOOcLLs4J6qcuBLC1OxLB5tSPuX+LlYcSctdqcgcL9qzZuLdNCaI+/tEADgic/TE /bpchkh00DyD4uJaw9cQmNSDABEBAAGJAjwEGAECACYCGwwWIQSbWZen2WoHrRiBHIOXoWqA ZL0sngUCXFQ1mwUJC0iELwAKCRCXoWqAZL0snuAzEACkVgaihxvG5bQdGVetflc2+rO73Zut Ik5FcMNr5EtBmxOgiGzprKCd2gyQSYMlaYrynGC4DcBypZ/hNMUoXVzaZfoFueMh+5GMyc/Z 91h1omKiVYzT14BRDWUX90RVCFtId7rVbISjPDJffNb1qcP6EqCB2QlzdFPzxosJrxQihtO/ HTs0034puTNmRhLGwzOnk/OZb5ZlBQbHOoxhAEIPjH2C0RPV9AarpkCjcBUAdMvwb5fN1Wkq Lrw/6PQs83xIIi5BkzmjiLnDQcshFNw31pHmRnjkKgzGIR38WzeFxik/+AVol8dahovri6YE V80tnjDvbzXzxPqQhRrO3u1p7cHnsHqbF7wa45mS5w4T8cqEBTDHFTZcZPSgfxYRr6MCK0+B lm+m4c67YZm7/JEh2paxuRXoLG1cBUEo7panE3S0TosyPdrlvHvRT26D4DT624KsZBHYBXxv NDNnN5PUsL3s64ybtc0aM7TeKVFOcZA3qttMlUJSJZj4iF84DF7Alx9/QTVyPtKP6cRbHcg2 a5oCMVhb+0/7Y3WytmPjnaLcBtTCUfWX3ijmiMRPLAY2brA+FNhAVozWtr1uZ1Lijf6ozJ9n uF3n0LnP9b2mz+8eQe8gvCOU7CiXSY/ym1U+OOheddccxI4xh1aMvo8WQi0xuasTNo4LUzpD xKXs8rkCDQRS7OTsARAA36jmwdBBEfQMAL52ij9RllwHSIpBHw8FOhsWwoT6k18nqADsMCvx dYqz+N8t7ZUHQSFEf1CsMaAT8f8+5PBIOQcl6u5otHWh9WjRSHQtUjj+GryIMCvlJ0hW5/kp Gom1wIxnQWwQVi5Y3t7uLDHxjoQrd5N0R9QA9W80x1XWkqorfMZmdC/X4zYujlBOF/yKjZlx DBEmU9RURPs014RYlV0bKKeJeyYOKT+bu/Hvszq/AwhmVCImOc6LQGKz+BjrZGglQn2M/Aof rvhEbhda7Qf3INZl/yMpYzgWxKWA0eTYCJWUUxb9HJNYlgIQxjtPw3GTNP17tdviPYfkyGUF MAvPBSoLpfQ6DX480IAfvRuJfOKO9ZeKO1NC+ZIBr93gHUDnoR8zfXyGE++BfpdvBvK0Wriw EKlVjy5iCv5qkHzV4aIFXw2rfDvZ2MkIBbVxE1jDFKQB6vC7WDICYsAL0rmWFdMuyl2N0byf UAWMwJkB8EENogDFxWCOPpBVpCBTpxg7xSMedDNz/yZlIL+05+mOUvVwCnCDVHDgBod1Lz/j BSTj5YuC4KTcbb1RbeM6apsJ/CyknY3czDhppcCI45wsuzgnqpy4EsLU7EsHm1I+5f4uVhxJ y12pyBwv2rNm4t00Joj7+0QAOCJz9MT9ulyGSHTQPIPi4lrD1xCY1IMAEQEAAYkCPAQYAQIA JgIbDBYhBJtZl6fZagetGIEcg5ehaoBkvSyeBQJcVDWbBQkLSIQvAAoJEJehaoBkvSye4DMQ AKRWBqKHG8bltB0ZV61+Vzb6s7vdm60iTkVww2vkS0GbE6CIbOmsoJ3aDJBJgyVpivKcYLgN wHKln+E0xShdXNpl+gW54yH7kYzJz9n3WHWiYqJVjNPXgFENZRf3RFUIW0h3utVshKM8Ml98 1vWpw/oSoIHZCXN0U/PGiwmvFCKG078dOzTTfim5M2ZGEsbDM6eT85lvlmUFBsc6jGEAQg+M fYLRE9X0BqumQKNwFQB0y/Bvl83VaSouvD/o9CzzfEgiLkGTOaOIucNByyEU3DfWkeZGeOQq DMYhHfxbN4XGKT/4BWiXx1qGi+uLpgRXzS2eMO9vNfPE+pCFGs7e7WntweewepsXvBrjmZLn DhPxyoQFMMcVNlxk9KB/FhGvowIrT4GWb6bhzrthmbv8kSHalrG5FegsbVwFQSjulqcTdLRO izI92uW8e9FPboPgNPrbgqxkEdgFfG80M2c3k9SwvezrjJu1zRoztN4pUU5xkDeq20yVQlIl mPiIXzgMXsCXH39BNXI+0o/pxFsdyDZrmgIxWFv7T/tjdbK2Y+OdotwG1MJR9ZfeKOaIxE8s BjZusD4U2EBWjNa2vW5nUuKN/qjMn2e4XefQuc/1vabP7x5B7yC8I5TsKJdJj/KbVT446F51 1xzEjjGHVoy+jxZCLTG5qxM2jgtTOkPEpezy Message-ID: <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> Date: Tue, 9 Jul 2019 14:02:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 12:02:39 -0000 Am 02.07.19 um 09:25 schrieb Florian Schmaus: >> 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. > > I can not remember that I ever ran into problems caused by A-labels in > domainparts. And hence I assume that the cost of explicitly disallowing > them isn't worth the gain. If we can, we should not make the PRECIS > operations on the domainpart to require anything besides the > "inspection" of every code point, with as less as possible context > around the inspected code point involved. > > Note that instead of forbidding A-labels / ACE in domainparts, RFC7622 > currently states in § 5. > > XMPP applications MUST support IDNA2008 for domainparts > > which I interpret as "use U-labels of your DNS name in the domainpart > (if applicable)". > > - Florian > While I have not personally experienced problems there definitely were reports of people struggling with using A-labels during an XMPP summit in Brussels. In particular they were struggling with using U-labels in some and A-labels in other places. Many servers do not perform any normalization in this regard when processing JID-slots. This caused problems when e.g. the server configuration contained A-labels, but the client configuration was done with U-labels, or vice versa. The intend of 7622 (in particular Section 3.2.1) as I recall it was that A-labels would generally be valid in JIDs. However, software would be required to process (user) input containing A-labels so that any JID-slots would only contain U-labels on the wire. From nobody Tue Jul 9 05:26:00 2019 Return-Path: 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 5640F120151 for ; Tue, 9 Jul 2019 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PDS_NO_HELO_DNS=1.295, 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 OBCLhK1OGOLP for ; Tue, 9 Jul 2019 05:25:56 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 4F3C012014E for ; Tue, 9 Jul 2019 05:25:56 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id v19so3013039wmj.5 for ; Tue, 09 Jul 2019 05:25:56 -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:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=oyeSJWYHen23vbJta6EbhcNf5LSw7XCMcAaCP0pjyfE=; b=gWkneJdHSOkakyw5TJu7tZBa3JTdT/q4Ew5xjodMO+VGq3NeqpPGv9sw5hSTHiXZZB aj4sUb9Gsk10vB2t28Ea3KU+LNubUGVmhq7RYUzOCvcGV1ED66RH5wMQzhrLgRknNf9s DW7axj3uAHQ8UJd+OFOFjSpKDF41jNMMZ8/GBvu+Zmw38bUviQYBYrlOYYX7s52oB51Y ZXB2AZkCiypjOZJXdE0/MnBJj4KIrrmpr6cwRtjs9gk+a6WAO1pxpMnvzOJY9AVT17Q/ mSVafo7npNbxVWUJ+V8kGqKRw3qQsCJoo/isi75KbN6aMvDwbVXs4fj8fpBqXlK8mjxa +p/w== X-Gm-Message-State: APjAAAWuw3z+HA2XJ/HeSsiRx5oOnAqHTXmLJ7Zh5ki3UN/JTsmFO/6/ yNIPReEa/8NyLmGRI1Y3njOzom43oOOtOg== X-Google-Smtp-Source: APXvYqyRO9s5vQEyuQKSJUbaI5MktyhrohIglEZAPlb0l8ssCrTsXCyuUJxjrwHfv/YNzqYVGWd7YQ== X-Received: by 2002:a7b:c7cb:: with SMTP id z11mr16658433wmk.24.1562675153949; Tue, 09 Jul 2019 05:25:53 -0700 (PDT) Received: from [192.168.4.111] (athedsl-164211.home.otenet.gr. [85.75.185.17]) by smtp.googlemail.com with ESMTPSA id w25sm2486462wmk.18.2019.07.09.05.25.51 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 05:25:52 -0700 (PDT) To: xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> From: Florian Schmaus 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: <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> Date: Tue, 9 Jul 2019 14:25:50 +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: <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 12:25:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16 Content-Type: multipart/mixed; boundary="pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs"; protected-headers="v1" From: Florian Schmaus To: xmpp@ietf.org Message-ID: <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> In-Reply-To: <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> --pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 09.07.19 14:02, Florian Zeitz wrote: > Am 02.07.19 um 09:25 schrieb Florian Schmaus: >>> c) I don't think we want A-Labels. It's just going to cause confusion= - >>> is=C2=A0=E5=95=86=E4=B8=9A.=E4=B8=AD=E5=9B=BD the same as=C2=A0xn--vh= qr8o.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. >> >> I can not remember that I ever ran into problems caused by A-labels in= >> domainparts. And hence I assume that the cost of explicitly disallowin= g >> them isn't worth the gain. If we can, we should not make the PRECIS >> operations on the domainpart to require anything besides the >> "inspection" of every code point, with as less as possible context >> around the inspected code point involved. >> >> Note that instead of forbidding A-labels / ACE in domainparts, RFC7622= >> currently states in =C2=A7 5. >> >> XMPP applications MUST support IDNA2008 for domainparts >> >> which I interpret as "use U-labels of your DNS name in the domainpart >> (if applicable)". >> >> - Florian >> =3D >=20 > The intend of 7622 (in particular Section 3.2.1) as I recall it was tha= t > A-labels would generally be valid in JIDs. The question here is: Do you mean A-label or "a string which is (also) a valid A-label"? > However, software would be > required to process (user) input containing A-labels so that any > JID-slots would only contain U-labels on the wire. Exactly. This is an important insight: Any string which is a valid A-label may be valid in the domainpart of a Jid. However, if this string got derived from an U-label, then you did something wrong. As JID domainparts constructed from DNS names which contain U-label(s) should conserve the U-label presentation (and not use the ACE/A-label form). - Florian --pCJmTBOv6PAYLxdMoksTjxOs2JjXrK2Bs-- --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0kh85fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFJmVQgAuidS5Q7HQD1x7OyStyv6wh6JrZieHbk5oTRiHQHLt7AJRrfX5Vg8B2It bDy31WGkrgkYsZDoM5Y1FGz5Xtsn2XAcrT6CqcnwqsVEl9D1A34c6lO4CIMr+Bcr ygDg5aOmJKg5wxpYefIg9WN35QpIDcxV4JW0T5nbS5MzJysi9wjnnILBYsdu5mUz NF00wgplMtHRZGw3Qu4qe8ykSN8xJ1n7eFOWdljS7I3gqgebSImbi2kF6EhV7Oxb U29xYTxAn5d8F4kBJpTXc1KyTahOHkPGuYZrWPUmmCjpSLrY+lLV6NM3LbRHslIn ec/Flx8nWKEPywbTVJZchq1a/CTtKw== =bLp/ -----END PGP SIGNATURE----- --04F2snYVn5rbLD0WzNCRmHwhxdL8ppT16-- From nobody Tue Jul 9 06:14:30 2019 Return-Path: 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 23D1512012D for ; Tue, 9 Jul 2019 06:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=babelmonkeys.de 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 hy0cvrIQLf9m for ; Tue, 9 Jul 2019 06:14:27 -0700 (PDT) Received: from babelmonkeys.de (babelmonkeys.de [173.212.225.104]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2861200FE for ; Tue, 9 Jul 2019 06:14:26 -0700 (PDT) Received: from [IPv6:2001:4dd6:d9d8:0:9778:7831:2c08:4207] (2001-4dd6-d9d8-0-9778-7831-2c08-4207.ipv6dyn.netcologne.de [IPv6:2001:4dd6:d9d8:0:9778:7831:2c08:4207]) by babelmonkeys.de (Postfix) with ESMTPSA id 17F2C1180157 for ; Tue, 9 Jul 2019 15:14:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=babelmonkeys.de; s=201801; t=1562678064; bh=56BXezXpH/qUe8PKQLdVeyeesMiDlv1MjNwlEajpBDs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Hp1NOqEUkk8pm1t+VykoRGOKdmAkfGD8sDElSw5OxgZIxCBVOs4D2Fmj/4aZCF20U 552IIUFC4F/fjzZbcwQlaZA0i4nlzdyDWvA02qfIu9ppIrjAjQzxtFLvfM7lUsGs7y b95UtHxH2F4CQahLsNMCdH/HMHBd5YsE6AQpfpgUMCjxSdl0FZIQntqeB/ZpWFWPZE HQnjOvdub2loUg89UIWgU6VeCFaOrmRty6TanB3x5Wyb/AlcnsJx8BLmxn1/6V15gI GSHJVuAU3QCJQ0zBrEOLYWWOJHN7gfDjbGuuokA3zWPa7fIgzXkonJW03khgpduEuX y/HTwQ6fpes0A== To: xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> From: Florian Zeitz Openpgp: preference=signencrypt Autocrypt: addr=florob@babelmonkeys.de; prefer-encrypt=mutual; keydata= mQINBFLs5OwBEADRBcJ2AqblJXr/lhGCINP9rKGCiaTK78bERZYKNP05JBLo6sLQHP2G6m0q M5/iPufZgbWNdZN1E8x3owvY32O06N93rFanoNSIHM8vwv9Jag3eAAZ6AZCJ/0rKGHZqulOU Hoio3CRbbbRn8VQaT1bGy12W7enphJAbdKOOVSWgDrX+u4fGCUaAWg9Hbfp0rcy4Rn0H0jr3 dZXqGcxgJNYYeuJlk65V+rpWEvedG1vOaKzRGNPaweCHWB6vaQB+jtDeQg2dH0x36ICXLvwJ WreEizoE5OcA5st6QMkGVq/plgkUdVD07UdcWWcB7Y9XEALg9ie5iiD+ph9FlbQLWVCKfnUj jVLpNYxq/snG3CF1h60sU2EdK93o85IplvFmlhy5onTPwuRdM1AytgMMP2MbFITKdpYmicxD GoF6USXSAB7UpxF+EF9D+HSpbG90T7Srys2ES3ixstap8SRxErA2aZWknvif8Gt5rktdWHJP ImohQthRaysndO6xD65L32KNYziXLDWgfWApmlWA/iKQwnev8v60dSwrhC0ueA4VJKnaCS4y dLZiUColxiEhzX15iiJ4W03P3Fzk5czUhDuc7dnXUWIaACbmeqJxiqS5f7fk5Ycy/TaEcre3 pFPkxKb7MCZj50D5RoRcAIBsLdikzVJJ6M/s5NctAnnONo88zQARAQABtCZGbG9yaWFuIFpl aXR6IDxmbG9yb2JAYmFiZWxtb25rZXlzLmRlPokCVgQTAQIAQAIbIwcLCQgHAwIBBhUIAgkK CwQWAgMBAh4BAheAFiEEm1mXp9lqB60YgRyDl6FqgGS9LJ4FAlxUNZQFCQtIhCgACgkQl6Fq gGS9LJ5N7RAAppYgXWLzy3mcdo7VlPLAaE8J4fH48X3KWMFPqD+9LSs/DEx1TiAa1DyjXiqw mMx1FKipk6mUPCOck7wLFYyxN34tLKbwLb1U2d2bEBMyxmXFKqU+npqdO5PqZKeUpy5wplR9 XTK0XppCdnor+qskEIDrweydQ8ldcX1X4aGcT9mmHWyVDp6pTC9cDO/vZjCPdNdb8+HxxgrN Ym0+cQjuxTV7kIHW74AfMWr8Sfu4J4gpw1N5lQy7XMaJoPubsCgl416MjYCBInqbhMhRp4I/ jB4GXh/K3LIX3RYkMgzuUp4XmKvstNFl1XNgF8HPvYoZeLSpWAvHEq4eIg4yAXsVpcssBIq8 HfBjZBaAyrWARqYw3bdP1Iqkqzakm+onu5YQcLLQU+wKYYUgE7iMFPuMHhMIY7hdXsL2WPYd vUXZWtTQetQiPryMmQFD0yQK3zvVIcCWuE52D6uC/n9on/gNc1b4nD0gXDvpoWDTXjgobCgI 6I793qORqdzdg7RP83i/vBtYsd5ZoZ05Qpb8fcf/oqmYvAHjinNlKkeG0GPx7Fn7gI0n2js4 VO2r1X+lUijVuaGZVKHW0zBUHqQFKJiRSrcUCBtdmO8KO5PocVsqcqkdxz3mop9wqRVH8b8d 0LuelyS2NJYd8vyYRVWiJIkJFx28TbUIMQrsqKtiCfOLGGK5Ag0EUuzk7AEQAN+o5sHQQRH0 DAC+doo/UZZcB0iKQR8PBTobFsKE+pNfJ6gA7DAr8XWKs/jfLe2VB0EhRH9QrDGgE/H/PuTw SDkHJeruaLR1ofVo0Uh0LVI4/hq8iDAr5SdIVuf5KRqJtcCMZ0FsEFYuWN7e7iwx8Y6EK3eT dEfUAPVvNMdV1pKqK3zGZnQv1+M2Lo5QThf8io2ZcQwRJlPUVET7NNeEWJVdGyiniXsmDik/ m7vx77M6vwMIZlQiJjnOi0Bis/gY62RoJUJ9jPwKH674RG4XWu0H9yDWZf8jKWM4FsSlgNHk 2AiVlFMW/RyTWJYCEMY7T8NxkzT9e7Xb4j2H5MhlBTALzwUqC6X0Og1+PNCAH70biXzijvWX ijtTQvmSAa/d4B1A56EfM318hhPvgX6XbwbytFq4sBCpVY8uYgr+apB81eGiBV8Nq3w72djJ CAW1cRNYwxSkAerwu1gyAmLAC9K5lhXTLspdjdG8n1AFjMCZAfBBDaIAxcVgjj6QVaQgU6cY O8UjHnQzc/8mZSC/tOfpjlL1cApwg1Rw4AaHdS8/4wUk4+WLguCk3G29UW3jOmqbCfwspJ2N 3Mw4aaXAiOOcLLs4J6qcuBLC1OxLB5tSPuX+LlYcSctdqcgcL9qzZuLdNCaI+/tEADgic/TE /bpchkh00DyD4uJaw9cQmNSDABEBAAGJAjwEGAECACYCGwwWIQSbWZen2WoHrRiBHIOXoWqA ZL0sngUCXFQ1mwUJC0iELwAKCRCXoWqAZL0snuAzEACkVgaihxvG5bQdGVetflc2+rO73Zut Ik5FcMNr5EtBmxOgiGzprKCd2gyQSYMlaYrynGC4DcBypZ/hNMUoXVzaZfoFueMh+5GMyc/Z 91h1omKiVYzT14BRDWUX90RVCFtId7rVbISjPDJffNb1qcP6EqCB2QlzdFPzxosJrxQihtO/ HTs0034puTNmRhLGwzOnk/OZb5ZlBQbHOoxhAEIPjH2C0RPV9AarpkCjcBUAdMvwb5fN1Wkq Lrw/6PQs83xIIi5BkzmjiLnDQcshFNw31pHmRnjkKgzGIR38WzeFxik/+AVol8dahovri6YE V80tnjDvbzXzxPqQhRrO3u1p7cHnsHqbF7wa45mS5w4T8cqEBTDHFTZcZPSgfxYRr6MCK0+B lm+m4c67YZm7/JEh2paxuRXoLG1cBUEo7panE3S0TosyPdrlvHvRT26D4DT624KsZBHYBXxv NDNnN5PUsL3s64ybtc0aM7TeKVFOcZA3qttMlUJSJZj4iF84DF7Alx9/QTVyPtKP6cRbHcg2 a5oCMVhb+0/7Y3WytmPjnaLcBtTCUfWX3ijmiMRPLAY2brA+FNhAVozWtr1uZ1Lijf6ozJ9n uF3n0LnP9b2mz+8eQe8gvCOU7CiXSY/ym1U+OOheddccxI4xh1aMvo8WQi0xuasTNo4LUzpD xKXs8rkCDQRS7OTsARAA36jmwdBBEfQMAL52ij9RllwHSIpBHw8FOhsWwoT6k18nqADsMCvx dYqz+N8t7ZUHQSFEf1CsMaAT8f8+5PBIOQcl6u5otHWh9WjRSHQtUjj+GryIMCvlJ0hW5/kp Gom1wIxnQWwQVi5Y3t7uLDHxjoQrd5N0R9QA9W80x1XWkqorfMZmdC/X4zYujlBOF/yKjZlx DBEmU9RURPs014RYlV0bKKeJeyYOKT+bu/Hvszq/AwhmVCImOc6LQGKz+BjrZGglQn2M/Aof rvhEbhda7Qf3INZl/yMpYzgWxKWA0eTYCJWUUxb9HJNYlgIQxjtPw3GTNP17tdviPYfkyGUF MAvPBSoLpfQ6DX480IAfvRuJfOKO9ZeKO1NC+ZIBr93gHUDnoR8zfXyGE++BfpdvBvK0Wriw EKlVjy5iCv5qkHzV4aIFXw2rfDvZ2MkIBbVxE1jDFKQB6vC7WDICYsAL0rmWFdMuyl2N0byf UAWMwJkB8EENogDFxWCOPpBVpCBTpxg7xSMedDNz/yZlIL+05+mOUvVwCnCDVHDgBod1Lz/j BSTj5YuC4KTcbb1RbeM6apsJ/CyknY3czDhppcCI45wsuzgnqpy4EsLU7EsHm1I+5f4uVhxJ y12pyBwv2rNm4t00Joj7+0QAOCJz9MT9ulyGSHTQPIPi4lrD1xCY1IMAEQEAAYkCPAQYAQIA JgIbDBYhBJtZl6fZagetGIEcg5ehaoBkvSyeBQJcVDWbBQkLSIQvAAoJEJehaoBkvSye4DMQ AKRWBqKHG8bltB0ZV61+Vzb6s7vdm60iTkVww2vkS0GbE6CIbOmsoJ3aDJBJgyVpivKcYLgN wHKln+E0xShdXNpl+gW54yH7kYzJz9n3WHWiYqJVjNPXgFENZRf3RFUIW0h3utVshKM8Ml98 1vWpw/oSoIHZCXN0U/PGiwmvFCKG078dOzTTfim5M2ZGEsbDM6eT85lvlmUFBsc6jGEAQg+M fYLRE9X0BqumQKNwFQB0y/Bvl83VaSouvD/o9CzzfEgiLkGTOaOIucNByyEU3DfWkeZGeOQq DMYhHfxbN4XGKT/4BWiXx1qGi+uLpgRXzS2eMO9vNfPE+pCFGs7e7WntweewepsXvBrjmZLn DhPxyoQFMMcVNlxk9KB/FhGvowIrT4GWb6bhzrthmbv8kSHalrG5FegsbVwFQSjulqcTdLRO izI92uW8e9FPboPgNPrbgqxkEdgFfG80M2c3k9SwvezrjJu1zRoztN4pUU5xkDeq20yVQlIl mPiIXzgMXsCXH39BNXI+0o/pxFsdyDZrmgIxWFv7T/tjdbK2Y+OdotwG1MJR9ZfeKOaIxE8s BjZusD4U2EBWjNa2vW5nUuKN/qjMn2e4XefQuc/1vabP7x5B7yC8I5TsKJdJj/KbVT446F51 1xzEjjGHVoy+jxZCLTG5qxM2jgtTOkPEpezy Message-ID: Date: Tue, 9 Jul 2019 15:14:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 13:14:29 -0000 >> The intend of 7622 (in particular Section 3.2.1) as I recall it was that >> A-labels would generally be valid in JIDs. > > The question here is: Do you mean A-label or "a string which is (also) a > valid A-label"? > Maybe you want to enlighten me what the distinction is you make here, and how it is useful? I can only imagine that it is one of intent. Yet, I'm having a hard time imagining people creating labels that consist of 'xn--' followed by a valid punycode encoding of IDNA-valid codepoints, but insisting these are not an A-label. >> However, software would be >> required to process (user) input containing A-labels so that any >> JID-slots would only contain U-labels on the wire. > > Exactly. This is an important insight: Any string which is a valid > A-label may be valid in the domainpart of a Jid. However, if this string > got derived from an U-label, then you did something wrong. As JID > domainparts constructed from DNS names which contain U-label(s) should > conserve the U-label presentation (and not use the ACE/A-label form). > It seems to me that you are implying that software should not convert something that looks like an A-label to a U-label either? I.e. each label of a domainpart always has to remain in the representation provided by the user? Regards, Florian From nobody Mon Jul 22 01:55:09 2019 Return-Path: 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 68CD71201B0 for ; Mon, 22 Jul 2019 01:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6hfFtEIET2Yb for ; Mon, 22 Jul 2019 01:55:04 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 D7B671201A1 for ; Mon, 22 Jul 2019 01:55:03 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id n4so38571209wrs.3 for ; Mon, 22 Jul 2019 01:55:03 -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:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=/YoZPtYXIIFe/LvAxYHD1DB+SOivyph2RPfmjdl82dM=; b=iVUIgcUO9drqTAc9YYy/axjVr7flGDPfZIw4VErgLB8DAfkINc1ygc/2A7ufh/gk9R +/VaHBT/YwF3mU9lNbMPW+Nc6C0a1FRXv60GfovXbhaIFsooDzT1nKvAgxt/KqbtdmgP 4RSzoPG3fmZ8njWVdxeo35LZw+kZjUqJPXyWm2cgvXGgkcbI8s5GFdJxEM5Gm4H5f2TP xUyjGUAIQoFtNU5bX/is0prCQQQLgkUWkWAUKnxucCjf/jFP7vHgZbqU9B04L5o0NJbU RC9WQUMbequU8NmrN2O9TPka+6pMlwGFHxRt/7pMI6+aEJ3jC87UpvSZowQyJ3EVkows 06BA== X-Gm-Message-State: APjAAAWbsgNLOV4mTsxPDkycmT4vROHoW75LZr1FWBjWUuiGjsvMb55u Y8bVx6ysEFoUxqpbURy1+bgViDDYPTI= X-Google-Smtp-Source: APXvYqwqFSmbQpYOuPqLAjdhzpBI1keHG4VH0gZAHeQFVML3njC9JkgGGW06ahKgAdwolc/ZWzdj1w== X-Received: by 2002:a5d:4309:: with SMTP id h9mr71264005wrq.221.1563785701686; Mon, 22 Jul 2019 01:55:01 -0700 (PDT) Received: from [10.188.34.160] (nat-inf.rrze.uni-erlangen.de. [131.188.6.45]) by smtp.googlemail.com with ESMTPSA id e19sm51539031wra.71.2019.07.22.01.55.00 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 01:55:00 -0700 (PDT) To: xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> From: Florian Schmaus 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: Date: Mon, 22 Jul 2019 10:54:59 +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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 08:55:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn Content-Type: multipart/mixed; boundary="SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n"; protected-headers="v1" From: Florian Schmaus To: xmpp@ietf.org Message-ID: Subject: Re: [xmpp] [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> <9150b28a-d773-853e-845f-6de4632ed836@geekplace.eu> <059429f5-c456-5c8d-84cd-1e3569daf757@babelmonkeys.de> <16f8e609-18f7-7381-b76f-2ddb39b1338c@geekplace.eu> In-Reply-To: --SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 09.07.19 15:14, Florian Zeitz wrote: >>> The intend of 7622 (in particular Section 3.2.1) as I recall it was t= hat >>> A-labels would generally be valid in JIDs. >> >> The question here is: Do you mean A-label or "a string which is (also)= a >> valid A-label"? >> > Maybe you want to enlighten me what the distinction is you make here, > and how it is useful? Of course. As I wrote in a previous mail, I want to avoid PRECIS for the domainpart to require anything more heavyweight besides what is most of the time a codepoint-by-codepoint validation routine. Otherwise implementations have to perform a semantic analysis of the given string in order determine if they are dealing with a DNS Name consisting of only A-labels or an IPv4/v6 address, or something which is potentially forbidden. I think that adds unnecessary complexity and is overkill, as validating XMPP implementations would perform that on every inbound JID they encounter. > I can only imagine that it is one of intent. Yet, I'm having a hard tim= e > imagining people creating labels that consist of 'xn--' followed by a > valid punycode encoding of IDNA-valid codepoints, but insisting these > are not an A-label. >=20 >>> However, software would be >>> required to process (user) input containing A-labels so that any >>> JID-slots would only contain U-labels on the wire. >> >> Exactly. This is an important insight: Any string which is a valid >> A-label may be valid in the domainpart of a Jid. However, if this stri= ng >> got derived from an U-label, then you did something wrong. As JID >> domainparts constructed from DNS names which contain U-label(s) should= >> conserve the U-label presentation (and not use the ACE/A-label form). >> > It seems to me that you are implying that software should not convert > something that looks like an A-label to a U-label either? > I.e. each label of a domainpart always has to remain in the > representation provided by the user? Not at all. I am only talking about what is allowed on the wire. We are also in the fortunate situation that domainparts do not require ASCII compatible encoding (ACE), and users are used to enter the IDNA/U-label representation of a DNS name in their XMPP (client) software. Whether or not software checks if the entered string into its UI is an A-label, is not part of what I am considering. Although if I would, then I'd probably argue that users do usually not enter ACE / A-label into UIs. How often have you entered xn--ber-goa.de into your browser? Of course, it potentially can not hurt if the software tries to convert those to U-labels. But that is not a concern of the wire protocol which RFC7622 describes, although a note about this would probably be helpful. - Florian --SZCeObHepL7vooASPIp5lQoXPe1KGLZ5n-- --S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl01eeNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFK7Cgf/eJd7cz88WOW75KyrX/lYgEI/EMsYu20m3aBlKQih9uSf/RY+4xBuSynO U/h4ujRoUneH51QHweenkmM+nE1FqfShLZtOOMIcnZMuplM5Y+e4U11FYiu2Mvv3 3DoczO2xfYed9Upp2rZtBK03mowvoo+VVlkoo5l53YT8+kMx8ek6grd7ZzarNIJV fn36Y6MEfX8zCU54GDD+totzBXLxmwHxi9I9s0tN82w9UEXUz4bQQZKAFTNBIxad v858k3KWRJz/c0r0SVj1/wmuUFkrKvSg5WBN9u5/Tc/n/ZgMSmkjZWMk8diIRwbc ESg+Ot7scfBnx7aWufVSaDmYSYbjCQ== =Mb/z -----END PGP SIGNATURE----- --S1LCxRKY2YKrb88IWJOwbFt8bbCstXaIn-- From nobody Mon Jul 22 02:12:57 2019 Return-Path: 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 35FE61201B0 for ; Mon, 22 Jul 2019 02:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 EZuUFCX7l_Gg for ; Mon, 22 Jul 2019 02:12:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6773312002F for ; Mon, 22 Jul 2019 02:12:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 70409B80E75; Mon, 22 Jul 2019 02:12:44 -0700 (PDT) To: stpeter@mozilla.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, jhildebr@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: flo@geekplace.eu, xmpp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190722091244.70409B80E75@rfc-editor.org> Date: Mon, 22 Jul 2019 02:12:44 -0700 (PDT) Archived-At: Subject: [xmpp] [Technical Errata Reported] RFC7622 (5789) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 09:12:55 -0000 The following errata report has been submitted for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5789 -------------------------------------- Type: Technical Reported by: Florian Schmaus Section: 3.2.1 Original Text ------------- An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890]. Corrected Text -------------- 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 [RFC5890] - % U+0025 PERCENT SIGN - . U+002E (FULL STOP, DNS label separator "dot") - : U+003A (COLON) - ] U+005B (LEFT SQUARE BRACKET) - [ U+005D (RIGHT SQUARE BRACKET) Notes ----- This is a follow up and update on Errata ID #5769. Besides allowing DNS label separators in the domainpart, this further allows codepoints not allowed in U-labels but required by the IP-literal rule of RFC6874, which is used by RFC7622 to allow IPv6 addresses in XMPP domainparts. As in the previous errata, this also drops the reference to NR-LDH labels, which I believe to be unnecessary. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Jul 22 05:45:14 2019 Return-Path: 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 2ED81120043; Mon, 22 Jul 2019 05:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 CjHK6VhVgsAO; Mon, 22 Jul 2019 05:45:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34F212001A; Mon, 22 Jul 2019 05:45:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B42BFB818F0; Mon, 22 Jul 2019 05:44:54 -0700 (PDT) To: flo@geekplace.eu, stpeter@mozilla.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, xmpp@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190722124454.B42BFB818F0@rfc-editor.org> Date: Mon, 22 Jul 2019 05:44:54 -0700 (PDT) Archived-At: Subject: [xmpp] [Errata Held for Document Update] RFC7622 (5789) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 12:45:06 -0000 The following errata report has been held for document update for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5789 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Florian Schmaus Date Reported: 2019-07-22 Held by: Barry Leiba (IESG) Section: 3.2.1 Original Text ------------- An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890]. Corrected Text -------------- 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 [RFC5890] - % U+0025 PERCENT SIGN - . U+002E (FULL STOP, DNS label separator "dot") - : U+003A (COLON) - ] U+005B (LEFT SQUARE BRACKET) - [ U+005D (RIGHT SQUARE BRACKET) Notes ----- This is a follow up and update on Errata ID #5769. Besides allowing DNS label separators in the domainpart, this further allows codepoints not allowed in U-labels but required by the IP-literal rule of RFC6874, which is used by RFC7622 to allow IPv6 addresses in XMPP domainparts. As in the previous errata, this also drops the reference to NR-LDH labels, which I believe to be unnecessary. ===== Verifier Notes ===== As with the related errata report, this is held for document update because more discussion and consensus is needed. So this is on record for that discussion. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG