Discussion Paper on Non-ASCII TLD Policy Issues

Summary of Public Feedback

I.    GEOGRAPHIC UNITS


Response from Jeffrey J. Neuman, Esq., Director, Law & Policy, NeuStar, Inc.

General comments on this topic.

NeuStar agrees wholeheartedly with your assessment that local ccTLD communities (including the relevant national government under which the ccTLD operates) should be responsible for the delegation and associated policies with respect to the rollout of multilingual domain names within a particular ccTLD jurisdiction. We believe it is the responsibility of the particular ccTLD manager, in cooperation with its national government, to determine whether there is support within the local Internet community for the introduction of a non-ASCII version of the geographic TLD.

Unfortunately, we do not believe that there are any objective criteria that can be established to determine whether support exists for a non-ASCII TLD in a geographic unit. That being said, however, we believe that support from the national government under which the ccTLD operates, should qualify for such a demonstration of support. If the national government supports the addition of a non-ASCII TLD in that nation's ccTLD, we do not believe that IANA or ICANN should be in a position to block such introduction.

Absent the express support of the national governments, we believe that ccTLD managers should work with the ICANN to develop criteria to determine community support.


Response from Kilnam Chon

General comments on this topic.

This could be a tricky issue, and I don't recommend ICANN to get involved in this issue as IANA avoided by referring to ISO 3166 in 1980s.  Let ISO and other international organizations to come up with the standard.

Once we could come up with the naming list, then the rest could be handled similarly to ccTLDs in ASCII.


Current ICANN/IANA policy permits the delegation of ASCII ccTLDs only when a given geographic unit and its associated codes appear on the ISO 3166-1 list.  The ISO-3166-1 list defines not only recognized countries and territories, but also the specific 2-letter ASCII codes associated with each.  No such authoritative list exists to define country/territory names in non-ASCII characters, leaving ICANN without a given reference point.  How should this problem be handled?  Should it be left to each proposer to identify the desired TLD string and to justify it?  If so, what criteria should be applied to evaluate the proposed string's suitability for (and acceptability to) the given geographic unit?  If not, to what neutral and authoritative arbiter should this problem be referred?


Response from Cord Wischhöfer (ISO 3166/MA Secretariat)

Below I quote parts of that question and try to give some input on these parts:
 
Current ICANN/IANA policy permits the delegation of ASCII ccTLDs only when a given geographic unit and its associated codes appear on the ISO 3166-1 list.  The ISO-3166-1 list defines not only recognized countries and territories, but also the specific 2-letter ASCII codes associated with each.
 
The ISO 3166/MA Secretariat appreciates ICANN's attitude of using no other two-letter codes than those from the official list of ISO 3166-1 in the DNS. Whether ICANN also uses the exact name forms of the English country names given in ISO 3166-1 is not known to me. I presume that certain spelling differences between the two lists may exist. One would have to check this.
 
No such authoritative list exists to define country/territory names in non-ASCII characters, leaving ICANN without a given reference point. How should this problem be handled?
 
It is correct to say that ISO 3166-1 only exists in English and French. But the statement needs some qualification since in its absoluteness it is not quite correct.
 
One of the two United Nations sources of the names in ISO 3166-1 is the UN Terminology Bulletin "Country Names" (1) which lists about 180 country names in the six official languages of the UN: English, French, Spanish, Russian, Arabic and Chinese. This document could well serve as a reference basis for authoritative input into a possible future list of non-ASCII country/territory names for Russian, Arab and Chinese name forms. For those entities not listed in the UN Terminology Bulletin -- 99 percent of those not listed are dependent territories -- another solution would have to be found.
 
Then, there is what we standardizers call "national adoptions" of ISO standards. Each national standards organization that is a member of ISO may adopt ISO standards nationally. By this process the ISO standard becomes a national standard recognized in the country. Very often this adoption entails the translation of the English version into the national language. ISO 3166-1 being a popular standard I am convinced that at least in some of the bigger countries who write in non Latin scripts there are translations into the national language and script (2). These national versions of ISO 3166-1 are identical to ISO 3166-1 as far as the content - and thus the list of names - is concerned.
 
The translations being made in the countries themselves, the acceptance of such non-ASCII script versions of ISO 3166-1 by the user-community in that country may be taken for granted. So using the official translation of ISO 3166-1 produced by the national ISO member organization would provide answers to the questions:

Should it be left to each proposer to identify the desired TLD string and to justify it?

No. Use national versions of ISO 3166-1.
 
If so, what criteria should be applied to evaluate the proposed string's suitability for (and acceptability to) the given geographic unit?

If the geographic unit figures in ISO 3166-1 and in the national standard then its name should be acceptable to users in that country.
 
If not, to what neutral and authoritative arbiter should this problem be referred?

If conflicts arise, the best authority for deciding what a country's name is in the country's script is usually the national government. Here the ICANN Governmental Advisory Committee can certainly be of assistance in establishing contacts with the national government concerned.
 
In going this way ICANN can avoid many of the difficulties it faces with NAMES of countries using non-ASCII scripts. The problem of the TWO-LETTER CODES or ABBREVIATIONS cannot be solved in this way because to my knowledge all national versions of ISO 3166-1 give the same code elements in ASCII characters. (3)
 
However, in my opinion, the non-ASCII CODES present a smaller problem than the NAMES. The development of codes does not involve the same amount of political considerations necessary when dealing with country names. Much rather this work might focus on technical questions of how to map country names to codes or abbreviations in non-ASCII scripts.
 
Work on this second part of the task (the non-ASCII codes) could:

a) be initiated by those Internet users in the respective countries that take a particular interest in the topic; and
b) be done in an appropriate national standards committee.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

This issue should be addresses by appropriate “local” bodies or consortia, if any exist, that specialize in each geographical location’s needs for ccTLDs in the various languages that the geographical area is known for. For example, in the case of Arabic Character languages (including Arabic, Farsi, Urdu, Kurdish, … etc), there is AINC (Arabic Internet Names Consortium) which is tackling these issues and currently making excellent progress. Representatives from ICANN attended meetings including the latest meeting in Tunisia in April 15-17, 2002 and found AINC to be a viable body for making decisions related to Arabic ccTLDs. ICANN would take input from AINC and work with it to adopt its recommendations. Members of AINC include all 22 Arab governments, the Arab League in a group representing the various Arabic-speaking geographical entities, academic and technical institutions, businesses and individuals with expertise in such matters as selection Arabic strings denoting ccTLDs for the geographical entities within AINC using Arabic script.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

