<div dir="ltr">Juan, "move ahead" means what? published a revised RFC? other?<div><br></div><div>v</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 9:44 AM, Juan Altmayer Pizzorno <span dir="ltr"><<a href="mailto:juan@sparkpost.com" target="_blank">juan@sparkpost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I think it would be good to move these errata ahead, be it as<br>
“verified” or with alternate wording:  the issue of the required<br>
buffer sizes came up while my team implemented SMTPUTF8, and these<br>
(incorrect) sizes given in the RFC created confusion.<br>
<span class="HOEnZb"><font color="#888888"><br>
.. Juan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On May 22, 2016, at 2:40 AM, Martin J. Dürst <<a href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>> wrote:<br>
><br>
> [What I say below also applies to erratum 4696. If it's desirable to reply to that with the same comment, please let me know.]<br>
><br>
> I believe that Juan is essentially right.<br>
><br>
> This has come up before before, and possibly already noted by John Klensin for fixing in an eventual update.<br>
><br>
> I provided some more detailed calculations with examples in the mail to <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a> with the following identifying details:<br>
> Message-ID: <<a href="mailto:4AACA7E6.1070503@it.aoyama.ac.jp">4AACA7E6.1070503@it.aoyama.<wbr>ac.jp</a>><br>
> Date: Sun, 13 Sep 2009 17:05:58 +0900<br>
><br>
> Unfortunately, when I currently try to access the archive at<br>
> <a href="http://www.alvestrand.no/pipermail/idna-update/" rel="noreferrer" target="_blank">http://www.alvestrand.no/<wbr>pipermail/idna-update/</a> from <a href="https://www.ietf.org/wg/concluded/idnabis.html" rel="noreferrer" target="_blank">https://www.ietf.org/wg/<wbr>concluded/idnabis.html</a>, I get the following:<br>
><br>
> ----<br>
> Forbidden<br>
><br>
> You don't have permission to access /pipermail/idna-update/ on this server.<br>
><br>
> Apache/2.4.7 (Ubuntu) Server at <a href="http://www.alvestrand.no" rel="noreferrer" target="_blank">www.alvestrand.no</a> Port 80<br>
> ----<br>
><br>
> I have cc'ed Harald in the hope that the archive can be fixed soon.<br>
><br>
><br>
> I'm coping the relevant part of that mail here:<br>
><br>
> >>>>>>>><br>
> Here are my calculations. After a few tests, one finds out that punycode<br>
> uses a single 'a' to express 'one more of the same character'. The<br>
> question is then how many characters it takes punycode to express the<br>
> first character. Expressing that first character takes more and more<br>
> punycode characters as its Unicode number gets higher, so one has to<br>
> test with the smallest Unicode character that needs a certain number of<br>
> bytes in UTF-8. Going through lengths 1,2,3, and 4 per character in<br>
> UTF-8, we find:<br>
><br>
> 1 octet per character in UTF-8:<br>
> <a href="http://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.org" rel="noreferrer" target="_blank">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaa.org</a> gives<br>
> <a href="http://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.org" rel="noreferrer" target="_blank">aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaa.org</a><br>
> and has 63 characters, so 63 octets in UTF-8, 126 octets in UTF-16, and<br>
> 252 octets in UTF-32.<br>
><br>
> 2 octets per character in UTF-8:<br>
> ¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢<wbr>¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢¢.<wbr>org gives<br>
> <a href="http://xn--8aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.org" rel="noreferrer" target="_blank">xn--<wbr>8aaaaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa.<wbr>org</a><br>
> and has 58 characters, so 116 octets in UTF-8, 116 octets in UTF-16, and<br>
> 232 octets in UTF-32. 59 seems possible in theory, but impossible in<br>
> practice.<br>
><br>
> <a href="http://ँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँ.org" rel="noreferrer" target="_blank">ँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँँ<wbr>.org</a> (using the currently lowest encoded character that needs 3 bytes,<br>
> U+0901, DEVANAGARI SIGN CANDRABINDU), gives<br>
> <a href="http://xn--h1baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.org" rel="noreferrer" target="_blank">xn--<wbr>h1baaaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa.<wbr>org</a><br>
> and has 57 characters, so 171 octets in UTF-8, 114 octets in UTF-16, and<br>
> 228 octets in UTF-32. Please note that even characters in the U+0800<br>
> range would need that much, because already a character such as 'ü'<br>
> needs that much.<br>
><br>
> Trying to assess how many characters one could use of<br>
> 𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀<wbr>𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀<wbr>𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀<wbr>𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀𐌀.org<br>
> (using U+10300, OLD ITALIC LETTER A, the lowest character in Unicode 3.2<br>
> that needs 4 bytes in UTF-8) gives<br>
> <a href="http://xn--097caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.org" rel="noreferrer" target="_blank">xn--<wbr>097caaaaaaaaaaaaaaaaaaaaaaaaaa<wbr>aaaaaaaaaaaaaaaaaaaaaaaaaaaaa.<wbr>org</a><br>
> and has 56 characters, so 224 octets in UTF-8, 224 octets in UTF-16, and<br>
> 224 octets in UTF-32.<br>
><br>
> Overall, we get a maximum label length in octets of 252 octets for<br>
> UTF-32 (with US-ASCII), and 224 octets in UTF-8 and UTF-16 (with Old<br>
> Italic and the like).<br>
> >>>>>>>><br>
><br>
> Regards,   Martin.<br>
><br>
> On 2016/05/18 00:58, RFC Errata System wrote:<br>
>> The following errata report has been submitted for RFC5890,<br>
>> "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework".<br>
>><br>
>> ------------------------------<wbr>--------<br>
>> You may review the report below and at:<br>
>> <a href="http://www.rfc-editor.org/errata_search.php?rfc=5890&eid=4695" rel="noreferrer" target="_blank">http://www.rfc-editor.org/<wbr>errata_search.php?rfc=5890&<wbr>eid=4695</a><br>
>><br>
>> ------------------------------<wbr>--------<br>
>> Type: Technical<br>
>> Reported by: Juan Altmayer Pizzorno <<a href="mailto:juan@sparkpost.com">juan@sparkpost.com</a>><br>
>><br>
>> Section: 2.3.2.1<br>
>><br>
>> Original Text<br>
>> -------------<br>
>> expansion of the A-label form to a U-label may produce strings that are<br>
>> much longer than the normal 63 octet DNS limit (potentially up to 252<br>
>> characters)<br>
>><br>
>> Corrected Text<br>
>> --------------<br>
>> expansion of the A-label form to a U-label may produce strings that are<br>
>> much longer than the normal 63 octet DNS limit (potentially up to 59<br>
>> Unicode code points or 236 octets)<br>
>><br>
>> Notes<br>
>> -----<br>
>> The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1 itself)<br>
>> output by the Punycode algorithm in their corresponding A-labels.  The Punycode<br>
>> decoder (<a href="https://tools.ietf.org/html/rfc3492#section-6.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>rfc3492#section-6.2</a>) consumes at least one<br>
>> of those ASCII characters for each code point inserted into the U-label. An U-label,<br>
>> thus, can contain at the most 59 Unicode code points.<br>
>><br>
>> Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding<br>
>> Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code<br>
>> point in at most 4 octets, 236 octets is an upper bound for an U-label's length.<br>
>><br>
>> I think it should be possible to derive a tighter bound, but its rationale would likely be<br>
>> less straighforward.<br>
>><br>
>> I imagine the number 252 was originally derived by multiplying 63, the maximum<br>
>> length of an A-label (including the "xn--" prefix), by 4, the maximum number of<br>
>> octets needed to represent a code point.<br>
>><br>
>> Instructions:<br>
>> -------------<br>
>> This erratum is currently posted as "Reported". If necessary, please<br>
>> use "Reply All" to discuss whether it should be verified or<br>
>> rejected. When a decision is reached, the verifying party (IESG)<br>
>> can log in to change the status and edit the report, if necessary.<br>
>><br>
>> ------------------------------<wbr>--------<br>
>> RFC5890 (draft-ietf-idnabis-defs-13)<br>
>> ------------------------------<wbr>--------<br>
>> Title               : Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework<br>
>> Publication Date    : August 2010<br>
>> Author(s)           : J. Klensin<br>
>> Category            : PROPOSED STANDARD<br>
>> Source              : Internationalized Domain Names in Applications (Revised)<br>
>> Area                : Applications<br>
>> Stream              : IETF<br>
>> Verifying Party     : IESG<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Idna-update mailing list<br>
>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" rel="noreferrer" target="_blank">http://www.alvestrand.no/<wbr>mailman/listinfo/idna-update</a><br>
>><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">New postal address:<div>Google<br><div>1875 Explorer Street, 10th Floor</div><div>Reston, VA 20190</div></div></div></div>
</div>