The primary reason for including this table is because of concerns from people on the IETF side. The UTC doesn't really have a strong position either way.<br><br>I agree with you that it would introduce a moderate complication. I say "moderate" because it is not trivial to detect those cases, but -- in comparison with Punycode! -- also not hugely complicated either.
<br><br>Mark<br><br><div><span class="gmail_quote">On 11/27/06, <b class="gmail_sendername">Paul Hoffman</b> <<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 9:53 AM -0800 11/27/06, Mark Davis wrote:<br>>One other restriction that I forgot.<br>><br>>B4. Disallow problematic sequences for normalization<br>><br>>These are listed<br>><<a href="http://www.unicode.org/reports/tr15/#Corrigendum_5_Sequences">
http://www.unicode.org/reports/tr15/#Corrigendum_5_Sequences</a>><a href="http://www.unicode.org/reports/tr15/#Corrigendum_5_Sequences">http://www.unicode.org/reports/tr15/#Corrigendum_5_Sequences</a><br>>This is a relatively uncontroversial change, even as a hard
<br>>restriction, since the sequences are degenerate -- not meaningful in<br>>any language.<br><br>It is premature to call this "uncontroversial", given that many of us<br>have never seen it before.<br><br>
Although the change seems useful, it also looks onerous to put in a<br>standard and expect it to be followed reasonably well. One of the<br>efforts for IDNAbis was simplification; this is far from simple.<br></blockquote>
</div><br><br clear="all"><br>-- <br>Mark