Again, this is an unnecessary consideration. The current SLD and 3LD system offers no such requirement by registries or registrars. Some ccTLDs implement SLD conventions
which mirror the gTLDs but as autonomous agencies, they are free to decide for themselves the suitability of the conventions they use. If so, why should this apply to
non-ASCII TLDs?

Even if a set of criteria could be achieved, how can an entity such as the ICANN acquire the full set of language and script competence to evaluate. All this is unnecessary
red tape which ICANN should not even go near.

For each language/script namespace, perform a reasonable delegation with dispute processes and let the delegated authority decide what they want to do with their namespace.

For example, if INFITT is the only international organization that is able to demonstrate some degree of competence, let the delegation take place, whereupon it is up to INFITT to sort it out amongst the Tamil speaking community how they would want their Tamil namespace to look like. If it doesn't work, it is the responsibility of the self-governing authority to fix the problem because the delegation has been performed. Why should ICANN bear the responsibility and play God to all the languages of the world? It is an unnecessary headache that does not scale at all.

Should another competing entity emerge that challenges the authority of INFITT, a few simple basic rules can be instituted for dispute resolution along the lines of UDRP
and let the precedence of case history evolve the rules of engagement.


Response from Hiro Hotta

Appointing a delegate for a non-ASCII ccTLD is more difficult than for an ASCII ccTLD. Considering the difficulty we are experiencing in formally defining the ccTLD delegate, it is realistic that ICANN appoints the current delegate for an ASCII ccTLD as a delegate for the corresponding non-ASCII ccTLD in order to achieve the delegation formation efficiently enough.


Response from Peter Constable, SIL International

An additional consideration / concern in relation to ISO3166-1 is that these codes are, unfortunately, not as stable as many would prefer.


Current ICANN/IANA policy requires proposers for new ASCII ccTLDs to demonstrate support from the local Internet community.  How can this requirement be objectively evaluated in the case of a proposed non-ASCII TLD semantically associated with a recognized geographic unit?  What indicators of support should be expected or required?


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

Similarly to the previous issue, if recognized bodies with fair rules recognized by ICANN are specialized in the issues of ccTLD selection and adoption facing local geographical entities exists, ICANN should consider the adoption of the recommended ccTLDs once support within all the geographical entities represented by that body is demonstrated. Such demonstration may come in the form of official adoption by that body which may be composed of governmental, academic and business members with fair rules for selection and representation. Again, in the case of Arabic ccTLDs, AINC has a parallel process similar to ICANN in selecting the appropriate ccTLDs and can demonstrate the support of their recommendation.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

By treating non-ASCII TLDs as an extension of ASCII, ICANN/IANA is now lumbered with the problem if trying to evaluate proposers of new ccTLDs. ICANN should recognize that this is a domain that it doesn't want to get into, it doesn't have the capability of successfully scaling up to handle the diversity of languages, nor does it have
the competence to objectively evaluate the various languages.

ICANN should treat non-ASCII TLDs as separate name spaces to be handled by the appropriate and competent party, and devolve that responsibility. Even in the case of the
Multilingual Internet Names Consortium, when key service providers of multilingual domain names congregate, where it is most likely a place with multilingual expertise may
be found, MINC has seen fit to delegate responsibility to competent parties, e.g. Tamil language/script to INFITT and to effect mutual recognition memoranda of understanding.

In the case of Tamil language and script, the situation is fairly simple and bodies such as the INFITT comprising Tamil speaking IT professionals are capable of independently and autonomously handling the namespace issues and should be delegated this responsibility of evaluation. All that has to be done at the level of bodies such as MINC and ICANN is coordination that the name space occupied does not interfere or cause problems for other namespaces.


Response from Hiro Hotta

If the current ASCII ccTLD delegate is appointed as a delegate of the corresponding non-ASCII ccTLD, the appointment can reflect the local Internet community's interest at least with the same degree as in the case of the current ASCII ccTLD.


What role, if any, should be played by the manager of the existing ASCII ccTLD for that geographic unit?


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

The role may be a “liaison” and overseeing one. Otherwise the full responsibility for string selection, demonstrating objective support for the recommendations is the responsibility of the local body that specializes in the geographical entities in question. If no such body exists, the manager for the existing ASCII ccTLD may play a greater role in inviting governmental and other institutions in forming an appropriate body. In the case of Arabic Character scripts (such as Arabic, Farsi and Urdu), AINC already exists and have full responsibility & authority by all Arab Governments.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

The existing ASCII ccTLD belongs to a separate namespace. By treating non-ASCII domain names as an extension of ASCII ccTLD, this question automatically arises. Equation of ASCII ccTLD with non-ASCII ccTLD will cause unnecessary problems.
Why shouldn't it be a simple equation? For example, the ccTLD manager of .in would probably want to have nothing to do managing the delegation of the hundreds of languages in India if he were asked to handle .in for India in these languages.
It could be a highly dangerous task in view of the political sensitivities involved.

For one, he has no knowledge of these languages which in many cases are totally alien to him. Tamil ccTLDs would have meaning only in the context of the language user. This
question is based on an assumption born of a lack of understanding of the language issues, and immediately shows that a high degree of awareness of the situation at hand is required, and that ICANN may not the appropriate platform for clear and productive discussion in such matters. Unnecessary non-issues and red-herrings created accidentally merely confuse rather than enlighten.

In the case of Tamil TLDs, let the organizations such as INFITT deal with these issues. If a ccTLD happens to map to a language TLD, then it is a coincidence. In many cases, minority language users are not well taken care of in countries with majority ethnic groups. If ICANN were to naively map ccTLDs to language TLDs, the situation can be politically explosive.  It is therefore not advisable that ICANN should venture into arenas in which it is out of its depth.


Response from Hiro Hotta

It is favorable the current ASCII ccTLD delegate is appointed as a delegate of the corresponding non-ASCII ccTLD. 


What role, if any, should be played by governments in the selection of non-ASCII TLDs associated with its country/territory?


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

If governments of a set of geographical entities are already part of a recognized body whose task is the selection and adoption of non-ASCII ccTLDs, then they are already playing a role. This is the case, for example for Arab governments and AINC (Arabic Internet Names Consortium). Otherwise, government must play a role in official support of the recommendation of whatever body selected the non-ASCII ccTLDs. Special departments within a government would take part in the recommendation.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

