<font class="Apple-style-span" face="georgia, serif">A few comments.</font><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><span class="Apple-style-span" style="border-collapse: collapse; "></span><font class="Apple-style-span" face="arial, helvetica, sans-serif">> they would have known perfectly well that U+19DA wasn't a numeral</font></div>
<meta charset="utf-8"><div><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">That is simply untrue. The character is a numeral; it is just not part of the standard decimal digits. IDNA2008 chose to disallow alternate digits, but that doesn't mean that the average person will know the precise formulation in IDNA2008.</font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">></font><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="arial, helvetica, sans-serif">The day that LATIN SMALL LETTER I changes class, I'll be happy to put something in category G. This is not that day.</font></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif">Unicode was hammered by IETF people for making changes in </font><i><font class="Apple-style-span" face="georgia, serif">phenomenally</font></i><font class="Apple-style-span" face="georgia, serif"> obscure sequences of characters; it is ironic that people on this list are making comments that imply they really only care about ASCII stability.</font></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><font class="Apple-style-span" face="georgia, serif"><br>
</font></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">> </font><span class="Apple-style-span" style="border-collapse: collapse; "><font class="Apple-style-span" face="arial, helvetica, sans-serif">The downside is that, for ever more, every IDNA implementation has to deal with this exception. </font></span></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><div><span style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif">There is already a table of <b>41</b> exceptions in <a href="http://tools.ietf.org/html/rfc5892#section-2.6">http://tools.ietf.org/html/rfc5892#section-2.6</a>:</font></span></div>
<div><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: separate; "><span class="Apple-style-span" style="font-family: Times; ">[\u302E\u302F \u0640 \u07FA \u30FB \u00B7 \u05F3 \u05F4 \u0F0B \u0375 \u303B \u3031-\u3035 \u0660\u06F0 \u0661\u06F1 \u0662\u06F2 \u0663\u06F3 \u0664\u06F4 \u0665\u06F5 \u0666\u06F6 \u0667\u06F7 \u0668\u06F8 \u0669\u06F9 \u00DF \u03C2 \u06FD \u06FE \u3007]</span></span></font></div>
<div><span style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></div><div><span style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: separate; "></span>For that matter there are <b>2</b> exceptions in <a href="http://tools.ietf.org/html/rfc5892#section-2.4">http://tools.ietf.org/html/rfc5892#section-2.4</a>:</font></span></div>
<div><span style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><font class="Apple-style-span" face="georgia, serif">[\u200C\u200D]</font></span></span></div><div><span style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><br>
</font></span></div><div><span style="border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: separate; "></span>And there are <b>357</b> exceptions in <a href="http://tools.ietf.org/html/rfc5892#section-2.8">http://tools.ietf.org/html/rfc5892#section-2.8</a>:</font></span></div>
<div><span style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><font class="Apple-style-span" face="georgia, serif">[\u1100-\u115E \uA960-\uA97C \u115F-\u11A7 \uD7B0-\uD7C6 \u11A8-\u11FF \uD7CB-\uD7FB]</font></span></span></div>
<div><span style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></span></div><div><span style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><font class="Apple-style-span" face="georgia, serif">Adding a few exceptions more to guarantee stability across versions is hardly a real issue.</font></span></span></div>
<div><span style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><font class="Apple-style-span" face="georgia, serif"><br></font></span></span></div><div><span class="Apple-style-span" style="border-collapse: separate; font-family: georgia, serif; ">==== </span></div>
</span></div><div><font class="Apple-style-span" face="georgia, serif"><br></font></div></span></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><span class="Apple-style-span" style="border-collapse: separate; "><div>
<font class="Apple-style-span" face="georgia, serif">Bottom line is that the IETF can choose stability or instability. The tools for stability are there, and they are not particularly onerous. I would recommend stability in order to maintain compatibility across versions, and thus give people confidence that adopting IDNA2008 will not cause problems in the future. </font><span class="Apple-style-span" style="font-family: georgia, serif; border-collapse: collapse; ">Or the committee could have protracted discussions of the probabilities that particularly characters will or will not occur -- with most participants basing conclusions on limited or incorrect understanding of the characters involved, and </span><span class="Apple-style-span" style="font-family: georgia, serif; border-collapse: collapse; ">on <i>no</i> real data.</span></div>
<div><span class="Apple-style-span" style="font-family: georgia, serif; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: georgia, serif; border-collapse: collapse; ">Compare what has happend in Unicode. </span><span class="Apple-style-span" style="font-family: georgia, serif; border-collapse: collapse; ">We instituted a grandfathering mechanism for Unicode Identifiers set up to automatically add characters that would become invalid because of property changes. (The definition is quite close to what IDNA2008 has). Since we started guaranteeing stability, we have added exactly the following characters to be grandfathered in Unicode Identifiers.</span></div>
</span></span></div><div><font class="Apple-style-span" face="georgia, serif"><span class="Apple-style-span" style="border-collapse: collapse; "><div><br></div><div><span style="border-collapse: collapse; "><font face="'courier new', monospace"># ================================================<br>
</font><span style="font-family: 'courier new', monospace; ">2118 ; Other_ID_Start # Sm SCRIPT CAPITAL P<br></span><span style="font-family: 'courier new', monospace; ">212E ; Other_ID_Start # So <span class="il" style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; "><span class="Apple-style-span" style="background-color: rgb(255, 255, 255);">ESTIMATED</span></span><span class="Apple-style-span" style="background-color: rgb(255, 255, 255);"> </span><span class="il" style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; "><span class="Apple-style-span" style="background-color: rgb(255, 255, 255);">SYMBOL</span></span><br>
</span><span style="font-family: 'courier new', monospace; ">309B..309C ; Other_ID_Start # Sk [2] KATAKANA-HIRAGANA VOICED SOUND MARK..KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK<br></span><span style="font-family: 'courier new', monospace; "># Total code points: 4<br>
</span><span style="font-family: 'courier new', monospace; "># ================================================<br></span><span style="font-family: 'courier new', monospace; ">00B7 ; Other_ID_Continue # Po MIDDLE DOT<br>
</span><span style="font-family: 'courier new', monospace; ">0387 ; Other_ID_Continue # Po GREEK ANO TELEIA<br></span><span style="font-family: 'courier new', monospace; ">1369..1371 ; Other_ID_Continue # No [9] ETHIOPIC DIGIT ONE..ETHIOPIC DIGIT NINE<br>
</span><span style="font-family: 'courier new', monospace; ">19DA ; Other_ID_Continue # No NEW TAI LUE THAM DIGIT ONE<br></span><span style="font-family: 'courier new', monospace; "># Total code points: 12<br>
</span><span style="font-family: 'courier new', monospace; "># ================================================</span></span></div><div><br></div><div>We introduced Unicode identifiers first in March 2002 (Unicode 3.2). Including it and Unicode 6.0, there have been 8 versions since then: 3.2, 4.0, 4.0.1, 4.1.0, 5.0, 5.1, 5.2, and 6.0. We had additions to the grandfathering sets in 4 of those versions, the last being ~2.5 years ago. This mechanism is computable, and has been easy to maintain; we simply compare each successive version of Unicode to derive it. And it is a formal property in Unicode, so implementations simply pick it up; we've never had a problem with that.</div>
<div><br></div><div>We can expect roughly the same frequency for IDNA2008. This expected frequency was discussed during the development of IDNA2008. <span style="border-collapse: collapse; ">And as was said many times during the development of IDNA2008, </span><span style="border-collapse: collapse; ">these are the kind of expected small adjustments that were </span><span style="border-collapse: collapse; ">inevitable for character properties -- particularly inevitable </span><span style="border-collapse: collapse; ">once the choice not to disallow historic </span><span style="border-collapse: collapse; ">scripts for domain names was taken. I</span><span style="border-collapse: collapse; ">t isn't unusual for some of the edge </span><span style="border-collapse: collapse; ">cases for lesser-known scripts of Asia to take a while to </span><span style="border-collapse: collapse; ">shake down in actual implementations, for example.</span></div>
<div><span style="border-collapse: collapse; "><br></span></div><div><span style="border-collapse: collapse; ">That was the reason that a grandfathering clause was put in, to allow IDNA2008 to preserve absolute stability. Because the WG opted to make this a manual process, that means that periodically the table needs to be amended.</span></div>
<div><br></div></span></font><div><font face="georgia, serif">Mark<br><br><i>— Il meglio è l’inimico del bene —</i></font><br>
<br><br><div class="gmail_quote">On Fri, Oct 15, 2010 at 08:37, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
--On Friday, October 15, 2010 10:22 -0500 Pete Resnick<br>
<div class="im"><<a href="mailto:presnick@qualcomm.com">presnick@qualcomm.com</a>> wrote:<br>
<br>
> On 10/14/10 4:01 PM, Mark Davis ☕ wrote:<br>
>> The stability of domain names is far more important -- that<br>
>> once a domain name is valid, that it remain so.<br>
><br>
> So I wish to disagree with the above statement and therefore<br>
> *disagree* with the suggestion that we adopt (c) adding U+19DA<br>
> to G. I am in favor of (a).<br>
><br>
> We made a design decision in IDNA2008 that domain names that<br>
> contained other than some small set of letters, digits, and a<br>
> small set of punctuation were more trouble than they were<br>
> worth. We made it clear to folks that acceptable domain names<br>
> should only contain certain classes of characters. What I take<br>
</div>>...<br>
<div class="im">> The day that LATIN SMALL LETTER I changes class, I'll be happy<br>
> to put something in category G. This is not that day.<br>
<br>
</div>Pete,<br>
<br>
To reinforce this from a slightly different perspective, we<br>
really want people to create domain name labels because the<br>
strings have some mnemonic significance for them. If, instead,<br>
someone puts a character in a string because they found it<br>
somewhere, thought it was cute, or wanted to play games with an<br>
edge case, I don't think we should warp our general rules to<br>
keep them amused.<br>
<br>
If someone was actually using a New Tai Lue character, the<br>
assumptions of the standard are such that it is rational for us<br>
to assume that they actually understood the script and the<br>
characters in it. That implies that they would have known<br>
perfectly well that U+19DA wasn't a numeral even if it took the<br>
Unicode Standard until 6.0 to catch the problem and make the<br>
correction.<br>
<br>
We never said it explicitly, but perhaps one of our criteria<br>
should be that we are not obligated to keep labels that violate<br>
the principles of the standard stable when it is discovered that<br>
the violations are based on simple classification mistakes.<br>
<font color="#888888"><br>
john<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<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" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br></div></div></div></div>