<html>
<body>
At 21:10 11/05/2008, John C Klensin wrote:<br>
<blockquote type=cite class=cite cite="">Of course, there is no such
requirement or restriction in either<br>
IDNA2003 or proposed for IDNA2008, nor are there strong<br>
guidelines that prohibit such registrations. Some serious<br>
confusion and/or FUD going on here.</blockquote><br>
Dear John,<br>
I do not know then how to read ICANN Guidelines :<br><br>
<blockquote type=cite class=cite cite="">1. Domain registries that
implement internationalized domain name capabilities<br>
at any level, including their own top-level designations, will do so in
strict<br>
compliance with the technical requirements described in RFCs 3454,<br>
3490, 3491, and 3492 (collectively, the "IDN
standards").</blockquote><br>
<blockquote type=cite class=cite cite="">2. In implementing the IDN
standards, domain registries will employ an<br>
"inclusion-based" approach (meaning that <b>code points which
are not explicitly<br>
permitted by the registry are prohibited</b>) for identifying permissible
sets of code<br>
points from among the full Unicode repertoire, as described below. A
registry<br>
may not even by exception permit code points that are prohibited by the
IDN<br>
standards.</blockquote><br>
<blockquote type=cite class=cite cite="">3. In implementing the IDN
standards, <b>domain registries will associate each label<br>
in a registered internationalized domain name, as it appears in their
registry, with<br>
a single script as defined by the block division of the Unicode code
chart.</b> A more<br>
specific association may be made by combining descriptors for both
language<br>
and script. Alternatively, a label may be associated with a set of
languages, or<br>
with more than one designator under the conditions described
below.</blockquote><br>
<blockquote type=cite class=cite cite="">3.1 A domain registry will
publish the aggregate set of code points that it<br>
makes available in clearly identified IDN-specific character tables, and
will<br>
define equivalent character variants if registration policies are
established<br>
on their basis. <b>Any such table will be designated in a manner
that<br>
indicates the script(s) and/or language(s) it is intended to
support.</b></blockquote><br>
<blockquote type=cite class=cite cite="">3.2 <b>All code points in a
single label will be taken from the same script as<br>
determined by the Unicode Standard Annex #24</b>: Script Names<br>
<<a href="http://www.unicode.org/reports/tr24" eudora="autourl">
<font color="#000081">http://www.unicode.org/reports/tr24</a>></font>.
Exceptions to this guideline are<br>
permissible for languages with established orthographies and
conventions<br>
that require the commingled use of multiple scripts. Even in the case
of<br>
this exception, visually confusable characters from different scripts
will not<br>
be allowed to co-exist in a single set of permissible codepoints unless
a<br>
corresponding policy and character table is clearly
defined.</blockquote><br>
".su" is just favoring a WSIS people centric vision of the
Internet over the network centric vision of the IETF. It seems that
currently 40 ccTLDs over more than 250 have signed an agreement with
ICANN. <br><br>
I do not think this creates any problem as long as users can filter in
the point-code they do not want to accept in their private environment
?<br>
jfc<br><br>
<br><br>
</body>
</html>