The history of the Internet should be fairly instructive here. Jon Postel issued delegations to country responsible persons. These people held in trust a responsibility which when governments were ready to come in and manage, were transferred amicably or otherwise to the appropriate governmental authority. That was how the Internet could grow so rapidly, by keeping the processes simple and straightforward. Eventually, these individuals will hand over the control to responsible bodies. History has shown that this is the case, and will continue to be the case as the Internet grows and matures in a particular geographical region. To put the cart before the horse will seriously cause hindrance to the growth of non-ASCII domain names as an Internet leveler of the playing field. All that needs to be done is to implement a dispute resolution policy that handles any dispute surrounding the transition or abuse of the responsibility, which can be easily dealt with in any arbitration process or the courts of law.


Response from Hiro Hotta

It is the role of the government to support the formation of the relationship among the local Internet community, ccTLD Sponsoring Organizations, and ICANN.


II.    LANGUAGES


Response from Kilnam Chon

General comments on this topic.
 
Please refer ISO Standards(639) for 2-letter and 3-letter language code,which was similarly developed to ISO 3166 for the country code.

The language code in local languages could impose very difficult problems as we are finding out in Chinese and Korean.  There may be more problems in other languages, too.

The language communities across sovereign national boundaries such as Tamiland Kurdish among others would impose tough problems to resolve, and ICANN is not well-suited to resolve those kinds of disputes as mentioned in the discussion paper.


Is there any recognized, authoritative reference list of languages (analogous to ISO 3166-1) that could be employed as a reference against which to judge proposals for language-associated non-ASCII TLDs?


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

ISO 639 (see also the author’s response in the General Comments section)


Response from Cord Wischhöfer (ISO 3166/MA Secretary)

Yes, there is a source with the same acceptance and reliability as ISO 3166-1. It is the International Standard ISO 639. It comes in two parts.

ISO 639:1988 Code for the representation of names of languages
ISO 639-2:1988 Codes for the representation of names of languages -- Part 2: Alpha-3 code
 
ISO 639 specifies a two-letter code identifying languages. This standard is presently under revision and will be published later this summer as ISO 639-1.
 
ISO 639-2 specifies a three-letter code identifying languages.
Both standards are updated by Registration Authorities -- an ISO office similar to the Maintenance Agencies. Code lists of both these language code standards are available on the WWW.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

This is best addressed by local policy and standards bodies from specific geographical entities. For e.g. AINC (Arabic Internet Names Consortium) can define the languages that use Arabic as a script (e.g. Arabic, Farsi, Urdu). AINC Executive Director is already coordinating with ISO to find an Arabic equivalent for the current ISO 3166-1 to be implemented for the Arabic Domains as part of the IDN process.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

ISO Standards (639) for 2-letter and 3-letter language code, which were similarly developed in ISO 3166 for the country code. However, these language codes are not even close to exhaustive.

The SIL International <http://www.sil.org/> provides a comprehensive catalogue of over 6,800 languages and a three letter language identifier code. But the IDN committee's statement below is apparently a non sequitur.
 
"There does not appear to be a recognized list of all human languages analogous to the ISO-3166-1 table."

Even if there were a list of languages, and indeed the SIL Ethnologue has a comprehensive if not near exhaustive list of languages, the codes are in ASCII. This certainly does not help the process of benchmarking non-ASCII script against each language, which is the thrust of the issue of TLDs based on semantic association
with language. Even if a language group were to find it useful to have a TLD that states their language in their script, which is essentially tautological, these are only required under special circumstances. In the Tamil language, since no other language uses
the Tamil script, there is absolutely no need for TLDs based on semantic association with language.

Wouldn't it be better to have these language tags at the internal representation layer, rather than the visible layer?

The only situation where it might be useful to have language tags in the same script is where more than one language uses a particular script.

For example, let NIHON represent the pictographic characters of the name "Japan" in Kanji and RIBEN represent the pictographic characters of "Japan" in Chinese. These characters look alike. At the Unicode level, they are the same. A CJK expert should easily be able to verify this. In this circumstance, NIHON.KANJI with the language KANJI TLD, versus RIBEN.HUAWEN or RIBEN.ZHONGWEN where HUAWEN or ZHONGWEN is the language semantic equivalent would help distinguish NIHON from RIBEN since their characters look very much alike if not identical.

So in Singapore where I come from, Chinese is an official language, and for us, the NIHON=RIBEN characters, which look identical would be obviously Chinese language without the necessity for a language semantic TLD. In Japan, it would be obvious it represented Japanese Kanji. In China, it would be clear it is the word "Japan" in Chinese. However elsewhere, where Japanese and Chinese are equally common, there might be contextual ambiguity which might necessitate a language tag.

Again, these tags are unnecessary most of the time because TLDs do not occur in isolation in their visible state. They occur with SLDs, and 3LDs, where such coincidences are rare, and the SLDs and 3LDs will provide the necessary contextual information for users to decipher if it is Chinese language usage of the NIHON=RIBEN characters, or the Japanese Kanji usage.

Therefore, this non-issue is again best left to each language/script group to sort it out. One size doesn't fit all, and any attempt to do so by ICANN will lead it down a slippery of
controversy and more chaos if it attempts to pursue this kind of non-issue.


Response from Hiro Hotta

No such list is known to me.


Response from Peter Constable, SIL International

Depends upon what is meant by "recognized". Several agencies have adopted the Ethnologue list for similar purposes (cf. <www.ethnologue.com>). There are some identifier conflicts with ISO 639-2, which could certainly lead to confusion, though. But the committee should be aware that ISO/TC 37/SC 2 has initiated a process that is intended to lead to extension of the ISO 639 family of standards, and one of the intents is to provide a comprehensive list of identifiers comparable to that provided by the Ethnologue.


The relevant community of interest for a given language is the set of all speakers of that language.  Is it likewise correct that the relevant community to be served by a given language-associated non-ASCII TLD would be the set of all speakers of the languages that utilize the characters that comprise the proposed language-associated non-ASCII TLD string?  If not, how should ICANN define the community to be served by the manager of a language-associated TLD?


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

