ICANN's CEO Paul Twomey made talked recently to San Francisco Chronicle and IDN's wasone of the topics that he talked about
.Q: When can we expect to have international top-level domain names in differentlanguages?
A: I'm thinking first quarter of next year. There's a series of countries - the northeastAsians, the Arabs, the Indians, the Arabic-speaking Farsi, south Asia if you like, andthen the Bulgarians and the Greeks and the Russians - have all expressed interest infast-tracking this process. And this has got very high attention. In Russia, it is an agenda item for both the president and the prime minister. Similarly, we've had lots of good conversations with the Chinese - it's going to the top of ministries and to statecouncils. It's also a very high priority for India. The Indians are putting fiber into 600,000 villages across India. Around 150 million people in India speak English. Thenext billion don't. So the policy is to bring the Internet to the next 300 to 400 million people in India. To do that they have to have a keyboard that's in the character set ofthe village. There are 22 official languages and 11 scripts
.Q: What implications does this have for balkanizing the Internet? We as English speakers arespoiled because the entire Internet has been open to us, pretty much. Will that no longerbe the case?
A: Let's be clear about what we mean when we say "the Internet." The Internet has three layers. There is a transit layer - the pipes and the radio signals. There is theprotocol layer, which is the stuff we're worried about - the mechanisms whereby everydevice on the Internet talks to every other device, where 250,000 private networksoperate as one single, global, interoperable Internet. And then sitting on top of those isthe application layer. The reality is that the application layer is increasingly localizing,and as a consequence we're going to see the Internet reflect the world - the local andthe global. Think how many businesses down in the Valley are all about local - you'vegot to be local, right? Well, we're going to be local in Shenzhen and we're going to belocal in Hyderabad, not just local in Boise, Idaho. What we've been very concernedabout is to ensure it's done in a way that's fully integrated across the entire globalInternet. So, to give you an example, there were various proprietary voices in theMiddle East promoting plug-in mechanisms for Arabic that had to be put in at the ISPlevel for people to have a fully Arabic experience. The difficulty with that is that if youwent to Switzerland on holidays, it wouldn't work.What we're concerned about ishaving a mechanism that no matter where you are, from Norway to New Zealand, it'sgoing to work. There is only one single global technology. The TCP/IP protocol doesn'trecognize geographic boundaries, it's a topological network. This is one of the geniusesof the Internet, why it's grown so quickly. We're very committed to promoting that.
Q: If I had a domain name that was in, for example, Chinese characters, and I didn'thave my (Chinese keyboard) with me, how would I type it?
A: Let me give an Australian example. I've got six or seven domain names from someof the businesses I've had. We had domain names that were "dot com" because wewanted to say we were global, particularly focused on North America, and we had "dotbiz" for similar reasons. But we had "dot au" and "dot hk" because we wanted to say we're Australian or we're Hong Kong Chinese, or whatever. Even in ASCII, people usedomain names as a form of identity. I think that will be even more so aroundinternational domain name country codes. If you're in China, people will use theChinese. And if they want to deal with Wal-Mart as a buyer of their manufacturedgoods, they can have a "dot com" or a "dot biz" or something in Roman characters, andboth Web sites will probably resolve to a hosted site that has English and Chinese on it.And if people have only an Urdu domain name, then they are probably saying that theydon't identify people who speak English or whatever. I do think also that innovation willcome in here and people will do all sorts of translationThis gives an overview of the IDN policy and implementation. The specifics of thepresent status is summarized by the definition of topics to work on by the IDN ccPolicy Development process.IDN cc Policy Development ProcessThe main topics to be addressed by the IDN ccPDP are summarized below as extracted from the Issues Report dated April 2, 2009 prepared by the Issues Manager Bart Boswinkel.
The issues are largely ( A to D) based on the topic areas as identified by the joint GAC-ccNSO working Group. To facilitate understanding and further discussion, the different questions are grouped in four clusters:
1) General, 2) Introduction, 3) Delegation and 4) Operation.
General Which ‘territories’ are eligible for an IDN ccTLD?
The existence of IDNs as ccTLDs assumes a direct relationship between an IDN TLD string and a‘territory’ as in ASCII ccTLDs.
a) Should this relationship be maintained?b) If so, should the ‘territories’ which are potentially eligible for IDN ccTLDs be exactly thesame as the ‘territories’ that are listed in the ISO-3166-1 list?
c) If not, should another list be used or should another mechanism be developed?d) Should anything be done about ccTLDs already being used as gTLDs?Should an IDN ccTLD string be “meaningful”?
a) An ASCII ccTLD string ‘represents’ the name of a ‘territory’ based on its entry into the ISO3166-1 list. Is there an obligation to make the IDN ccTLD string 'meaningful' in itsrepresentation of the name of a ‘territory’? For example, whereas .uk is 'meaningful'because it is a commonly used abbreviation for United Kingdom, .au is not 'meaningful'because the commonly used abbreviations for Australia are Oz or Aus.
b) If so, how is “meaningful” determined and by whom?How many IDN ccTLDs per script per ‘territory’?Apart from some exceptions, there is one single ASCII ccTLD per listed ‘territory’
.a) Should there similarly be only a single IDN ccTLD for a given script for each ‘territory’ or canthere be multiple IDN ccTLD strings? For example, should there be only one equivalent of .cnin Chinese script for China or .ru in Cyrillic for Russia?
b) Could there be several IDN strings for a ‘territory’ in a script? If so, who would determine thec) number and what are the criteria?d) If an IDN ccTLD string is not applied for, for whatever reason, should an IDN ccTLD string thatcould be associated with a particular ‘territory’ be reserved or protected in some way?How many scripts per ‘territory’?
a) Can a ‘territory’ apply for more than one IDN ccTLD string in different scripts if more thanone script is used to represent languages spoken in that location? For example in Japan morethan one script is used to represent the Japanese language. In other words, should there bea limit on the number of scripts each territory can apply for?
b) In what circumstances would it be appropriate to seek to introduce a limit on the number ofscripts a ‘territory’ may choose to introduce for a ccTLD or any TLD with a nationalconnection?
c) Can a ‘territory’ apply for an IDN ccTLD string even if the script is not used in a language with any ‘official status’ in that ‘territory’? For example, if the Kanji script is accepted under the IDNA protocol, can Australia apply for a representation of Australia in that scripteven though neither the script nor any language deriving from it has any 'official' status in Australia?
If ‘official status’ is required who will define it and who will determine it in each case? Number of characters in the string?Currently, ccTLD strings are limited to 2 US-ASCII characters and gTLDs to 3 or more. It is understood that abbreviations can be problematic for internationalized TLDs as abbreviations usedin US-ASCII are not used on a global basis in all scripts. The underlying nature of IDN makes theactual string inserted in the DNS always longer than two characters when expressed in Unicode(due to the IDNA requirement to prefix internationalized labels with ‘xn---‘). However, it is how the string appears in its non US-ASCII character set that is important. In this context:a) Should all IDN ccTLD strings be of a fixed length, for example by retaining the two-characterlimitation that applies to ASCII ccTLD labels, or can they be of variable length? If a variable string length is introduced for IDN ccTLDs, should it also be introduced for ASCII ccTLDs?
b) Does moving outside the current 2-symbol limitation create any security, stability or integrityissues?
c) Who determines the appropriate label used to represent a new IDN ccTLD string, and howare the set of characters used to represent this label selected?Are there any ‘rights’ attached to a given script?In purely technical terms, a script is a collection of symbols. However, each of those collections of symbols when put together in particular ways produce the ‘languages’ of groups of peoplesometimes defined by borders, although very often not. These groups are often referred to aslanguage communities.
a) Should such groups (or their governments) have special rights regarding those scripts? For example, should the Korean language community be entitled to restrict the use of theHangul script? If special rights exist what is the procedure to exert these rights and resolveconflicts?
b) Can anyone get acceptance of a script under the IDNA protocol or are there restrictions? Forexample, can a gTLD registry get the Kanji script accepted under the IDNA protocol? Shouldthat use be vetted/approved by Japan? If yes, would the same requirement apply if a scriptwere used in more then one ‘territory’?
c) Should it be possible to adopt two or more ‘versions’ of a script with only minor differencesfor use under the IDNA protocol and are there issues or concerns should this occur?Introduction of IDN ccTLDs / DelegationShould a list of IDN ccTLD strings be mandated?In the US-ASCII case, ccTLD strings are currently primarily based on the ISO 3166-1 Alpha 2 list.If a similar mechanism were adopted for IDN ccTLDs, this could mean that every ISO 3166 entrywould have an equivalent IDN ccTLD string(s) to represent it
a) Is such a list necessary?
b) Who would develop such a list?
c) Should such a list be mandated?
d) If yes, by whom?
e) Who would develop the criteria and relevant policies for identifying IDN ccTLDs?
f) Under what policy or authority would the list be created?g) If additional criteria and or policies are required, who is responsible for formulating thatpolicy?What precedence should be given to ccTLDs in the IDN implementation process?
a) Who selects the IDN ccTLD string in the absence of a mandated list?
b) If IDN ccTLD strings are not going to come from a mandated list then, how does an IDN ccTLDstring become designated as the string for a particular ‘territory’?
c) What are the criteria and policies to determine who can submit a request for the designationof an IDN ccTLD?
d) Who will develop the criteria and policies for determining the designation of an IDN ccTLD?
e) How will such issues as competing requests (both domestic and international) be dealt with?
f) What will happen if 2 ‘territories’ are eligible for the same or confusingly similar strings forIDN ccTLD?What coordination should exist between the different actors?
The deployment of IDN ccTLDs will require coordination among various actors, within territoriesand ICANN constituencies. Irrespective of the methodology employed, some coordinationquestions must be addressed, such as:
a) Who are the appropriate actors?
b) What are their roles?
c) Do the GAC ccTLD principles need to be revised in the light of the introduction of IDNccTLDs?Operation of IDN ccTLDsIs the operation and management of an IDN ccTLD different to that of an existing US-ASCIIccTLD such that there are specific global technical requirements, in addition to the general IDNstandards, needed for the operation of an IDN ccTLD? If so, how are those requirements developedand who would develop them?The IDN cc PDP timeline is here on this webpagehttp://ccnso.icann.org/workinggroups/idn-pdp-process-time-table-02dec08.htmALAC Chair and the IDN liaison to represent ALAC in the IDN ccTLD WG1.
Inputs from ALAC and theRALOs in response to the questions raised are invited.
