<font class="Apple-style-span" face="georgia, serif">I agree with John; there are millions of registries, not just hundreds.</font><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">====<br>
</font><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">In terms of Patrik's proposed disposition, I agree 2/3 with him. There are two distinct issues.</font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div><b><font class="Apple-style-span" face="georgia, serif">1) DISALLOWED => PVALID</font></b></div>
<div><b><font class="Apple-style-span" face="georgia, serif"><br></font></b></div></span><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div>
<b><font class="Apple-style-span" face="georgia, serif">U+0CF1 KANNADA SIGN JIHVAMULIYA</font></b></div></span><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div><b><font class="Apple-style-span" face="georgia, serif">U+0CF2 KANNADA SIGN UPADHMANIYA</font></b></div>
</span></blockquote><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">These don't cause any problem. With each new version of Unicode, this happens with thousands of characters; all the new ones. Having IDNA2008 just follow Unicode is the right thing to do.</font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><b><font class="Apple-style-span" face="georgia, serif">2) PVALID => </font></b><b><font class="Apple-style-span" face="georgia, serif">DISALLOWED</font></b></div>
<div><b><font class="Apple-style-span" face="georgia, serif"><br></font></b></div></span><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div>
<b><font class="Apple-style-span" face="georgia, serif">U+19DA NEW TAI LUE THAM DIGIT ONE</font></b></div></span></blockquote><span class="Apple-style-span" style="font-size: 13px; border-collapse: collapse; "><div><b><span class="Apple-style-span" style="font-weight: normal; "><font class="Apple-style-span" face="georgia, serif"><br>
</font></span></b></div><div><font class="Apple-style-span" face="georgia, serif">Patrik mentioned having a 'bug' in Unicode show up in IDNA2008. But what qualifies as a bug depends on the usage. It was a bug in the Unicode properties that the </font><span class="Apple-style-span" style="font-size: x-small; "><font class="Apple-style-span" face="georgia, serif">NEW TAI LUE THAM DIGIT ONE</font></span><font class="Apple-style-span" face="georgia, serif"> was categorized as a decimal number. For general usage, that is indeed a significant bug, and needed to be fixed. But the world of identifiers (including IDNA2008) is much much narrower. Would it be a significant bug to have it be grandfathered in domain names? If someone has an </font><span style="font-size: x-small; border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif">NEW TAI LUE THAM DIGIT ONE</font></span><font class="Apple-style-span" face="georgia, serif"> in a domain name does that cause any real problem?</font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">My answer is </font><i><font class="Apple-style-span" face="georgia, serif">no</font></i><font class="Apple-style-span" face="georgia, serif">. It will not cause any problems in domain names, no more than the average character that is already allowed in domain names (such as the many historic characters). The choice of exactly which characters are in domain names is, as we all know, somewhat fuzzy. The decision to generally disallow non-decimal numbers in domain names (</font><a href="http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:no:][:nl:]%26[:isnfkc:]&g=sc" target="_blank" style="color: rgb(17, 65, 112); "><font class="Apple-style-span" face="georgia, serif">http://unicode.org/cldr/utility/list-unicodeset.jsp?a=[:no:][:nl:]%26[:isnfkc:]&g=sc</font></a><font class="Apple-style-span" face="georgia, serif">) is perfectly reasonable, but it doesn't hurt to leave one of them (</font><span style="font-size: x-small; border-collapse: collapse; "><font class="Apple-style-span" face="georgia, serif">NEW TAI LUE THAM DIGIT ONE</font></span><font class="Apple-style-span" face="georgia, serif">) in via Clause G, in order to preserve stability.</font></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">The stability of domain names is far more important -- that <i>once a domain name is valid, that it remain so</i>. We know that there is a significant break before and after Aug 2010, but that should be the last such break. And we have the mechanism in Clause G to to guarantee that, if there is the will to do so.</font></div>
</span><div><div><font class="Apple-style-span" face="georgia, serif"><br clear="all">Mark<br><br></font><i><font class="Apple-style-span" face="georgia, serif">— Il meglio è l’inimico del bene —</font></i><font class="Apple-style-span" face="georgia, serif"><br>
<br><br></font>
<div class="gmail_quote"><font class="Apple-style-span" face="georgia, serif">2010/10/14 John C Klensin </font><span dir="ltr"><font class="Apple-style-span" face="georgia, serif"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></font></span><font class="Apple-style-span" face="georgia, serif"><br>
</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font class="Apple-style-span" face="georgia, serif"><br><br>
--On Thursday, October 14, 2010 13:22 -0700 Tina Dam<br></font>
<div class="im"><font class="Apple-style-span" face="georgia, serif"><</font><a href="mailto:tina.dam@icann.org"><font class="Apple-style-span" face="georgia, serif">tina.dam@icann.org</font></a><font class="Apple-style-span" face="georgia, serif">> wrote:<br>
<br>
> Hi Patrick, thanks for this. It was sooner than I expected...<br>
><br>
> In terms of the forward progress, I agree with your<br>
> recommendation for the specific example. Generally I think in<br>
> order to choose between the options (accept change or add<br>
> exception for backward compatibility) I would personally like<br>
> to hear from registries that have implemented the character<br>
> and who may be disadvantaged by it's elimination.<br><br></font>
</div><font class="Apple-style-span" face="georgia, serif">Tina, I know you know this but, just as it is sometimes easy to<br>
lose sight of the fact that the DNS is not just about "web<br>
addresses", it is sometimes easy to lose track of the depth and<br>
extent of the tree. The meaning of "registry" in IDNA2008 (and<br>
similar terminology in IDNA2003) extends to every zone<br>
administrator of a zone in the DNS. In principle, the<br>
administrator of a subdomain somewhere deep in the DNS tree<br>
could have chosen to utilize one or more of these characters<br>
without having to discuss that decision with anyone else.<br><br>
While I believe that the probability of that having occurred is<br>
actually very low, any sort of decision process associated with<br>
"ask the registries" or "hear from the registries" has most of<br>
the properties of a search for a universal negative: if someone<br>
comes forward and says "yes, I am using one of those" it gives<br>
us a lot of information but that absence of such an answer tells<br>
us almost nothing... and, in this day of restrictions on zone<br>
transfers, there is no feasible way to walk the entire tree.<br></font>
<div class="im"><font class="Apple-style-span" face="georgia, serif"><br>
> For this specific case, I am personally unaware of any IDNs<br>
> with the New Tai Lue script. However, we should probably make<br>
> some sort of process where the gTLD registries and ccTLD<br>
> registries are asked to provide relevant input if/when this<br>
> happens again.<br><br></font>
</div><font class="Apple-style-span" face="georgia, serif">While I think some mechanism of that sort would be a good idea,<br>
we also need to remember that, while many people are thinking<br>
about IDN TLDs in terms of script-homogeneous or<br>
language-homogeneous trees and FQDNs, there is, in general, no<br>
plausible way to enforce such requirements. Even if one could<br>
do that for IDN TLDs and their subtrees, it is not possible for<br>
subtrees of existing, non-IDN, TLDs.<br><br>
best,<br></font>
<font color="#888888"><font class="Apple-style-span" face="georgia, serif"> john<br></font>
</font><div><div></div><div class="h5"><font class="Apple-style-span" face="georgia, serif"><br>
_______________________________________________<br>
Idna-update mailing list<br></font>
<a href="mailto:Idna-update@alvestrand.no"><font class="Apple-style-span" face="georgia, serif">Idna-update@alvestrand.no</font></a><font class="Apple-style-span" face="georgia, serif"><br></font>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank"><font class="Apple-style-span" face="georgia, serif">http://www.alvestrand.no/mailman/listinfo/idna-update</font></a><font class="Apple-style-span" face="georgia, serif"><br>
</font>
</div></div></blockquote></div><br></div></div></div>