Some languages are represented in more than one script, partly over
time and partly based on geographical area. There are very many political "conflicts/problems" relating to languages spreading across borders, "oppressed linguistic minorities", etc. Language and culture are very closely connected. Language-related TLDs may be to a great cultural benefit to many groups, and also be a source of political conflict, "separatism" (which may be desired and undesired), etc. I should think (although I haven't asked) that e.g. Basque groups would be happy to have a TLD that is neither .es nor .fr. This isn't only (or to a great degree) dependent on the question of non-ASCII TLDs, but rather on "language-related" TLDs.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

Consistent with our previous comments, this is the responsibility of local bodies of each (group of) geographical entity(ies). Such bodies must address this issue as part of their activities and selection of TLDs. In Arabic for example, AINC defines the countries in question and coordinates efforts and research with all its authorities to reach a unified agreed upon standard.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

Again this question is borne out of inexperience with the multiplicity of languages and their current situation, which is another reason why ICANN should keep out of the arena of non-ASCII TLDs.

It confuses script with languages. More than one language can use a particular script. It is obvious if one takes the example of the ASCII script. If we take .melayu as the language-associated TLD as an example for the Malay language which uses the ASCII character set (where Melayu is "Malay" in Malay and it is an official language in my country too!)

Let's rephrase the question:

Is it likewise correct that the relevant [Malay global] community, served by the given language-associated TLD [.melayu] is the set of all speakers of the languages that utilize the characters that comprise the proposed language associated TLD string, in this case .melayu?

It is immediately obvious that the statement is fallacious in the case of multiple languages that use the same or subsets of the same script.

But how would a non-native English speaker be able to de-convolute such a convoluted question merely points to the fact that ICANN should not be involved in this space. That this question was so constructed underscores the lack of competence of ICANN IDN WG in handling such issues.

In case people who read this are still wondering, let me rephrase again:

All speakers of the languages that utilize the characters m, e, l, a, y, u in ".melayu"
include all groups that use the ASCII character set, the English, the Americans, the Hawaiians, the Indonesians, etc. But the French and the Germans also use these characters, so do they also belong to that relevant community served by .melayu, being the set of all speakers of the languages English, American, Hawaiian, Indonesian, French and German etc that utilize the characters that comprise the language associated TLD string, .melayu? Of course not.

If this question was meant to confuse, it has certainly most successfully achieved the effect.


Response from Hiro Hotta

Not accurate. The word "speakers" should be changed to "users."


Response from Peter Constable, SIL International

Yes, though there is an additional complication to be aware of: they are talking in terms non-ASCII TLDs corresponding to languages, yet many of the world's languages are written by subsets of the overall language community using different scripts. It will most generally be true that a given person will be familiar with only one of these ways of writing the language (though certainly not always, especially when transitions between one or the other are occurring). Thus, whereas they are talking of TLDs corresponding to languages, strictly speaking it probably should be TLDs that correspond to different writing systems (where a writing system = a particular system for writing a particular language, roughly language x script).

Note: the very useful glossary by Paul Hoffman referenced in the doc has a small but, I think, significant weakness in that it fails to include the notion of writing system. The distinction between language and script cannot be properly understood, I think, apart from the intervening notion of writing system. (Some use orthography for the notion I am describing as "writing system", which is good in that it makes the important distinction missing in the TLD doc, though I think there is yet another distinction of interest for general IT purposes that can reasonably be called "orthography".)



Is it correct that a non-ASCII TLD semantically associated with the name of a language is essentially redundant, given that the domain is by its very nature an expression of that language?


Response from Kilnam Chon

The answer depends on the language community; yes in the case of Japanese, but no in the case of Arabic, Kurdish, Tamil, ... Korean is half way between yes and no.


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

I don't quite understand this question. Would the owner and user of a site "www.a-word-in-Basque.es" be more happy with "www.a-word-in-Basque.euskera" or "www.a-word-in-Basque.eu" or "www.a-word-in-Basque.lang-eu" or something? And would the owner and user of "www.a-word-in-?????-Hindi.in" prefer "www.a-word-in-?????-Hindi.??" or "www.a-word-in-?????-Hindi.?????" or something? I am certain that "your own name" of your language is a strong identity factor, and that language-based TLDs is of interest to some, and that non-ASCII language TLDs works even stronger in this respect. However, I should think that the inclusion of language-name-based TLDs would be more important than non-ASCII TLDs.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

Yes, it is definitely redundant. Furthermore, there is no “classification” of domains except at the second-level. This is limiting and results in a huge single domain for all domain names in a particular language. The best recommendation would include ccTLDs for each language, as well as gTLDs, all using non-ASCII characters.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

As (previously) explained, in the Tamil situation, it is essentially redundant. In the case of the Han characters used by the Chinese, Japanese and Korean (CJK) it may be useful depending on how the CJK peoples decide amongst themselves because of their code space collision, i.e. NIHON = RIBEN occurring in the same Unicode point. So one cannot ask this question across the board as if the differences amongst the way language maps to script did not exist.

Since one size doesn't fit all, either ICANN wants to maintain all the possible permutations and combinations, or else, have a simple workable policy of giving up control by delegation to the relevant authority and let them handle these issues.

If ICANN still wants to have control beyond this level, then, it should play the coordination role of arbitrating or facilitating the interaction of language groups that might
share the Unicode points in their languages, or have glyphs that look similar to each others languages. But groups such as MINC already exist. So the wheel should not be re-invented.


Response from Hiro Hotta

Not correct. As multiple languages may share the same characters, non-ASCII domain labels solely cannot identify the language they are from. In addition, a domain label may have multiple meanings according to the languages it may belong to.

Response from Peter Constable, SIL International

Not in general. In some cases, there may not be significant ambiguity for a majority of users; e.g. the likelihood of someone mistaking the string "brother" as being Navajo / Indonesian / whatever rather than English is pretty slim. But the statement cannot be generalized. A single string can be used in different languages with different meanings. Thus a TLD of "chat" wouldn't determine a particular language. Also, for some strings with a particular semantic, particularly proper names, might not inherently
belong to any single language. Consider that many TLDs involve names of businesses that would be invariant from language to language (e.g. IBM goes by "IBM" universally, even if a local office happened to provide content in one language only).


Languages are often spoken across territorial boundaries and under different and sometimes hostile governments, making the usual requirement of community consensus extremely difficult to establish or document.  Given the near-impossibility of demonstrating, for example, a consensus among all the worldwide Internet communities consisting of Arabic speakers, should this category simply be excluded as a matter of policy pragmatism?  If not, how could "consensus" across many territorial boundaries be objectively demonstrated?


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

It would be very simple just to accept this argument. However, there are also minority groups and cross-border groups around the world that are well taken care of, that are recognized by "central" authorities, and that do have a genuine need to struggle to maintain their cultural identity. It would be a pity if such groups were to be "denied" their language-based TLDs because other groups are living less peacefully next to each other. If language-based TLDs are based on ISO 639, the "political" issues are moved to a different place, and consensus-building would be within the domain of ISO.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

The existence of a body, such as AINC (Arabic Internet Names Consortium) which already involves governments as well as other technical & linguistic institutions representing Arabic speakers, and which uses voting rules and other recognized objective criteria for analysis and selection is an objective proof of “consensus”. ICANN should not decide these matters for others, of course. It should coordinate and take recommendations from each local body that specializes in a set of geographical entities and its corresponding language(s). Arabic so far is being well served by AINC and the Arab consumer is well represented in international bodies.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.


To the degree and in the same way ICANN achieves "consensus" across many territorial boundaries which it claims to be objectively demonstrated, that "consensus" amongst Arabic script users, which stretch across the Arabic speakers, the Urdu speakers, the Farsi speakers etc, across many territorial boundaries, may be achieved. So in the case
of Tamil, the INFITT stretches across territorial boundaries and achieves the rough consensus it needs to come to grips with Tamil font standardization, which is not easy but
nevertheless achievable, sufficient for the organization to go forward. INFITT can objectively demonstrate the rough consensus that is needed to be able to move forward
in the administration and management and governance of Tamil domain names if the responsibility is delegated to it.

Should any other language groups start to use Tamil script, the best entity that can coordinate is probably MINC, the Multilingual Internet Names Consortium, which has
the track record of spawning off groups in the Arabic, Urdu, Tamil, CJK language/script communities and maintaining coordination amongst them.


Response from Hiro Hotta

It is thought to be realistic that, through open procedures, such TLDs that have got consensus about the language definitions can only be adopted as language TLDs. An example of such procedure is:

1) ICANN or another organization keeps a list of the language definitions for language TLDs.
2) Someone registers a language definition for the language TLD.
3) If no objection comes within a reasonable period (for example 3 months), the language definition becomes the formal definition for the language TLD. The language TLD can be served with the definition.
4) If some objection comes, coordination must be made to get consensus. Until consensus has been made, the language TLD cannot be served.


