Re: internationalized versions of domain name top-level labels

[I have revomed <member-i18n-core@w3.org> from the To: list.
There is no point in copying a private list if the discussion
is public and the public list of the same group is also copied.]


At 00:38 07/06/06, Greg Aaron wrote:
>FYI:
> 
>A major topic of discussion at ICANN is the introduction of $BE*(BDN TLDs$BH"(B -- internationalized versions of top-level domain (TLD) labels such as $BE(BCOM$BG
(B $BE(BNET$BG
(B $BE(BORG$BG
(B etc.  This means that in the future, a whole domain name $BK(Bboth to the left and the right of the last dot $BK(Bmay be internationalized.  (Currently only characters to the left of the dot may be internationalized.)  Imagine $BE(BCOM$BG(Brendered in and functional in many different scripts: Chinese, Devanagari, Japanese, Cyrillic, Tamil, etc. etc. 

I think that for ease of use (especially typing), introducing IDN TLDs
is crucial, and ICANN should speed up their work on this issue.

I think that overall, IDN ccTLDs (country code TLDs such as .jp, .fr,...)
are quite a bit easier to handle than IDN gTLDs (generic TLDs, i.e.
.com, .net, .org). The reasons are manyfold. The first one is that
in a first step, IDN ccTLDs should be used only for those country/script
combinations where that script is of major use (e.g. for an offical
language,...) in that country. As an example, it's quite important
that Marocco gets an Arabic TLD, and China gets a Han TLD, but a
Han TLD for Marocco or an Arabic TLD for China are way down on the
list of priorities.

In most cases, for ccTLDs, the same organization that manages the ASCII
TLD should also manage TLDs in other scripts. These organizations
could (but would not have to) adopt a policy of 'mirroring' and in
the long run transfering the second level domains in their ASCII TLD
into the new non-ASCII TLDs, for all of them or at least for those
second level domains in the corresponding script. In the long run,
while combinations of different scripts in different labels won't
necessarily die out nor should be forbidden, they will certainly
seriously decrease in usage.

Some consensus process is necessary among the countries that are the
main users of a script, to avoid problems. But delayed consensus on one
script should not delay consensus on another script.

It is very important to do this by script, not by language.
The first version of ICANN IDN guidelines had this totally
wrong, later versions seem to get better.


>This topic will have impact on applications. 

As far as I'm aware, modern browsers are ready to handle non-ASCII
TLDs. Some recent tightening of security might have changed that
a bit (some browsers use TLD whitelisting to exclude 'rogue' TLDs
that allow registration of mixed-script domain names that can lead
to spoofing).

The potential for spoofing on the TLD level can be kept very low,
because TLDs can be created on a one-by-one basis. As an example,
the most straightforward Cyrillic TLD for Russia looks like .py,
but that has to be ruled out because .py already exists.


>There are also policy issues, such as management of the various $BEW(Bersions$BG(Bof a TLD. 

There are definitely quite a lot of policy issues. The most difficult
part is to figure out who should manage the IDN gTLDs. For gTLDs,
I definitely think they should NOT be managed by the same entity
as the corresponding ASCII TLD.

Finding good short generic equivalents for things such as .com,
.org,... may not be easy. Once again, it's important that they
be provided on a per-script, not on a per-language basis.
In the same way as the Latin language served as a base for
abbreviations like .com and .org in Latin script, other scripts
likewise have a tradition of some coherence of terms or common
roots and loanwords across languages. For Arabic-script TLDs,
I'd assume roots would be created from widely used Arabic words/
stems, for Cyrillic script TLDs, I'd assume words/stems from
Russian/Slavic origin, and so on. For Han, this is even a bit
easier, as Han ideographs transmit meaning in a more direct
way, although one has to be careful to choose characters that
work across all relevant modern languages.

Another issue is the length of the TLDs. For Latin, it's
very easy: 2 letters for ccTLDs, 3 letters for traditional
gTLDs, 3 or more letters for newer gTLDs (such as .info).
Comming up with a similar scheme for other scripts may be
very helpful, but things have to be considered on a script-
by-script basis. As an example, Han may not need anything
more than 1-character TLDs, because there are so many Han
characters. Some other scripts may need a flexible length
to take into account the internal Unicode encoding (e.g.
diacritics, virama,...), even though on the outside, things
might look quite regular.



>This topic will be discussed at the upcoming ICANN meeting in San Juan, Puerto Rico on June 25-29, 2007.  There is currently work underway in ICANN committees and at the Internet Engineering Task Force (IETF). 
> 
>As part of the effort, ICANN has posted a set of draft procedures describing how IANA will manage the insertion, administration, and removal of internationalized top-level labels in the DNS root zone.

I hope very much ICANN is NOT thinking about removal.
Removing a domain name is a very bad thing, in clearest terms,
it's the cyberspace equivalent of killing somebody (or in the
case of TLDs, of potentially killing a lot of sites).



> ICANN$BCT(B announcement is at: 
>http://www.icann.org/announcements/announcement-02jun07.htm
>A public comment period is open until June 22, 2007.
> 
>ICANN has also published a new version of its IDN Guidelines, which for the first time makes specific reference to IDN in top-level labels. It is anticipated to be amended and supplemented in subsequent drafts in preparation for the release of internationalized top-level labels in the production environment.  This document is currently open to public comment:
>http://www.icann.org/announcements/announcement-2-11may07.htm

Many thanks for this information. I'll certainly try to send in my comments.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

Received on Wednesday, 6 June 2007 06:19:54 UTC