<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<META content="MSHTML 6.00.2900.2995" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=428340821-27112006><FONT face=Arial
color=#0000ff size=2>We probably should take into account as much as we are
able the registered domain names as opposed to those that might possibly have
been registered under the earlier rules. Also, one wonders to what extent those
IDNs that have been registered have been part of the domain name parking
business as opposed to domain names for what I will call functioning Internet
destinations (not only web sites but other services also). It may be that not
many registrations fall into the area of backward
incompatibility.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=428340821-27112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=428340821-27112006><FONT face=Arial
color=#0000ff size=2>vint</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=428340821-27112006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV> </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> </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> </DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><A
href="mailto:vint@google.com">vint@google.com</A></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><A
href="http://www.google.com/">www.google.com</A></FONT></DIV>
<DIV dir=ltr align=left> </DIV></DIV>
<DIV> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Mark Davis [mailto:markdavis@google.com]
<BR><B>Sent:</B> Monday, November 27, 2006 1:48 PM<BR><B>To:</B> Vint
Cerf<BR><B>Cc:</B> idna-update@alvestrand.no<BR><B>Subject:</B> Re: IDNAbis
Goals<BR></FONT><BR></DIV>
<DIV></DIV>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>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>...<BR></LI></UL>Mark<BR><BR>
<DIV><SPAN class=gmail_quote>On 11/27/06, <B class=gmail_sendername>Vint
Cerf</B> <<A href="mailto:vint@google.com">vint@google.com </A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2>mark,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff 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
"safe" 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 "safe
enough" - 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 face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2>vint</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN></SPAN> </DIV>
<DIV> </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> </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> </DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:vint@google.com" target=_blank>vint@google.com</A></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial size=2><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.google.com/" target=_blank>www.google.com</A></FONT></DIV>
<DIV dir=ltr align=left> </DIV></DIV>
<DIV> </DIV><BR>
<DIV lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:idna-update-bounces@alvestrand.no"
target=_blank>idna-update-bounces@alvestrand.no</A> [mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:idna-update-bounces@alvestrand.no"
target=_blank>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
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:idna-update@alvestrand.no"
target=_blank>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 "can't" are disallowed.
<BR><BR>Here is what I've heard so far:<BR>
<OL>
<LI>Allow Unicode 5.0 characters
<LI>Provide for some mechanism for more quickly updating to successive
Unicode versions.<BR>
<LI>Allow for combining marks at the end of bidi fields
<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>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: "<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://microsoft.com" target=_blank> microsoft.com</A>" becoming "<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://mcrsft.cm" target=_blank> mcrsft.cm</A>".
<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>
<UL>
<LI>Unicode supplies a proposed list of such characters, in <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.unicode.org/reports/tr39/#General_Security_Profile"
target=_blank>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>Certain scripts are quite clearly archaic, and could be easily removed
or discouraged.
<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 </BODY></HTML>