<font class="Apple-style-span" face="georgia, serif">Briefly:</font><div><font class="Apple-style-span" face="georgia, serif"><br></font><div><span class="Apple-style-span" style="font-family: georgia, serif; ">A. T</span><span class="Apple-style-span" style="font-family: georgia, serif; ">he <a href="http://www.unicode.org/consortium/memblogo.html">Unicode technical committee</a> is strongly in favor of stability for labels, that is:</span><br>
<ol><li><i><font class="Apple-style-span" face="georgia, serif">If a label is valid according to IDNA2008 under Unicode version V, then it is also valid under Unicode version V+1.</font></i></li><li><span class="Apple-style-span" style="font-family: georgia, serif; ">Maintaining stability in the face of changes in underlying property changes is <i>not</i> rocket science. Unicode has done for years that with its definition for recommended programmatic identifiers.</span></li>
</ol><span class="Apple-style-span" style="font-family: georgia, serif; ">B. IDNA2008 provides for this capability. That is done by adding character to Section G.</span><br><ol><li><span class="Apple-style-span" style="font-family: georgia, serif; ">For Unicode 6.0, this would involve adding one character, U+19DA NEW TAI LUE THAM DIGIT ONE as PVALID.</span></li>
<li><span class="Apple-style-span" style="font-family: georgia, serif; ">Ideally, this process would simply be automatic in IDNA2008, requiring no change in the RFC with any version of Unicode, and based purely on Unicode properties. The WG declined to do this, but did maintain the capability of doing this manually with Section G.</span></li>
</ol><span class="Apple-style-span" style="font-family: georgia, serif; ">C. If it is not done, then an implementation of IDNA2008 on a newer version of Unicode disallows strings that were valid under previous versions of Unicode.</span><br>
<ol><li><span class="Apple-style-span" style="font-family: georgia, serif; ">The argument is made that this character is not important, so it doesn't matter.</span></li><li><span class="Apple-style-span" style="font-family: georgia, serif; ">While this particular characters is of very low frequency, in our view, that is cherry-picking, and makes testing and comparison of implementations more difficult.</span></li>
<li><span class="Apple-style-span" style="font-family: georgia, serif; ">There is no harm at all to adding this character, and thus providing stability.</span></li><li><span class="Apple-style-span" style="font-family: georgia, serif; ">It also sets a very bad precedent; IDNA2008 resulted in a large incompatible change for IDNA, but people can deal with a one-time large change. Additional instability on top of that is not welcome, especially for no good reason.</span></li>
</ol><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; "><div><font class="Apple-style-span" face="georgia, serif">See also: <a href="http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html">http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html</a></font></div>
</span><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">Mark<br></font><br><i style="font-family: garamond, serif; ">— Il meglio è l’inimico del bene —</i><br>
<br><br><div class="gmail_quote">On Sun, Feb 20, 2011 at 07:14, Simon Josefsson <span dir="ltr"><<a href="mailto:simon@josefsson.org">simon@josefsson.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Mark Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> writes:<br>
<br>
> That would work fine for me, with a slight change to wording.<br>
><br>
>> Mark Davis also contributed to the document, but do not believe the<br>
>> description of the issues in this document is optimal.<br>
><br>
> =><br>
><br>
>> Mark Davis also contributed to the document, but does not believe the<br>
>> solution for the issues discussed in this document is optimal.<br>
<br>
</div>Mark, what solution would you have preferred? I may have missed your<br>
position from earlier discussion, but if we are close to a IETF-wide<br>
last call on this it may be useful re-iterate your point succinctly to<br>
see if others agree.<br>
<br>
Personally I feel uncomfortable with changes that takes us from two<br>
different compliant IDNA algorithms to three different compliant IDNA<br>
algorithms depending on when in time you implemented the standards:<br>
IDNA2003, IDNA2008-original, IDNA2008-revised. This is damaging from a<br>
security perspective. I don't know what the alternative is though.<br>
<br>
/Simon<br>
<br>
(If we consider non-compliant IDNA algorithms, there is also two other<br>
IDNA2003 variants in wide use: 1) with improper PR-29 fix, and 2) with<br>
improper dot-separation. On the client-side, the non-compliant<br>
implementations are probably more common than compliant IDNA2003.)<br>
</blockquote></div><br></div></div></div></div>