Response from Peter Constable, SIL International

Language communities cross sovereign national boundaries.  The problem of identifying and achieving consensus among the stakeholders of a given set of language communities may be extremely difficult.  ICANN/IANA might be left with competing claims backed by different stakeholders, or, worse, different national governments. ICANN/IANA is not well-suited to resolve those kinds of disputes.                



What role, if any, should by played by governments in the selection of non-ASCII TLDs semantically associated with languages?


Response from Kilnam Chon

This is another tough problem, in particular on the languages (character) being used among multiple countries.


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

As pointed out above, there may be great advantages using the mechanisms of ISO and ISO/TC37 (ISO 639).


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

The existence of a body, such as AINC (Arabic Internet Names Consortium) which already involves governments as well as other technical & linguistic institutions representing Arabic speakers, and which uses voting rules and other recognized objective criteria for analysis and selection is an objective proof of “consensus”. ICANN should not decide these matters for others, of course. It should coordinate and take recommendations from each local body that specializes in a set of geographical entities and its corresponding language(s). Arabic so far is being well served by AINC and the Arab consumer is well represented in international bodies.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

"Governments" do not map to "languages" and "languages" do not map one-on-one to "scripts". This is a fundamental premise which must be understood. Once this is clear, the role by government only occurs when the language/script group happens to find synergy with a particular government department responsible for that language/script group residing in that territory. So the fictitious Ministry of Tamil Affairs in a country X might be tasked by the government of X to liaise with the representatives of INFITT from that country. In some cases the Government works closely with the representatives. In some cases, the language group is such a minority that there is no relevant government organization that deals with it. It is unlikely for example that although there might be several million Tamil speaker programmers in California that say, the US Government might have a Tamil Affairs Department, although it may well have a group that monitors Tamil Affairs but that department is most unlikely to have the charter to do Tamil domain names.


Response from Hiro Hotta

Government can propose a language definition.


Response from Peter Constable, SIL International

This is also a very sensitive issue. Certainly, governments should have a role in selecting names for official languages (though there is potential for conflict given the fact cited in the document that languages span borders, and given that different names or spellings may be used in different countries). Beyond that, there are many would argue in many cases that governments should specifically *not* be given a role, on the basis that many governments severely limit or oppose the interests of non-dominant language communities within their borders. It is probably safe to make the claim that some governments currently limit the linguistic freedoms of language communities living within their borders (in some case, even citizens).
 


