I'm a bit confused. What we are starting with is the published RFCs, deployed now for several years, and seeing yet wider deployment because of IE7. Any removal of characters that are currently allowed by those RFCs is a backward incompatible change. And any backwards-incompatible change surely needs good, solid justification.
<br><br>Some cases are clear enough that they don't need much evidence. The characters are (1) not part of normal words, and (2) have clear and present spoofing problems: fraction slash, for example.<br><br>Others are not so clear, such as the combining marks. Removal of these would severely handicap many languages (I gave the vowel analogy for English), so they need to be carefully assessed:
<br><ul><li>Is there any evidence of known spoofs with these characters?</li><li>Do the techniques already in use (eg in Firefox and IE7), or recommended in <a href="http://www.unicode.org/reports/tr36/">http://www.unicode.org/reports/tr36/
</a>, handle known or prospective spoof attempts?</li><li>...<br></li></ul>Mark<br><br><div><span class="gmail_quote">On 11/27/06, <b class="gmail_sendername">Vint Cerf</b> &lt;<a href="mailto:vint@google.com">vint@google.com
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">mark,</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">taking this from the other direction, one might start with 
a pretty limited set(s) of characters (but far more than present use of LDH) 
that are believed to be &quot;safe&quot; and then try to find ways to expand the set(s) 
within the tolerance of safety risk. Plainly there will be differences of 
opinion as to what is &quot;safe enough&quot; - the expressiveness of the characters 
permitted in IDNs should not, in my opinion, be required to have the same degree 
of expressiveness as one would expect in natural written languages. These are, 
after all, computer-based identifiers, technically speaking. Plainly we want 
them to have some linguistic value in the sense that they are memorable, but the 
presence of search, cut/paste, and directories suggests that perfect 
memorability is less critical than, say, global interoperability. 
</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">I hope no one reads this and thinks I am deliberately 
short-changing the expressiveness side of the equation but I am deeply concerned 
that we appreciate the intended utility of IDNs compared to general multilingual 
discourse.</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">vint</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div dir="ltr" align="left"><span></span>&nbsp;</div>
<div>&nbsp;</div>
<div dir="ltr" align="left">
<div dir="ltr" align="left"><font face="Arial" size="2">Vinton G Cerf</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">Chief Internet 
Evangelist</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">Google</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">Regus Suite 384</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">13800 Coppermine 
Road</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">Herndon, VA 20171</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2"></font>&nbsp;</div>
<div dir="ltr" align="left"><font face="Arial" size="2">+1 703 234-1823</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2">+1 703-234-5822 (f)</font></div>
<div dir="ltr" align="left"><font face="Arial" size="2"></font>&nbsp;</div>
<div dir="ltr" align="left"><font face="Arial" size="2"><a href="mailto:vint@google.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">vint@google.com</a></font></div>
<div dir="ltr" align="left"><font face="Arial" size="2"><a href="http://www.google.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.google.com</a></font></div>
<div dir="ltr" align="left">&nbsp;</div></div>
<div>&nbsp;</div><br>
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:idna-update-bounces@alvestrand.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">idna-update-bounces@alvestrand.no</a> 
[mailto:<a href="mailto:idna-update-bounces@alvestrand.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">idna-update-bounces@alvestrand.no</a>] <b>On Behalf Of </b>Mark 
Davis<br><b>Sent:</b> Monday, November 27, 2006 12:19 PM<br><b>To:</b> 
<a href="mailto:idna-update@alvestrand.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">idna-update@alvestrand.no</a><br><b>Subject:</b> IDNAbis Goals<br></font><br></div><div><span class="e" id="q_10f2a984bd7fdf6f_1">

<div></div>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 &quot;can't&quot; 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.
  <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><li>Remove (or discourage) non-spacing marks.
  <ul>
    <li>This is quite controversial. These marks are needed by many languages; 
    excluding them is like removing vowels from English: &quot;<a href="http://microsoft.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> microsoft.com</a>&quot; becoming &quot;<a href="http://mcrsft.cm" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
mcrsft.cm</a>&quot;.
    </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><li>Remove (or discourage) archaic / technical characters (characters not in 
  common modern use)<br>
  <ul>
    <li>Unicode supplies a proposed list of such characters, in <a href="http://www.unicode.org/reports/tr39/#General_Security_Profile" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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></li></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 
</span></div></div>

</blockquote></div><br><br clear="all"><br>-- <br>Mark