Mark,<div><br></div><div>one of the intentions of IDNA2008 was to generate tables of valid characters automatically based solely on properties of Unicode characters independent of specific versions. The modification to Section G causes changes that are Unicode version specific and this violates the motivation for developing IDNA2008 as a replacement for IDNA2003. </div>
<div><br></div><div>The tension is between maintaining a view of Internet use of Unicode that propagates the properties of older versions of Unicode rather than deriving validity from whatever the current version of it happens to be. I appreciate the stability argument you make but at the same time, propagating old "errors" seems somehow in bad taste from the engineering perspective.</div>
<div><br></div><div>v</div><div><br><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 3:43 PM, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font face="georgia, serif">Briefly:</font><div><font face="georgia, serif"><br></font><div><span style="font-family:georgia, serif">A. T</span><span style="font-family:georgia, serif">he <a href="http://www.unicode.org/consortium/memblogo.html" target="_blank">Unicode technical committee</a> is strongly in favor of stability for labels, that is:</span><br>
<ol><li><i><font 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 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 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 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 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 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 style="font-family:georgia, serif">The argument is made that this character is not important, so it doesn't matter.</span></li><li><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 style="font-family:georgia, serif">There is no harm at all to adding this character, and thus providing stability.</span></li><li><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><span style="border-collapse:collapse"><div><font face="georgia, serif">See also: <a href="http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html" target="_blank">http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html</a></font></div>
</span><div><font face="georgia, serif"><br></font></div><div><div class="im"><font face="georgia, serif">Mark<br></font><br><i style="font-family:garamond, serif">— Il meglio è l’inimico del bene —</i><br>
<br><br></div><div class="im"><div class="gmail_quote">On Sun, Feb 20, 2011 at 07:14, Simon Josefsson <span dir="ltr"><<a href="mailto:simon@josefsson.org" target="_blank">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>Mark Davis ☕ <<a href="mailto:mark@macchiato.com" target="_blank">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></div>
<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>
<br></blockquote></div><br></div>