What role, if any, should by played by recognized language authorities (for example, l'Académie française) in the selection of non-ASCII TLDs semantically associated with languages?


Response from Kilnam Chon

This is (yet) another tough problem, in particular on the languages (character) being used among multiple countries.


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

The same comment applies as under 5. The ISO mechanism obviously
involves national standardizing bodies as well as other national and cross-national authorities.


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

The existence of a body, such as AINC (Arabic Internet Names Consortium) which already involves governments as well as other technical & linguistic institutions representing Arabic speakers, and which uses voting rules and other recognized objective criteria for analysis and selection is an objective proof of “consensus”. ICANN should not decide these matters for others, of course. It should coordinate and take recommendations from each local body that specializes in a set of geographical entities and its corresponding language(s). Arabic so far is being well served by AINC and the Arab consumer is well represented in international bodies.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

Language authorities have their own charter. They may not necessarily take kindly to additional out-of-charter work that is foisted upon them. Let the organizations that have an interest in these areas, and had the credentials and competence self-organize and self-determine the selection process that makes the most sense for them. They will liaise with the appropriate parties once the standards are set. They will decide whether TLDs semantically associated with languages make sense for them or not. And not some external party that does not have language expertise, and certainly not some language authority that does not have Internet expertise or experience.


Response from Hiro Hotta

Recognized language authorities can (or even "should") propose language definitions.


Response from Peter Constable, SIL International

To the extent that such language authorities are often affiliated with national governments (which provide the source for their authority within a given country), the statements made under the previous point more or less apply here. I would think it reasonably non-controversial for such an agency to make decisions affecting the language for which they are recognized as authority (though not necessarily: cf. resistance to the German orthography changes of 1996).


III.    CULTURAL GROUPS / ETHNICITIES


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

General comments on this topic

It is best to consider languages and geographical entities for non-ASCII TLDs rather than cultural groups and ethnicities. The latter are, as you pointed out, extremely hard to define and enumerate. However, consistent with comments above, a local body responsible for a set of geographical entities and associated language(s) is best to address cultural and ethnic issues. For example, in the Arabic world, there are several cultural groups. No one is better qualified than an entity such as AINC made up of Arabic institutions from the Arabic world to decide on what would be relevant TLDs that represent meanings agreeable to all cultural components of the Arabic world.


Is there any recognized, authoritative reference list of cultures and ethnicities (analogous to ISO 3166-1) that could be employed as a reference against which to evaluate proposals for non-ASCII TLD strings semantically linked to them?


Response from Håvard Hjulstad (Chairman of ISO/TC37; Convener of ISO/TC37/SC2/WG1)

(This) issue relates to cultural groups / ethnicities. That is outside the scope of our work, but still closely related. My personal opinion is that general consensus in this issue is even more difficult than for languages. There is a high degree of overlap between language and ethnicities. We already have countries as TLDs. It might possibly suffice to add language-based TLDs.

I know of no "official" lists of ethnic groups (or religious groups or any other culturally-based "classification"), although in particular immigration authorities do have a need sometimes to "classify" groups according to cultural background (you don't necessarily place two persons from Serbia in the same room in a refugee facility if one is a Muslim from Kosovo and the other a Greek orthodox from "the rest of Serbia").


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

The closest is the SIL International's Ethnologue <www.sil.org>. They reference the English language catalogue of different languages. However, they may not have the complete set of strings in those languages that may be meaningful to those people who speak or write them, that describe the name of these cultures and ethnicities in the cognate language.

Again, it is best left to people who speak it to self-determine their future. Conversely, if they all wish to learn English and use ASCII and do not wish to use their language and script for domain names, then we should not force it on them. What ICANN can do is to create a conducive environment that fosters their development. A good example is MINC's outreach efforts to promote multilingual domain names awareness in as many language as it can.


Response from Hiro Hotta

No such list is known to me.


Response from Peter Constable, SIL International

No. There are probably attempts at such a list, but the difficulties in enumerating such distinctions are quite a bit greater than those for languages, as noted in the doc. I am not aware of any lists that I would consider candidates in this regard.
 

How should we define the community to be served by the manager of a non-ASCII TLD semantically linked to a culture or ethnicity?


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

This question should best be inverted. How should the community define who the manager of a non-ASCII TLD that is semantically linked to a culture or ethnicity
should be. The community must first decide on how they wish to refer to themselves. In any case, they might find this description of culture and ethnicity does not map
to a script. The Tamil ethnic or cultural group fits this category, and fortunately, the language maps uniquely to the ethnicity and the culture. But in some cases they
don't apply. Again, ICANN should let those groups decide and let themselves decide, rather than creating unnecessary sizes to force a fit.


Response from Hiro Hotta

Not accurate. The word "speakers" should be changed to "users."


Given the vast range of complicated political controversies and the difficulty of demonstrating, for example, a consensus among all members of a given culture or ethnicity, should this category simply be excluded as a matter of policy pragmatism? If not, how could ICANN avoid being caught in the middle of innumerable emotionally charged and politically sensitive fights?


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

ICANN should simply avoid dabbling with the control of the non-ASCII name space and delegate out the responsibility as far as possible.


What role, if any, should by played by governments in the selection of non-ASCII TLDs semantically linked to a culture or ethnicity?


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

Governments do not map one-to-one with a culture or ethnic group. In most cases, ethnic groups cross governmental borders. If governments are involved, and sensitive ethnic issues are created where there used to be none, the situation can be potentially explosive. Of such are basic ingredients for war, and ICANN should not dabble in issues of governments versus cultures and ethnicity more than necessary as they are major fault lines of almost every country today. Eschew control or the need to control and delegate the responsibility to the groups concerned.


IV.    EXISTING SPONSORED gTLDs


What process and criteria should be employed to select non-ASCII TLDs semantically associated with an existing sponsored gTLD?  Are any special considerations required?

Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director

Firstly, the selection of the non-ASCII TLDs semantically associated with sponsored TLDs must be made by appropriate local bodies (such as AINC for Arabic). Secondly, the non-ASCII TLDs does NOT have to be managed by the same registries (those that manage the ASCII version). The selection of which registry should manage the non-ASCII TLDs should allow proposals from other entities. In fact, other recognized bodies, such as AINC, may decide which registries should manage the non-ASCII TLDs and coordinate with ICANN the management and set up of at least Arabic root servers, etc.


Response from Cary Karp, President and CEO, Museum Domain Management Association

The policy basis for the existing .museum TLD is given by the definition of "museum" stated in the Statutes of the International Council of Museums (ICOM). This organization was created in 1946 and is a non-governmental non-profit organization maintaining formal relations with UNESCO and having a consultative status with the United Nations Economic and Social Council. ICOM is dedicated to the development of museums and the museum profession, and operates globally for the preservation of cultural heritage.

Committed to the promotion and facilitation of professional cooperation, ICOM is a worldwide network for museum professionals of all disciplines and specializations. The 17,000 members of ICOM in 140 countries participate in the activities of 108 National Committees and 28 International Committees. Some National Committees have also organized on a regional level to reinforce their action. ICOM is affiliated with 14 international associations.

ICOM's publications and activities have long been produced and conducted in a manner that reflects the diversity of languages used by its membership, and the national committees conduct their primary business in their native languages. More importantly, a national committee may have its own implementation of central ICOM policies in full accommodation of local conditions and concerns.

ICOM's global organizational network provides an ideal basis for establishing an internationalized platform for the development and maintenance of .museum policies and administrative procedures. This was foreseen from the outset and is reflected in the Sponsorship Agreement between ICANN and MuseDoma, for example, in the wording, "Later in Phase 2 [the Full Operation Phase], MuseDoma will consider, in consultation with the Sponsored TLD Community, whether the provision of ENS [Eligibility and Name Selection] Services should be distributed on a broader collaborative basis among appropriate organizations selected by MuseDoma."

A national or regional node foreseen in this extended action might include representatives of the National Committee of ICOM, any other National Museums Association that may be in operation, and an accredited registrar providing support in local languages. The availability of different non-ASCII character semantic equivalents of .museum would significantly heighten the potential utility of this mode of policy distribution. It would do so by providing clearly defined vessels for local implementations of the shared international policies. It would also provide a vernacular basis for eliciting the broader participation of museums in different language regions and thus provide significant impetus to the growth of the global museum community's Internet presence. This, in turn, would benefit the entire community of Internet users.

The scope of ICOM's pre-existing efforts in accommodating the language needs of its membership will be readily seen on the ICOM Web site. In present context, however, they will be most clearly
illustrated by the mirror site maintained bilingually in Japan at:

     <http://www.museum.or.jp/icom-J/>

and

     <http://www.museum.or.jp/icom/>

The agency operating this service and MuseDoma are currently discussing both a similar bilingual mirror of the MuseDoma site and the establishment of a Japanese ENS node.

As clear as the benefit to be derived from the availability of non-ASCII character semantic equivalents of .museum may be, there are equally significant risks of counterproductive consequence if the policy basis for their coordinated operation is not suitably structured.

Each TLD string should be treated differently, and should be open for proposals to any potential registry operator that can establish the basic requirements for a sponsored TLD, including support within the community to be served.

If this were permitted to serve as the normative basis for impending action it would largely, if not totally, negate the effort currently in progress to establish a unified presence for the global museum community on the Internet. It is difficult to envision any constructive purpose that would be served by mandating a heterogeneous policy structure that might, for example, render a Korean museum eligible to hold a name in the TLD string consisting of the Hangul characters meaning "museum", without at the same time establishing the same museum's eligibility for the present .museum sTLD.

In order to avoid any such negative effect, some central coordinating body will be needed. I submit for your consideration that the .museum Sponsoring Organization <http://musedoma.museum> has been established in a manner that will enable it to assume this role without difficulty. Should you perceive any utility in coordinating relevant aspects of your own action with MuseDoma's efforts in the international distribution of .museum policy oversight, I am at your disposal for the discussion of how this might proceed. The establishment of a viable basis for providing alternative character set representations of .museum, sharing the same core policies and providing a basis for the clear demarcation of local considerations, would be a clear step forward in the development of the utility provided by the Internet to its users.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

Decouple the two. These are separate issues. Non-ASCII TLDs are NOT extensions of ASCII TLDs and should not be treated as such. A sponsored gTLD that is meaningful
in one language may not be meaningful in another. ICANN should not view the so-called Non-ASCII namespace through the tinted lenses of the ASCII namespace.


Response from Hiro Hotta

It is desirable that the same delegate as that of the current ASCII gTLD becomes a delegate of the corresponding non-ASCII gTLD. The reasons are :

(1) Registrants and users would desire that the rules of the registration and the characteristics of the domain name space are the same, because such situation would bear less confusion.

(2) It would require substantial cost for ICANN to investigate and qualify new gTLD delegates.


V.    EXISTING UNSPONSORED gTLDs


Response from Jeffrey J. Neuman, Esq., Director, Law & Policy, NeuStar, Inc.

General comments on this topic.

With respect to "existing unsponsored gTLDs", NeuStar believes that the issue is not "whether to give any advantage to the current registry operators of the existing ASCII unsponsored gTLDs," but rather whether the operation of a non-ASCII version of a particular unsponsored TLD could be operated by a separate registry operator than the one operating the ASCII registry without causing consumer confusion and instability within the DNS. When the issue is framed in this light, we believe that the answer is no. This is especially the case when such unsponsored TLD is a so-called "chartered TLD." By chartered TLD, we mean a TLD, like .BIZ, that carries with it several unique restrictions and dispute resolution policies, that establish the integrity and utility of the space. We also take serious issue with your assertion that there are "no significant advantages, other than for the existing registry operators of the existing ASCII unsponsored gTLDs."
 
We believe that existing operators of sponsored or unsponsored TLDs should be offered the right to administer and operate the non-ASCII TLD string that is semantically associated with the existing unsponsored gTLD for several reasons:
 
Ease of Transition

One cannot determine the feasibility of a registry operator without discussing first who should be allowed to register in the non-ASCII TLD. Much of the world-wide policy discussion on this topic has focused around the fact that businesses (and to some extent consumers), who have registrations in the ASCII version of an unsponsored (or sponsored) TLD believe that they are entitled to have the ability to register their domain name in the semantically equivalent non-ASCII TLD. This, they argue is of paramount importance, to prevent consumer confusion.
 
Assuming this is implemented, without the development of a new Registry-Registry protocol (which we do not believe has ever been contemplated by any standards-based organization), the only entity in a position to ensure that such a policy can be implemented effectively, is in fact, the existing operator of the ASCII gTLD. Especially with the new so-called "thick registries" (i.e., Afilias, GNR, NeuLevel and Registry Pro), the transition and launch of the semantically equivalent non-ASCII TLD could operate in a smooth manner that ensures the stability of the DNS. If a new operator were to be selected for the non-ASCII semantically equivalent TLD, then that new operator would need to:

(1)     develop a registry-registry protocol; and
(2)     require that the existing operator of the ASCII TLD build
and implement such protocol. 
   
It would also force the existing operator to:
 
finance the implementation of the registry-registry protocol (on its end);
cooperate with the new operator; and
possibly to share confidential information about the operation of its ASCII TLD.

There would have to be an additional policy added as to who would pay the costs borne by the existing ASCII Operator.
 
B) Policy Stability:

As the Registry Operator for .BIZ, NeuLevel has developed several unique policies for the operation of .BIZ, including registration restrictions, intellectual property protections and dispute resolution mechanisms. Examples of such policies include a restriction of speculation and purely noncommercial uses of the .BIZ domain names. Several of the other new so-called "unsponsored TLDs", including .name and .pro, also have their own unique standards, policies and dispute mechanisms. In order to maintain the integrity of such a chartered TLD for each of its registrants, it is essential the implementation of that TLDs policies remain neutral, consistent and uniform throughout the world. If there were another registry operator operating the non-ASCII semantically equivalent TLD (or worse yet, several registry operators operating different non-ASCII semantically equivalent TLDs), who would ensure that the ASCII TLD's policies were implemented in the same neutral, consistent and uniform manner as the ASCII TLD operator. Moreover, the potential differences in policies between the ASCII and the semantically equivalent non-ASCII TLDs could create massive consumer confusion in the marketplace. Those consumers registering in different non-ASCII TLDs within the same semantically equivalent ASCII TLD would have no assurances that the policies between each of the semantically equivalent TLDs are implemented in such a neutral, consistent and uniform manner. This could utterly destroy the integrity of the entire TLD space. As an example, what would happen if the ASCII TLD for NeuLevel required .BIZ registrants to use its domain name for a bona fide business or commercial purpose, and a new Non-ASCII operator did not have the same requirement? What if the new operator allowed domain name speculation (currently forbidden in .BIZ)? The differences in policies for the semantically equivalent TLDs could destroy the integrity of the space.
 
C) Consumer Confusion between IDN.ASCII TLD and IDN.IDN.

