From nobody Sun Jun 30 14:49:31 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 D8F571201D1 for ; Sun, 30 Jun 2019 14:49:29 -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 dvCYMN1oSVlj for ; Sun, 30 Jun 2019 14:49:27 -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 959561201D0 for ; Sun, 30 Jun 2019 14:49:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 40238B81D6A; Sun, 30 Jun 2019 14:49:21 -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: <20190630214921.40238B81D6A@rfc-editor.org> Date: Sun, 30 Jun 2019 14:49:21 -0700 (PDT) Archived-At: Subject: [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: Sun, 30 Jun 2019 21:49:30 -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/eid5769 -------------------------------------- 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 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). 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 Sun Jun 30 15:23:51 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 CC5A01201D1 for ; Sun, 30 Jun 2019 15:23:49 -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 cab0DF9gOjy1 for ; Sun, 30 Jun 2019 15:23:47 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 870A51201CD for ; Sun, 30 Jun 2019 15:23:47 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id m24so24425819ioo.2 for ; Sun, 30 Jun 2019 15:23:47 -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=bQKCmwl1wExMOzYyrNduEg59ROefQV3IXlP7gDEc/kA=; b=GCUN4+8wd2aClHzjokw1G+BbMb3PRgjkduSuxOZjNaFdyQCq7WS9ZZ+Dq6kBNmybpu rDrzaaTut6MqTyzeh/4BMlg4NXy9Xx092PEB2YAIBkV41UAOBT7ZQfdHSJNPCV43VV7S 0ML9+r6EnIgVdHvCgge87xYAVfRyXflfAJII26/li66H+CJSvWPXiWBY3TxIdAVfeQIJ mpzKc57aEcGYoNzT6jqVyWfggMq5wNoSShPYBDL+fnbcIWMt/5ZOlkDw0BCsOlKj20tV I6prkJesgGqrDubAZF+GS79b2LU/j7dfEZkvjiZ9g5UfvuIuxhhXqftrdizjM5cOaIGr +6dw== X-Gm-Message-State: APjAAAV0DdKhis1Na0lBUbtSJiK4O/oiUTEnOskQ/g9VmUHDZp6cgG+p Uv1AiPRURfZUOJsvfkEtTgoXzzhpPWJ527+YpHU= X-Google-Smtp-Source: APXvYqzlOZVapJuQt0aPxBfFQ6h6sjWoaGkNQTAJ6KpgsDa5qDmxH4KSMWB5V25txNLGgrN3o6qyNjfXP1bBYbav3pA= X-Received: by 2002:a02:5489:: with SMTP id t131mr24798141jaa.70.1561933426164; Sun, 30 Jun 2019 15:23:46 -0700 (PDT) MIME-Version: 1.0 References: <20190630214921.40238B81D6A@rfc-editor.org> In-Reply-To: <20190630214921.40238B81D6A@rfc-editor.org> From: Barry Leiba Date: Sun, 30 Jun 2019 18:23:35 -0400 Message-ID: To: RFC Errata System Cc: Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , flo@geekplace.eu, xmpp@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Sun, 30 Jun 2019 22:23:50 -0000 This report seems basically correct to me, though I'm not sure the suggested fix is the right one, so let's have some discussion first: 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? Characters valid for those are also valid for R-LDH labels and A-labels as well, so it seems a bit of a confusing way to define it (in particular, "xn--" are all valid characters in U-labels, but my sense is that we do not want labels in XMPP "domainpart" to actually be A-labels... right?). Similarly, do we intend to allow R-LDH labels in XMPP "domainpart"? The characters are valid, so they would be allowed by the cited text. 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? 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). Barry On Sun, Jun 30, 2019 at 5:49 PM RFC Errata System wrote: > > 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/eid5769 > > -------------------------------------- > 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 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). > > 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 Sun Jun 30 22:56:33 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 DA01A120286 for ; Sun, 30 Jun 2019 22:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 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, RCVD_IN_MSPIKE_H2=-0.001, 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 dg-SC5nM6aB7 for ; Sun, 30 Jun 2019 22:56:20 -0700 (PDT) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 5C9961201F0 for ; Sun, 30 Jun 2019 22:56:20 -0700 (PDT) Received: by mail-wm1-f52.google.com with SMTP id w9so13696131wmd.1 for ; Sun, 30 Jun 2019 22:56:20 -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=ihK/TcvkKmBqmm6MSHbzSav/D1+ZASapgAqtYmOaMJ8=; b=Ei0WjECKDoX045mAItbvRjimrFzkU2iENAMPygJCgBQp3Qpt4/9FxM9k0wKldVRAZM mzwTlRrB1e1ODiJUfNLDdRBSOq6vGNm/YOlrV13AoyeBClpe/QycgkQujdx/WRdYHgsx 6FHalZjQoVGgrm7RvnAFNviYHdFXNevJFvZdtLqqRJm49BB6VgubMglhFcrk3ZkMM0+R F28XidSmgO9EHcK/ju7lwRelYgrkamjULfAl91KVpVQNx/smq2JwOkb3JbofUQtj2Y3S Ozla6Dd1rnDbRe6EaLiWkICVPjeCPuCNrodtf/7sdWn+fvcDIp+KeHdhnnO1y6HFHWxz NKuQ== X-Gm-Message-State: APjAAAVt45hrKk2Z4G6FuelMGnfHW//lkinX2rPo0scuJt5ya3obkGHb TEWTybia8g+dwbLpoR/wJdHLhllwnvU= X-Google-Smtp-Source: APXvYqx/4Z2vWzHirNTDIP7WzLBuaA+GOr92vtZ38+8lzHPmtvmRwkPyfEyYP3Z3siV5UYMvZgXONw== X-Received: by 2002:a7b:cc81:: with SMTP id p1mr14978203wma.107.1561960578107; Sun, 30 Jun 2019 22:56:18 -0700 (PDT) Received: from [192.168.188.20] (55d494e1.access.ecotel.net. [85.212.148.225]) by smtp.googlemail.com with ESMTPSA id o6sm23609269wra.27.2019.06.30.22.56.16 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jun 2019 22:56:17 -0700 (PDT) To: Barry Leiba , RFC Errata System Cc: Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , xmpp@ietf.org References: <20190630214921.40238B81D6A@rfc-editor.org> 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: <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> Date: Mon, 1 Jul 2019 07:56:11 +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="Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi" 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 05:56:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi Content-Type: multipart/mixed; boundary="SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP"; protected-headers="v1" From: Florian Schmaus To: Barry Leiba , RFC Errata System Cc: Peter Saint-Andre , Joe Hildebrand , Alexey Melnikov , Adam Roach , xmpp@ietf.org Message-ID: <9c33c9d6-3bfb-78bb-f684-0a8fc078ac4a@geekplace.eu> Subject: Re: [Technical Errata Reported] RFC7622 (5769) References: <20190630214921.40238B81D6A@rfc-editor.org> In-Reply-To: --SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 01.07.19 00:23, Barry Leiba wrote: > This report seems basically correct to me, though I'm not sure the > suggested fix is the right one, so let's have some discussion first: >=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) Those are potentially longer strings then DNS labels are allowed to be. > 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. > so it seems a bit of a > confusing way to define it (in particular, "xn--" are all valid > characters in U-labels, but my sense is that we do not want labels in > XMPP "domainpart" to actually be A-labels... right?). Similarly, do > we intend to allow R-LDH labels in XMPP "domainpart"? The characters > are valid, so they would be allowed by the cited text. 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. > 2. Earlier, in Section 3.8, is this text that seems rather odd to me: >=20 > If the domainpart includes a final character considered to be a labe= l > separator (dot) by [RFC1034] >=20 > 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: >=20 > When a user needs to type a domain name, the length of each label is= > omitted and the labels are separated by dots ("."). >=20 > 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. 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: >=20 > 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) - Florian > On Sun, Jun 30, 2019 at 5:49 PM RFC Errata System > wrote: >> >> 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/eid5769 >> >> -------------------------------------- >> 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 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 d= omainpart, since they are not allowed in NR-LDH nor U-labels. But they sh= ould be allowed, as otherwise a DNS name could never be put into an XMPP = domainpart (which is commonly done). >> >> 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 --SuWDfjsDxw3AQBV6GxNIguigqI5uOiMRP-- --Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAl0ZoH9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIACgkQIjmn6PWF IFIFYgf/Z8nPkid01NoJj3tHJRM/ztvduHjF8Ofs0++pzmf6ZUDu+Wh96alx3yJ+ BBWK6JhPIaK2fs9wnGoJPjdUjsT7DiSfpW15Wrl/TRbBBygSkYKrUcMo+Why0YTd +6ITznNwvV6MlOVo+gisjzp8V8St7BIcGYnM46t2YYuFnDjlPjeZoIE/c+/YxLbQ +Tk9J5In0Bo7O9cfneka3VcW2cbLkt9Np2IcpYVq+xJXv09AvfKXzsMCdwU3ySos B6PHoiIIC9Mseut2BJdbbGwtrgqz8W8ZezKTWuEvA3MMVBLZ1aU4rtZ3vO6MmtwW Y6HRsfyUNX3IaRtB3lyoXZvzo+ORLA== =/Nu6 -----END PGP SIGNATURE----- --Fabj4O1Y1ikVs1dt2DP8P4goMG0rVAYRi--