<!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=굴림><SPAN class=996431108-25032009>Dear all WG
members,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>About the
JAMO characters in Korean, We still strongly recommend to disallow these
characters.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>We want to
allow ONLY Hangul Syllables(U+AC00 ~ U+D7A3) in revised
IDNA.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009>I attached the letter from Korean
goverment. (I think some of you may had already read
it .)</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>I
hope this document helps you to understand our
situation.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>With regard
to the local mapping draft,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009>About '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=굴림><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=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><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=굴림><SPAN
class=996431108-25032009> The term "Korean IDN"
stands for "IDN consists from CJK scripts marked with 'Y' in 'K'
column, which is Hangul Syllables(U+AC00 ~ U+D7A3), and
LDH". </SPAN></FONT><FONT face=굴림><SPAN class=996431108-25032009>
Permitted characters in Korean IDN are listed in
[IANA-IDN-Language-ko-KR].</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><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=굴림><SPAN class=996431108-25032009>Because if
we restrict the range of allowed characters to only Hangul Syllables(U+AC00 ~
U+D7A3), nomalization is not an issue for Korean IDN
anymore.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>Again,
allowing only Hangul Syllables in IDNA is
recommended.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>Thank
you.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>With
regards,</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN
class=996431108-25032009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=굴림><SPAN class=996431108-25032009>YungJin
Suh</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=굴림><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=굴림><SPAN
class=h1><STRONG></STRONG></SPAN></FONT></SPAN></FONT> </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><<A href="mailto:vint@google.com"
target=_blank>vint@google.com</A>></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. 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. </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> for determining PVALID
characters based on Unicode character properties</BLOCKQUOTE>
<DIV> </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> ASCII and case-insensitive matching
only) </BLOCKQUOTE>
<DIV>[no change from IDNA2003] </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> some of which are treated through contextual
rules (there is still ongoing discussion<BR> about the
implications of these choices)</BLOCKQUOTE>
<DIV><BR>This is also a current feature of the drafts, but not required by the
charter. 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. <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> </DIV>
<DIV>Just a comment (no change): IDNA2003 had the slightly different goal:
unassigned Unicode characters will not be returned from the DNS. </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 </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 (and thus no
impact<BR> on other protocols relying on Nameprep or
Stringprep.) </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> 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>
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> IDNA2003 posture that excluded only a few Unicode
characters) </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> (Definitions) </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> aid implementors, registries, registrants and users in
understanding IDNA.</BLOCKQUOTE>
<DIV> </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> </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> 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> <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> "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-- <LDH compliant
string>") 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. </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. 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> </DIV>
<DIV>=> "compatibility decomposable" characters of Unicode into their
counterparts</DIV>
<DIV>[Not all compatibility characters are decomposable and vice versa.]</DIV>
<DIV> </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> </DIV>
<DIV>This is not quite accurate; better would be to say "Unicode CaseFold maps
characters to 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. Under Unicode 5.0<BR>CaseFold
was unchanged for 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>=></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> </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. 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 is</BLOCKQUOTE>
<DIV>... with at least one non-LDH character... </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<u-umlaut>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<u-umlaut>cher" and
"b<u-umlaut>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> </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 "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> </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. 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> ab or<BR> 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>=> in 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> </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... </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" </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> </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. </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 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>