This paper does not even address the potential confusion caused between the ASCII registry operating an ASCII.IDN TLD and having a separate registry operate the semantically equivalent IDN.IDN TLD. For example, under the current ICANN Registry Agreement with NeuLevel, NeuLevel has the right to operate an IDN.BIZ TLD once technical standards are developed for the operation of such a TLD and those have been approved by ICANN. In accordance with its agreement with ICANN, NeuLevel, as most of the current registries, is planning on deploying such an IDN.BIZ in multiple languages in the very near future. If NeuLevel were to offer (as VeriSign currently does in .com) a Chinese version of IDN.BIZ, then you can imagine the inherent confusion in the marketplace that would be caused if another operator were allowed to introduce the semantically equivalent Chinese IDN.IDN with different technical standards and policies. The problems raised in numbers 1 & 2 above would be even more apparent here.
 
D) What about ASCII.IDN?

This paper also does not address whether ASCII.IDN would also be allowed for an non-ASCII top-level domain. The addition of this type of TLD would raise the same concerns expressed above and would also have the potential of causing more massive consumer confusion if not operated by the existing semantically equivalent ASCII TLD operator.


Response from Kilnam Chon

General comments on this topic.

This category is the main issue for development of the (domain) name space, and much effort must be spent on the development for each language as I stated in Section 2.  Mere extension of ASCII TLD to non-ASCII would be a wrong approach due to the following reasons;

