In order to assess the advantages and disadvantages of any approach, we need to have a good idea of the goals and the weights attached to them. Here is an initial take on some of the issues so far discussed, divided into categories.
<br><br>A. Loosen some restrictions on IDNA. The goal is to allow, <span style="font-style: italic;">*where feasible*</span>, the same kind of expressive capability in other languages that is now provided for in English. It should be recognized that not all reasonable words of every language will qualify: even in English the lack of spaces and other punctuation forces compromises: words like "can't" are disallowed.
<br><br>Here is what I've heard so far:<br><ol><li>Allow Unicode 5.0 characters</li><li>Provide for some mechanism for more quickly updating to successive Unicode versions.<br></li><li>Allow for combining marks at the end of bidi fields
</li><li>Allow for ZWJ/ZWNJ in limited contexts (see a previous message).<br></li></ol>Except for #4, which probably most people haven't looked through yet, it appears that these are mostly uncontroversial.<br><br>B. Tighten some restrictions on IDNA. The purpose of this appears to be to reduce the opportunity for spoofing. Thus any proposed restrictions should be assessed against that metric. That is: (a) does the restriction reduce spoofing significantly? (b) Are there no other reasonable mechanisms for doing so?
<br><br>Here is what I've heard so far:<br><ol><li>Remove (or discourage) symbols and (most) punctuation.</li><ul><li>This appears to be mostly uncontroversial. While the vast majority of symbols and punctuation do not cause spoofing problems (I♥NY.com is not a problem, for example), there is not enough value to having them to be worth the effort.
</li></ul><li>Remove (or discourage) non-spacing marks.</li><ul><li>This is quite controversial. These marks are needed by many languages; excluding them is like removing vowels from English: "<a href="http://microsoft.com">
microsoft.com</a>" becoming "<a href="http://mcrsft.cm">mcrsft.cm</a>".</li><li>A very good case has to be made that they (a) cause problems, and (b) those problems can't feasibly be handled with other mechanisms.
</li></ul><li>Remove (or discourage) archaic / technical characters (characters not in common modern use)<br></li><ul><li>Unicode supplies a proposed list of such characters, in <a href="http://www.unicode.org/reports/tr39/#General_Security_Profile">
http://www.unicode.org/reports/tr39/#General_Security_Profile</a>. However, it is recognized that any such list will need refinement and extension in the future.<br></li><li>Certain scripts are quite clearly archaic, and could be easily removed or discouraged.
</li><li>Judging whether a character in a modern script is archaic, especially those in broad usage such as Latin, Arabic, and Cyrillic, can be quite difficult -- often these characters are pressed into use in minority languages.
<br></li></ul></ol>A major issue is the choice between removal and
discouragement. Removal has the very significant cost of breaking
backwards compatibility, so a clear case has to be made that there is
no feasible alternative to handle spoofing problems that would otherwise occur.<br><br>Mark