- From: Martin Duerst <duerst@it.aoyama.ac.jp>
- Date: Wed, 06 Jun 2007 15:19:24 +0900
- To: <gaaron@afilias.info>, <www-international@w3.org>, <public-i18n-core@w3.org>
[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:57 UTC