Each language community is different from each other as we are finding out in Korean and Chinese.  Other language communities would have different aspects, too.

We should learn from the experience of ASCII TLDs. Some are good, but others are bad including imbalance caused by .com.  This is a good chance to try remedy to the .com and other problems.

One-to-one mapping for ASCII TLD may not exist, and this would be a bad approach we are finding out in Chinese language/character community for .com.


What process and criteria should be employed to select non-ASCII TLDs semantically associated with an existing unsponsored gTLD?  Are any special considerations required?


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director
   
As mentioned in previous comments, local bodies which specialize in a set of languages / geographic entities are best to select which non-ASCII TLDs are counterparts to unsponsored ASCII TLDs. For example, AINC (Arabic Internet Names Consortium) is in the process of selecting and adopting such non-ASCII TLDs. A final selection is expected soon. Selection criteria are (and should be) rigorous and can only be made by such local bodies which are best to understand the linguistic, cultural, political issues of such selections. For example, the Arabic language does not usually use abbreviations, unlike other languages such as English. As a result abbreviated words cannot be used as meaningful gTLDs.  Some abbreviations may in fact be corresponding to culturally and religiously offending words. Fortunately, for Arabic at least, Arabic words are typically short by nature. These issues are being considered and studied very seriously by AINC and probably by other bodies for their respective languages. ICANN should take recommendations of such non-ASCII TLDs from these bodies and adopt them.

As the selection of registries, we agree that current registries which manage the ASCII TLDs should NOT necessarily be given control of those TLDs, especially if there exist very viable candidates to which the local bodies prefer to assign this responsibility. If local bodies, such as AINC, decide who to assign responsibility for non-ASCII TLDs, they should be recognized by ICANN.

Finally management of root servers for the non-ASCII TLDs should be coordinated between ICANN and local bodies in a joint effort coordinated by AINC to ensure compatibility and continued service.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

This is a non-issue created by imposing the ASCII worldview to the non-ASCII world. If in the well-intentioned effort to create a facility for the non-ASCII world, ICANN ends up
destroying the goodwill it hopes to generate, it will be extremely sad. The spectrum of gTLDs need not necessarily map to one-to-one equivalents in other languages and in
other scripts. Failure to give up this assumption and this predominant thought pattern will inevitably lead to grief.


Response from Hiro Hotta

It is desirable for ICANN to investigate and qualify delegates of such gTLDs. The delegate is not necessarily the same delegate of the corresponding ASCII gTLD. The reasons are:

(1) Very little confusion will occur because the rules of the registration and the characteristics of the domain name space would not be confusingly different even if ASCII TLD and corresponding non-ASCII TLD are served by different registries.

(2) If current ASCII gTLD registry serves the corresponding non-ASCII gTLD, the privilege is too big. For example, think of the situation where the current .com registry can serve all the non-ASCII TLDs corresponding to .com of many languages.


VI.    EVERYTHING ELSE


What process and criteria should be employed to select non-ASCII TLDs that do not fall into one of the defined categories above – in other words, non-ASCII gTLDs?


Response from Asaad Alnajjar, CEO Millennium Inc., AINC Executive Director
   
This issue is no different than the ones above in that the local bodies should be best in making judgment. After all, for some geographic entities and languages, given specific cultural traits, certain non-ASCII TLDs make sense which would not for other languages even after translation.


Response from by Mr S. Maniam, Chairman WG03 of the International Forum for IT in Tamil (INFITT) and Chairman MINC Tamil Language Working Group Approved by Executive Director, INFITT.

ICANN should not be selecting non-ASCII TLDs. It should be open process for an open namespace. The Internet is an open namespace. As much as an individual can create any utterance or any script, let him create it. If only he alone speaks it, then the forces of nature will dictate its demise. If others do speak it, it grows into a language with a written script perhaps. So long as it is used by somebody, let them decide and be empowered to insert an entry into the TLD namespace. Let them be in control of their own namespace. ICANN will go down in history as the facilitator of language in the new dimension of cyberspace if only it could attain this thought pattern. No single organization or body or council of persons should have the power to dictate what languages go into cyberspace and what words go into the root server. Like dictionaries, the role is to mirror what happens in reality, what happens in real people their respective groups. If ICANN can find itself, then it should find itself as the coordinator and the facilitator and the enabler, with such a great enabling technology like the Internet, to let a thousand flowers bloom. It should focus its energies in creating and enhancing that infrastructure we call the Internet to support all the flowers that wish to bloom.


Response from Hiro Hotta

Can be handled in the same way as ASCII gTLDs.