<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18203" name=GENERATOR></HEAD>
<BODY 
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>Dear all WG 
members,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>About the 
JAMO characters in Korean, We still&nbsp;strongly recommend to disallow these 
characters.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>We want to 
allow&nbsp;ONLY Hangul Syllables(U+AC00 ~ U+D7A3)&nbsp;in&nbsp;revised 
IDNA.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009>I&nbsp;attached&nbsp;the letter from&nbsp;Korean 
goverment. (I think some of you may had already&nbsp;read 
it&nbsp;.)</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>I 
hope&nbsp;this document helps you to understand&nbsp;our 
situation.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>With regard 
to the local mapping draft,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009>About&nbsp;'dots' as label separators, actually Korean 
doesn't have mapping problems. But Chinese and Japanese do. </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>So I hope 
this problem will be solved in some way or other.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>And about 
'Compatibility characters', we defined Korean IDN in the draft as 
following:</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The term "Korean IDN" 
stands for "IDN consists from CJK scripts&nbsp;marked with 'Y' in 'K' 
column,&nbsp;which is Hangul Syllables(U+AC00 ~ U+D7A3),&nbsp;&nbsp;and 
LDH".&nbsp;&nbsp;</SPAN></FONT><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009> 
Permitted characters in&nbsp;Korean IDN are listed in 
[IANA-IDN-Language-ko-KR].</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>Eventhough 
in IDNA2003 allowed JAMO in Korean, we defined like this. </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>Because if 
we restrict the range of allowed characters to only Hangul Syllables(U+AC00 ~ 
U+D7A3),&nbsp;nomalization is not an issue for&nbsp;Korean IDN 
anymore.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>Again, 
allowing only&nbsp;&nbsp;Hangul Syllables in IDNA is 
recommended.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>Thank 
you.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>With 
regards,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN 
class=996431108-25032009></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>YungJin 
Suh</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=&#44404;&#47548;><SPAN class=996431108-25032009>
<DIV align=left>
<DIV><FONT face="Times New Roman" size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009>=======================</SPAN></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009></SPAN></SPAN></FONT><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN class=850041301-29012009><FONT 
face="Times New Roman" size=2>YungJin Suh</FONT></SPAN></SPAN></DIV>
<DIV><SPAN lang=EN-US style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009><FONT face="Times New Roman" size=2>Head of DNS 
section, KRNIC, NIDA</FONT></SPAN></SPAN></DIV>
<DIV><FONT face="Times New Roman" color=#0000ff size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN class=850041301-29012009><A 
href="blocked::mailto:yjsuh@nida.kr">yjsuh@nida.kr</A></SPAN></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009>+82-2-2186-4562(O)</SPAN></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009>+82-10-4820-8291(M)</SPAN></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" color=#000000 size=2><SPAN lang=EN-US 
style="FONT-SIZE: 12pt"><SPAN class=850041301-29012009>
<DIV><SPAN lang=EN-US style="FONT-SIZE: 12pt"><SPAN 
class=850041301-29012009>========================</SPAN></SPAN></SPAN></SPAN></FONT></SPAN></FONT></DIV></DIV></DIV></DIV>
<DIV dir=ltr align=left><FONT size=+0><SPAN class=996431108-25032009><FONT 
face=&#44404;&#47548;><SPAN 
class=h1><STRONG></STRONG></SPAN></FONT></SPAN></FONT>&nbsp;</DIV><BR>
<DIV class=OutlookMessageHeader lang=ko dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> idna-update-bounces@alvestrand.no 
[mailto:idna-update-bounces@alvestrand.no] <B>On Behalf Of </B>Vint 
Cerf<BR><B>Sent:</B> Monday, March 23, 2009 5:31 AM<BR><B>To:</B> Mark 
Davis<BR><B>Cc:</B> idna-update@alvestrand.no<BR><B>Subject:</B> Re: DRAFT 
Status of Work on IDNA2008 + IDNAv2<BR></FONT><BR></DIV>
<DIV></DIV>thanks Mark - I re-issued version 5 of the material so some of your 
comments have crossed in the mail. I will try to update once more to take into 
account your comments or at least annotate as reminders for discussion. 
<DIV><BR></DIV>
<DIV>v</DIV>
<DIV><BR>
<DIV apple-content-edited="true"><SPAN class=Apple-style-span 
style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0"><SPAN 
class=Apple-style-span 
style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px"><SPAN 
class=Apple-style-span 
style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px">
<DIV>
<DIV><BR class=Apple-interchange-newline>Vint Cerf</DIV>
<DIV>Google</DIV>
<DIV>1818 Library Street, Suite 400</DIV>
<DIV>Reston, VA 20190</DIV>
<DIV>202-370-5637</DIV>
<DIV><A href="mailto:vint@google.com">vint@google.com</A></DIV>
<DIV><BR></DIV></DIV></SPAN><BR class=Apple-interchange-newline></SPAN><BR 
class=Apple-interchange-newline></SPAN></DIV><BR>
<DIV>
<DIV>On Mar 22, 2009, at 3:51 PM, Mark Davis wrote:</DIV><BR 
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">Here are comments on the status. (I tried to update to 
  the later doc, but because it was only distributed in pdf, I had to do it 
  manually, so I may have missed something.) 
  <DIV><BR>
  <DIV><BR clear=all>Mark<BR><BR><BR>
  <DIV class=gmail_quote>On Fri, Mar 20, 2009 at 06:12, Vint Cerf <SPAN 
  dir=ltr>&lt;<A href="mailto:vint@google.com" 
  target=_blank>vint@google.com</A>&gt;</SPAN> wrote:<BR>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">DRAFT 
    Status of work on IDNA2008<BR><BR>3/21/2009 0523 PDT<BR><BR><BR>Vint 
    Cerf<BR><BR><BR>This brief summary is intended to provide some focus for the 
    IDNABIS WG meetings<BR>scheduled for Monday and Tuesday, March 23 
    (1740-1940) and March 24 (0900-1130).<BR><BR>One goal is to try to assess 
    rough consensus about the present documentation on the<BR>presumption that 
    we are abiding by the ground-rules set forth in the charter of the 
    WG.<BR>Another is to assess what the implications are for users, registries, 
    registrars if<BR>IDNA2008 is adopted as it presently stands. &nbsp;A third 
    goal is to examine the implications<BR>of the IDNAV2 proposal from Paul 
    Hoffman and contrast with adoption of IDNA2008.<BR><BR>I fully recognize 
    that consensus has to be assessed from mailing list exchanges, not<BR>merely 
    from appearances at our face to face meetings.<BR><BR>The material presented 
    below is by no means intended to be more than a basis for<BR>discussion, and 
    is not intended as a penultimate recommendation.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I think it would also be useful to mark where each is different from 
  IDNA2003.&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>Background<BR><BR><BR></BLOCKQUOTE>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>Under 
    the IDNABIS charter, the IDNA2008 design as it now stands makes 
    several<BR>specific assumptions or makes specific propositions to achieve a 
    number of goals:<BR><BR>0. Avoid dependence on any specific version of 
    Unicode through the use of rules<BR>&nbsp; &nbsp;for determining PVALID 
    characters based on Unicode character properties</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>add: "as much as possible". Exceptions may be necessary in some cases 
  (and are included in the draft tables).</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>1. 
    No change to the deployed DNS server functionality (domain name labels 
    limited to<BR>&nbsp; &nbsp;ASCII and case-insensitive matching 
  only)&nbsp;</BLOCKQUOTE>
  <DIV>[no change from IDNA2003]&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>2. 
    Esszet, Final Sigma, ZWJ and ZWNJ, geresh and gershayim are PVALID 
    characters<BR>&nbsp; &nbsp; some of which are treated through contextual 
    rules (there is still ongoing discussion<BR>&nbsp; &nbsp; about the 
    implications of these choices)</BLOCKQUOTE>
  <DIV><BR>This is also a current feature of the drafts, but not required by the 
  charter.&nbsp;It is unclear whether this is actually consistent with the 
  charter or not. "This work is intended to specify an improved means to produce 
  and use stable and unambiguous IDN identifiers." Effectively, any IDN with the 
  first four characters is ambiguous between versions of IDNA in that it will 
  lead to different addresses.&nbsp;<BR><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>3. 
    Unassigned Unicode characters will not be looked up</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>Just a comment (no change): IDNA2003 had the slightly different goal: 
  unassigned Unicode characters will not be returned from the DNS.&nbsp;</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>4. 
    No mapping of characters at least within the protocol 
  specification&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>5. 
    No modification of or dependence on Nameprep &nbsp;(and thus no 
    impact<BR>&nbsp; on other protocols relying on Nameprep or 
  Stringprep.)&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>6. 
    Clear specification of valid "dot" form in a way that is consistent with 
    DNS<BR>&nbsp; &nbsp; protocol requirements.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>IDNA2003 specified the dot form in a way that is consistent with DNS; 
  that is, it required no change of the DNS protocol, so this is no change. That 
  is, once in the ACE form, dots are dots.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>7. 
    Symmetry between native-character ("Unicode") and ACE ("Punycode")<BR>&nbsp; 
    &nbsp; forms of a label.</BLOCKQUOTE>
  <DIV><BR>This may be a goal, but it is not achieved by the current drafts. 
  There is a strong asymmetry between them in that in lookup, an implementation 
  need not check that what appears to be an A-Label is one, but it must check 
  that a U-Labels is one (mostly). (Comment: I believe that this should be a 
  goal: if it is important to check those requirements, then it is important to 
  test both A and U Labels; if it is not important to test them, then it should 
  not be a requirement for either one.)<BR><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>8. 
    Conversion to an inclusion list of PVALID characters (as distinct from 
    the<BR>&nbsp; &nbsp;IDNA2003 posture that excluded only a few Unicode 
    characters)&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>9. 
    Improved terminology to make categories and types of labels more 
    clear.<BR>&nbsp; &nbsp;(Definitions)&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>10. 
    Provide explanation for decisions and their motivations (Rationale) 
    to<BR>&nbsp; &nbsp; aid implementors, registries, registrants and users in 
    understanding IDNA.</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>Rationale doesn't really provide explanation for motivations in enough 
  detail to be useful. I'd recast this as: "Provide informative background 
  material (Rationale) to aid ..."</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>11. 
    Separately describe registration and lookup procedures to improve 
  clarity</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>The goal is good, but the current drafts don't meet the goal. Whether it 
  increases clarity or not is unclear, since by doing so makes it difficult to 
  determine what the similarities and differences are between the two processes. 
  So drop "to improve clarity". (A relatively small recasting of the text to 
  make it precisely parallel between them (including numbering), and point out 
  precisely where the differences are, would meet this goal.<BR><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>12. 
    Specify tests to be applied at lookup time in an attempt to limit abuse 
    of<BR>&nbsp; &nbsp; &nbsp; IDNA at all levels of registration</BLOCKQUOTE>
  <DIV><BR>That is not a change from IDNA2003. The tests are different, and are 
  expanded, but it is a quantitative difference, not qualitative. For example, 
  IDNA2003 did test bidi; we just think the IDNA2008 tests are better. And the 
  "in an attempt to limit abuse" is not true; the changes in IDNA2008 will have 
  a trifling effect on abuse at the very best, and introduce significant 
  opportunities for spoofing because of the 4 ambiguous characters. And 
  affecting the "phishing" problem is not a requirement of the charter. So this 
  item should be removed.<BR>&nbsp;<BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>13. 
    Clarify what is expected of IDNA-aware applications and domain 
    name<BR>&nbsp; &nbsp; &nbsp; "slots" with regard to invalid labels and 
    future extensibility</BLOCKQUOTE>
  <DIV><BR>These are still not nailed down in the current drafts. My 
  expectations are that once a domain name is valid, it remain valid for all 
  time -- that is, we are doing a one-time massive compatibility change, but 
  there will be no more changes that would affect compatibility. However, that 
  is not captured in the text, despite the charter requirement "This work is 
  intended to specify an improved means to produce and use stable and 
  unambiguous IDN identifiers."</DIV>
  <DIV><BR></DIV>
  <DIV>Another major change is the introduction of a mechanism for changing 
  IDNAs on the fly via the context mechanism, with and associated 
  process.<BR><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR><BR>Chartering 
    and Re-Chartering<BR><BR>(1) A Re-charter is needed if we abandon a 
    significant fraction of the IDNA2008 goals<BR>and methods. IDNAv2, as 
    described by Paul Hoffman requires a re-charter.<BR><BR>(2) A Re-charter is 
    needed if the WG decides to introduce mappings into the 
    IDNA2008<BR>specifications since the basic assumption in IDNA2008 was that 
    mapping would not<BR>be part of the specification.<BR><BR>(3) It is possible 
    that re-charter might not be needed if IDNA2008 adopts some<BR>IDNA2003 
    operations under a restricted set of conditions and only at lookup<BR>time 
    for purposes of easing the transition to IDNA2008. This would be up to 
    the<BR>AD and IESG presumably to decide.<BR><BR>Basics for IDNA2003 and 
    IDNA2008<BR><BR>Both of these specifications use the Punycode algorithm to 
    generate what<BR>IDNA2008 would call an A-label (ie. "xn-- &lt;LDH compliant 
    string&gt;") from</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>Better expressed as an XN label. That terminology can be applied to both, 
  while A-Label only makes sense for IDNA2008.&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>labels 
    expressed as a string of characters drawn from a subset of 
    Unicode<BR>defined characters.<BR><BR>DNS matching is done in the servers by 
    comparing the query string to the<BR>registered string in a case-independent 
    fashion. &nbsp;For IDNs, these comparisons<BR>are done after conversion into 
    the "xn--" prefix form. For IDNs the case insensitive<BR>matching of the DNS 
    servers applies only to the A-label form and not to the<BR>Unicode form. 
    This means that the case-insensitive matching behavior of<BR>in traditional 
    ASCII labels is not conferred on IDNs in their Unicode form.<BR><BR>The 
    case-insensitive comparisons between traditional LDH domain names 
    is<BR>approximated under IDNA2003 by using CaseFold as a mapping guide on 
    the<BR>Unicode strings being looked up. In addition, IDNA2003 also maps the 
    so-called<BR>"compatibility" characters of Unicode into their counterparts. 
    The same actions</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>=&gt; "compatibility decomposable" characters&nbsp;of Unicode into their 
  counterparts</DIV>
  <DIV>[Not all compatibility characters are decomposable and vice versa.]</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>precede 
    the registration of new domain names under IDNA2003.<BR><BR>Unicode CaseFold 
    maps to upper case and then map back to lower case.</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <DIV>This is not quite accurate; better would be to say "Unicode CaseFold maps 
  characters to&nbsp;lowercase values based on an an equivalence class formed by 
  including lowercase, uppercase, and titlecase mappings."</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>Prior 
    to Unicode 5.0, Ezsett became "SS" because there was no upper<BR>case, then 
    became "ss" in the lower case mapping. &nbsp;Under Unicode 5.0<BR>CaseFold 
    was unchanged for &nbsp;stability reasons. Consequently<BR>CaseFold 
    (ESSZETT) is "ss" rather than lower case esszett even after<BR>the 
    introduction of upper case ESSZETT in Unicode 5.0.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>=&gt;</DIV>
  <DIV>The uppercase of ezsett in Unicode is "SS", following national standards 
  and practices. As of Unicode 5.1, an uppercase version of eszett became 
  available. Under the Unicode case folding, both map to "ss".</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>Under 
    IDNA2003, both DISALLOWED and UNASSIGNED characters<BR>are looked up. If 
    abusive registrations are made using DISALLOWED<BR>or UNASSIGNED characters, 
    these registered domain names may be<BR>be found on lookup by 
    IDNA2003-compliant clients.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>This is not correct, as Erik points out.</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>Under 
    IDNA2008, UNASSIGNED and DISALLOWED characters are not looked up.<BR>If new 
    characters become defined under a new version of Unicode<BR>an old client 
    will not look them up until it is updated. Abusive registrations<BR>using 
    UNASSIGNED characters will not be looked up.<BR><BR>Script mixing is not 
    banned under IDNA2003. Under IDNA2008, BiDi<BR>bans mixing of European and 
    Extended Arabic-Indic numbers with<BR>Arabic numbers. &nbsp;That is AN and 
    EN characters may not be present in<BR>the same label. Otherwise, mixing is 
    permitted in IDNA2008.<BR><BR>IMPLICATIONS OF ADOPTING IDNA2008 AS CURRENTLY 
    SPECIFIED<BR><BR><BR>1. IDNA2008 is case sensitive for labels with non-LDH 
    characters in them but &nbsp;is</BLOCKQUOTE>
  <DIV>... with at least one non-LDH character...&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>case-insensitive 
    for LDH characters<BR><BR>for example" buecher "is all ASCII and could be 
    matched with "Buecher" or "bUecher"<BR>under IDNA2008<BR><BR>however 
    "B&lt;u-umlaut&gt;cher" would not be allowed because Tables (see 4.2.2) 
    would<BR>disallow Latin Capital letters. Some users accustomed to LDH-label 
    behavior<BR>may be surprised that "B&lt;u-umlaut&gt;cher" and 
    "b&lt;u-umlaut&gt;cher" do not match.<BR><BR>On the other hand, the 
    symmetric relationship between the IDNA2008-defined<BR>A-Label and U-Label 
    has the benefit one can use exact match for either<BR>U-label form or 
    A-label forms since they are directly and unambiguously<BR>transformable 
    into each other.</BLOCKQUOTE>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">However, 
      this symmetry will not exist for</BLOCKQUOTE>
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">cases 
      where the IDNA2003 A-Label and IDNA2008 A-label for the same</BLOCKQUOTE>
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">U-Label 
      differ. [Query: will this be a material problem only for actual</BLOCKQUOTE>
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">registrations 
      under IDNA2003 that differ in A-label form from 
  IDNA2008?]</BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>For registries, this is an advantage (equivalent to disallowing mapping), 
  but it is not so clear that it is a "benefit" for lookup.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
    <BLOCKQUOTE class=gmail_quote 
    style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"></BLOCKQUOTE><BR><BR><BR>2. 
    IDNA2008 does not ban script mixing even within labels.<BR><BR>Attempts to 
    fashion rules along these lines have run into problems<BR>in which 
    characters that may be confused for others are needed<BR>to express strings 
    in particular languages. The International Phonetic<BR>Alphabet (IPA) 
    characters are a case in point. Some are used for<BR>certain (e.g. African) 
    languages but some of these characters<BR>can be confused for others in the 
    Latin alphabet. Other examples<BR>exist in Arabic, Cyrillic, Greek among 
    others.<BR><BR>Even in the absence of intra-label script mixing, 
    inter-script confusion<BR>such as the Russian word for "restaurant" looking 
    like &nbsp;"pectopah" in<BR>Latin characters is quite 
    possible.<BR><BR>Despite the apparent desirability of such a ban at protocol 
    level, there<BR>are simply too many combinations of confusion within-scripts 
    and between<BR>scripts to benefit significantly from a protocol-level ban. 
    On the other hand,<BR>registry level constraints that may be more 
    script-aware appear to be<BR>the most effective tool we have.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I think client-level warnings are the most effective constraint. After 
  all, if we could always trust the registries, we would need *no* constraints 
  on the client side in the protocol.</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>3. 
    Esszet is permitted and its usage appears to be geographically and 
    language<BR>specific. Under IDNA2003, this character is mapped into "ss". To 
    deal with the<BR>potential conflict with previously mapped registrations in 
    which Esszet is mapped<BR>to "ss" registries would need to appeal to 
    Rationale 7.2 options, for example,<BR>to deal with this. Note that not all 
    collisions may be a consequence of mapping, i.e.,<BR>many occurrences of 
    "ss" in German text are not typographic variations of<BR>Esszett and very 
    few occurrences in Latin script, without consideration of language,<BR>are 
    variations of Esszett either.<BR><BR>4. Final Sigma is permitted and raises 
    similar issues to Esszet with regard to<BR>collisions and the same remedies 
    would apply.<BR><BR>5. ZWJ/ZWNJ<BR><BR>In IDNA2003, these characters were 
    mapped to "nothing". It has become apparent<BR>however that some Indic 
    scripts need them. Persian registries currently<BR>reject registration of 
    labels including ZWJ/ZWNJ although ZWNJ is used in<BR>writing Persian 
    languages. Arabic language does not need ZWJ/ZWNJ.<BR>Mapping to "nothing" 
    in INDA2003 has the side-<BR>effect of inhibiting domain name expression in 
    some Indic scripts including<BR>Tamil and Devanagari. Permitting either or 
    both as valid characters creates<BR>a compatibility problem similar to the 
    Esszett one; i.e., one cannot tell<BR>whether a DNS label, when converted 
    back to native character form, was<BR>intended to be written with ZWJ, ZWNJ 
    or neither.<BR><BR>Elaboration: Suppose that "ab" is a string in one of the 
    scripts in which we now<BR>propose to permit ZWNJ. &nbsp;All we have in the 
    DNS is the A-label equivalent of "ab".<BR>We can't tell from looking at it 
    whether the starting string, as seen/preferred by the<BR>registrant, 
    was<BR>&nbsp;ab &nbsp; &nbsp;or<BR>&nbsp;aZWJb<BR>since both map to the same 
    A-label.<BR><BR>Under IDNA2008, if the user enters "ab", she gets one 
    A-label<BR>while, if she enters "aXWJb", she gets a different 
    A-label.<BR>That is exactly the same as the Eszett problem -- you can't 
    tell<BR>from the IDNA2003 A-label what the original intention was and<BR>use 
    of the string under IDNA2008 gets you a different A-label<BR>than it does 
    under IDNA2003.<BR><BR>Joiner characters become invisible if inserted in 
    strings written in scripts<BR>that do not use them. </BLOCKQUOTE>
  <DIV>=&gt; in&nbsp;strings where they make no visual difference. This included 
  scripts</DIV>that do not use them, and many positions in scripts that do use 
  them. 
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Unicode 
    classifies these characters<BR>as "COMMON" so they also end up passing any 
    plausible tests to prevent<BR>mixing of scripts in a label. Contextual rules 
    are needed to restrict their use<BR>to strings in scripts where they have 
    some effect. </BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>where they could have some effect (they won't always, and even when they 
  commonly have an effect, it depends on the font).</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">We 
    end up relying on<BR>registries to adopt their use judiciously within those 
    scripts. See also the<BR>Rationale document for further 
    commentary.<BR><BR>6. Symbols and punctuation are NOT PVALID under IDNA2008 
    but are valid</BLOCKQUOTE>
  <DIV>Most symbols...&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>under 
    IDNA2003 leading to a variety of potential confusions with 
    "slash-like"<BR>symbols or other symbols used in URIs for example. IDNA2008 
    rules reduce<BR>confusion potential by making all characters with these 
    Unicode properties<BR>invalid for use with Domain labels.</BLOCKQUOTE>
  <DIV>either most, or add at the end "with certain exceptions"&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>It 
    is not clear that such symbols are critically needed for domain 
    names.<BR><BR>Another reason for banning these characters is that they 
    complicate<BR>references, discussions and databases (such as WHOIS) because 
    it is<BR>not clear how to describe them in common, informal usage.<BR>What 
    is the correct way to refer to "-" ? Is it "hyphen", "minus sign", 
    "hyphen-<BR>minus" or "short middle horizontal bar?" And is "." "period", 
    "dot", "full stop",<BR>or something else? What about "#" - is it "pound", 
    "hash", "number sign" or<BR>"tic-tac-toe"? "Heart" is another example: which 
    one is it?</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>Thus is just not an issue; there are thousands of letters that have 
  ambiguous or multiple names. This paragraph just can't be fixed; it needs 
  removal.</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>To 
    be fair, one could refer to the Unicode long name for the character or 
    even<BR>the "U+" form although this sounds pretty awkward in practical 
    terms.<BR><BR>7. JAMO characters in Korean have been made Protocol Invalid 
    (DISALLOWED)<BR>for reasons similar to (6) above. They introduce a 
    combinatorial explosion of different<BR>string representations built from 
    JAMO primitive characters. They are valid<BR>under IDNA2003.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>This is debatable. The only reasonable rationale we can include is that 
  they are only used in historic Korean.&nbsp;</DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>8. 
    Under INDA 2008, when a new version of Unicode is released the 
    following<BR>steps can be taken:<BR><BR>a. review of changes that might 
    require new rules in the IDNA2008 framework.<BR>Such a conclusion would 
    assuredly require formation of a &nbsp;WG to facilitate \new 
    RFC<BR>production. This is thought to be extremely unlikely to 
    happen.<BR><BR>b. A review of changes might only require exception rules to 
    preserve<BR>compatibility. It is possible that the required changes might be 
    delegated<BR>to an IANA action possibly in consultation with an expert 
    committee<BR>to generate new tables.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>The current drafts require new RFCs in order to change the exception 
  tables, I believe. It would be better to change that to have the exception 
  table governed by the same process as the context tables (under stability 
  provisions).</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR><BR>c. 
    Generate new tables for IANA registry (suitable for downloading as 
    needed<BR><BR>During the transition some will clients have the older tables 
    and<BR>some registries the newer ones. Lookups of Domain Names 
    containing<BR>new PVALID characters by older clients will fail under IDN2008 
    because<BR>the client will reject UNASSIGNED characters until the clients 
    are updated<BR>with the new PVALID characters.</BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>That is not the bad part of the transition. The bad part is that old 
  characters may transform from DISALLOWED to PVALID <SPAN 
  class=Apple-style-span style="FONT-STYLE: italic">only during the 
  transition</SPAN>, then corrected, or transform from PVALID to DISALLOWED only 
  during the transition, then corrected. And the correction period may be long, 
  depending on when software is updated. That is, if a program ships every two 
  years, and is updated during the correction, it will be wrong for 2 
  years.</DIV>
  <DIV><BR></DIV>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR></BLOCKQUOTE></DIV>... 
  </DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>