Comments on: Managing variants at the top-level http://blog.icann.org/2009/08/variations-on-a-theme-when-ae-becomes-%c3%a6/ Internet Corporation for Assigned Names and Numbers Wed, 08 Feb 2012 01:42:27 -0800 hourly 1 http://wordpress.org/?v=3.3.1 By: 电驴 http://blog.icann.org/2009/08/variations-on-a-theme-when-ae-becomes-%c3%a6/comment-page-1/#comment-19052 电驴 Wed, 09 Sep 2009 04:38:15 +0000 http://blog.icann.org/?p=1007#comment-19052 这一直都是ICANN的重要议题。 这一直都是ICANN的重要议题。

]]> By: Tina Dam http://blog.icann.org/2009/08/variations-on-a-theme-when-ae-becomes-%c3%a6/comment-page-1/#comment-18826 Tina Dam Tue, 25 Aug 2009 09:41:37 +0000 http://blog.icann.org/?p=1007#comment-18826 Hi David Cohen, you question is illustrating part of the problem. If we had such list that was agreeable for the entire community then i think the topic of variants would be much easier. However, different language communities have different opinions on whether a character is a variant and not. That can work fine at the second level, but when you move to the top level there need to be a more concise decision on this to avoid confusion and hence instability. The variant are defined/found via the IDN Tables. IDN Tables exists for some languages and some scripts, but not for all. IDN Tables are required as part of a Fast Track request or an IDN gTLD application. Depending on which characters are used in the requested/applied-for string, and whether these characters have variants, and which ones, we get a list of variant strings. Some of these variant strings are desirable for use and others are not. One of the reason for desired use is that users will either type in the requested/applied-for string or the desired-variant-string, not knowing which one they are actually typing nor understanding the difference between them. Hence in order for IDNs to be _really_ useful, in certain regions, there is a need for for these desired-variants to be delegated as well. However, as long as we dont know which strings we will get requests/applications for, and as long as we dont have the IDN Tables for all languages or scripts, this is adding to the complication of adding this to the top level. I dont think we will have any such list or anything close to it in the short term. I think we need to move forward and get some IDN TLDs in the root and then move from there. That can be considered as an unfair advantage to first-movers, however, we also cannot wait for all IDN Tables to be developed in the world, especially considering the changing nature of languages. Tina Hi David Cohen, you question is illustrating part of the problem. If we had such list that was agreeable for the entire community then i think the topic of variants would be much easier. However, different language communities have different opinions on whether a character is a variant and not. That can work fine at the second level, but when you move to the top level there need to be a more concise decision on this to avoid confusion and hence instability.

The variant are defined/found via the IDN Tables. IDN Tables exists for some languages and some scripts, but not for all. IDN Tables are required as part of a Fast Track request or an IDN gTLD application. Depending on which characters are used in the requested/applied-for string, and whether these characters have variants, and which ones, we get a list of variant strings. Some of these variant strings are desirable for use and others are not. One of the reason for desired use is that users will either type in the requested/applied-for string or the desired-variant-string, not knowing which one they are actually typing nor understanding the difference between them. Hence in order for IDNs to be _really_ useful, in certain regions, there is a need for for these desired-variants to be delegated as well.

However, as long as we dont know which strings we will get requests/applications for, and as long as we dont have the IDN Tables for all languages or scripts, this is adding to the complication of adding this to the top level.

I dont think we will have any such list or anything close to it in the short term. I think we need to move forward and get some IDN TLDs in the root and then move from there. That can be considered as an unfair advantage to first-movers, however, we also cannot wait for all IDN Tables to be developed in the world, especially considering the changing nature of languages.

Tina

]]> By: David Cohen http://blog.icann.org/2009/08/variations-on-a-theme-when-ae-becomes-%c3%a6/comment-page-1/#comment-18808 David Cohen Sun, 23 Aug 2009 18:11:10 +0000 http://blog.icann.org/?p=1007#comment-18808 Hi Tina, When can the community expect to see the blocked/reserved variant lists for idn gTLD's and ccTLD's? Will the idn fast track include any idn gTLD's? Hi Tina,
When can the community expect to see the blocked/reserved variant lists for idn gTLD’s and ccTLD’s?
Will the idn fast track include any idn gTLD’s?

]]> By: Dave Wrixon http://blog.icann.org/2009/08/variations-on-a-theme-when-ae-becomes-%c3%a6/comment-page-1/#comment-18807 Dave Wrixon Sun, 23 Aug 2009 18:08:33 +0000 http://blog.icann.org/?p=1007#comment-18807 Frankly, ICANN actually getting anything up and running would be an "Amazing Step". Frankly, ICANN actually getting anything up and running would be an “Amazing Step”.

]]>