[council] IDN Food for Thought
Bruce & Council, especially IDN Task force, I am due to travel this weekend, attending an academic conference at the Havard Law School next week and hopefully from there onward to Marrakesh. With all the work involved including the parallel and after hour events I will need to attend to discuss some research with the other collegues, I will try but am not sure I will be able to make it for the upcoming calls on IDN. I have prepared some comments and put forward some guiding principles that I joyfully name "axioms," but of course you may call them guidelines or principles, or whatever. They are based on my current understanding of the issues, and I'm opened to discussions. You may want (or not) to consider them during your discussion on the calls, and if I'm not there, I will catch up in Marrakesh. Olof, if relevant, please consider as input for the next iteration of the report. The comments are in the attached file, as well as in plain text below. Thanks for your attention. Mawaki --- INTERNATIONALIZED DOMAIN NAMES (IDN) AT THE TOP-LEVEL COMMENTS ON THE GNSO ISSUES REPORT & PROPOSAL OF POLICY ?AXIOMATICS? June 14, 2006 *** Note: The quotes are from the IDN Issues Report dated 9 May 2006, with the page number [in brackets] *** "These two approaches [DNAME-records and NS-records] are not mutually exclusive. Accordingly, if both are technically feasible, one of these approaches will not preclude the use of the other, pending policy considerations." [p. 3] Does this mean that one approach might be chosen for one IDN-TLD and the other for another IDN-TLD? Assuming that it is excluded to implement both approaches to the same IDN-TLD, does it imply that once the ?policy considerations? dictate a choice, only that choice will be implemented for all IDN-TLDs? "DNAME records imply a situation where the operator of an existing TLD would map it into some other script equivalent, either synonymous to or a transliteration of the original TLD. NS records allow the creation of a new TLD that can be proposed by any entity regardless of whether it is currently operating a top-level domain or not." [p. 3] The policy issues the community is faced with derive from assumptions that can only be addressed by replying to one fundamental question that is three-fold (which is somehow also related to the two technical approaches above put forward). The question is: 1) Will all the IDNs (incl. those mapping an internationalized equivalent onto an existing TLD) be treated as new gTLDs? 2) Or will they always be treated merely as translation/ transliteration of an initial TLD. 3) Or a mix of the two approaches: IDNs that (semantically) map onto existing TLDs will follow 2) and those completely (semantically) new will follow 1). Each of the above options leads to serious policy & political issues that will need to be assessed. Given the dynamics and the rationale behind the increasing demand for IDN, it might be worth considering as an axiom (though it may be seen as a postulate or premise). "During these discussions, the need to connect to the ongoing policy development process for new gTLDs was also highlighted, with a view to map the IDN-related issues to the issue areas already identified in the ongoing PDP for new gTLDs, notably selection criteria, allocation methods and contractual conditions." [p .4] Axiom 1: ------- Each IDN, that is, each IDN label shall, to the fullest extent possible, be considered and processed as a new TLD ? either it is meant to be generic or country codes, at least for management purpose. However, at political level, it must be recognized that any IDN-ccTLD shall enjoy the same prerogatives as the ccTLD, especially with regard to the sovereignty of the related country. The five policy issues enumerated (a, b, c, d and e) on p. 5 nail down to three policy-scenarios, distributed over country codes or generic names: 1) Application by an incumbent registry for an IDN based string that relates to the TLD it has been operating; 2) Application by a third party for an IDN string that relates to an existing TLD operated by another registry; 3) Application by a party for a totally new IDN-TLD. "What are the advantages and drawbacks of having a TLD (<.tld>) and its internationalized equivalent (<.idn-tld>) in the same TLD or in two different TLDs? - In particular, is there a policy preference to have domain names under <.tld> and <.idn-tld> resolve to the same website or to different sites? - Ancillary aspects are whether <idn-domain>.<idn-tld> should be the same as <idn-domain>.<tld>, whether the registrant of <domain>.<tld> also should have <domain>.<idn-tld> and similar aspects regarding combinations with <idn-domain>.<tld> and <idn-domain>.<idn-tld>?" [p. 6-7] "Provided that an internationalized equivalent of a TLD exists as <idn-tld> in some script, should there be a policy for what script(s) may be used at the second level, such as <idn-domain>.<idn-tld>? In other words, should the script used on the second level match the script used in top-level? Given that, with specific exceptions, mixing of scripts is prohibited on the second level, should the same rule apply to the top-level?" [p. 7-8] First, it must be understood that the demand for IDN is not just for the sake of having colorful strings in the DNS; it is deeper than that, and it will renew and expand the Web contents. It is more likely that the website behind a domain name under <.idn-tld> will have a different form of content, adapted to the community that uses the related IDN script, from the corresponding website for the same domain name under <.tld>. This will be even more so when the domain name itself will be in IDN format, i.e. <idn-domain>.<idn-tld>. Thus, there should not be a policy preference that could prevent both domain names to resolve to different websites. Though it is desirable to have an homogeneity throughout levels of the DNS, it is clear that a lot of languages will still remain outside of the TLD, increasing chances for continuing mixing of scripts. If inter-level mixing is inevitable due to IDN being already implemented at the second level (domain names), intra-level mixing should however be avoided. So the rule of no mixing of scripts on the second level should apply to the top-level, too. The non-homogeneity of the string <idn-domain>.<tld> is due to the historical precedence of ASCII-based TLDs, leaving no choice to the rest of the world to register IDN domain names under ASCII TLDs. As other types of scripts will become available in the TLD, there will be more and more homogeneity in the registration of IDN-domain names with the corresponding IDN-TLD. But again, provisions should be secured to enable the registrants and the users to have different contents (at least in terms of language, presentation, layout, etc.), or the same, at those different addresses combining ASCII and IDN standards. In other words, <domain>.<tld>, <idn-domain>.<tld>, <idn-domain>.<idn-tld>, and <domain>.<idn-tld> should potentially remain different addresses (URLs). "Should entities other than the existing TLD registry be entitled to run an IDN equivalent or equivalents of this TLD? If so, under what policies should the ?new? registry manage the <.idn-tld>? Are there special considerations required in this regard concerning TLDs with eligibility requirements?" [p. 6] I fail to see any good reason to answer ?No? to the first question, and addressing the second one is an important part of the substantial work that needs to be done by the GNSO Council on the IDN issue. "Should a registrant in <.tld> have a prior right to register in the IDN version <.idn-tld>? Would current domain name holders feel that they are forced to register in the IDN equivalent for brand protection? Does an intellectual property rights holder in one or more jurisdictions have a prior right to register in an IDN version?" [p. 8] Without prejudice to whether or not there will be sunrise period at introduction to each IDN-TLD, all competitors should be treated on an equal basis. Axiom 2: ------- A name is a specific string of characters meant to be an identifier of a unique entity. Having property rights over a name does not entitled to property over matching strings in other set of characters, or over its equivalents in virtually all language scripts. It also and always must be reminded that a domain name is not a trademark. ICANN should be careful not to act as if entrenching a pre-eminence of the English language on top of the other languages. "What selection and approval processes should apply for translation and/or transliteration of an existing <.tld> to its script equivalent(s) <.idn-tld>? Should any transliteration be phonetic (= transcription) or definitional/literal? Should a registry be able to determine its own equivalent(s), subject to an approval process involving input from the community, including governments?[?] Should there be a limit on the number of IDN top-level labels per existing TLD? If so, how many IDN strings should be allowed per existing TLD? For ccTLDs, should such a limit be related to the number of official languages or scripts used within the respective country?" [p. 6] Axiom 3: ------- ICANN must stay away from micro-management and centralized planning. It is not the responsibility of ICANN ?to create [or not] internationalized equivalents of existing TLDs,? or if transliteration should be ?phonetic (= transcription) or definitional/literal.? Those are not global policy issues, and it is not the ICANN/GNSO to address them. It is not the duty, even less the competence, of a registry to determine or make decision in naming standards that necessarily have linguistic, cultural and political implications. Unless otherwise constrained by technique, the rationale for ICANN should rather be to set up guidelines to the effect of assessing and addressing requests from the community, not to define in advance the nature and the number of the IDN labels. Otherwise, ICANN would need to set up, in a centralized manner, a Global Academy of high-level linguists and language historians to effectively solve the problem. Registries are nothing else than businesses and the core competences of ICANN are technical. Furthermore, the fact that English is the language of origin, thus the lingua franca, of the Internet and its (earlier) infrastructures does not and must not make it the necessary origin of all language on the Internet, its infrastructures and in its governance mechanisms (and this is not at all contradictory to having English as the primary working language). This means ?things,? including among the core Internet logical resources, may be created directly from potentially any language, not just be justified, as a result of translation or transliteration, by the pre-existence of an archetype in English. Axiom 4: -------- The fact that English language is a precursor in the invention and governance of the Internet should not be translated and entrenched into a character of pre-eminence. "Should the IDN based string relate to an official language within the country of the ccTLD? In cases when a language can be represented in multiple scripts, should each script be entitled to a separate IDN based string?" [p. 6] There should be a local/national advisory committee including all the relevant stakeholders (notably, with policy as well as technical expertise, e.g. from the RIRs, etc.) in order to build consensus, especially where the IDN representation might not be straightforward. Such committee will act as a buffer between ICANN and the user communities, filtering the naming issues that might be addressed at local level from those to be addressed by ICANN, especially in cases of multiple languages in the same community or multiple scripts for the same language. Mainly two scenarios can be considered: i) The issue is country-specific: the variety of competing options remains in the confines of the same country, and it is up to the local communities to reach consensus for language and script representation at national level. In this case a local/national advisory or steering committee may be the best approach; ii) The issue is clearly transnational: different countries not only share the same language, but identify with it, or have historical claims over it, while actively using it currently. Then after ICANN receives a consensual application from one of these countries, it shall seek international expert advice in consultation with the other countries that might have claims over the concerned language and IDN. In such cases, ICANN should definitely encourage cross-country consultations to build consensus prior to application, and joint applications. In the latter case, countries in Africa and Asia using English or French (as a legacy of the latest wave of colonization in History) may not have that level of claims that will justify adopting a different ?IDN? script for the same TLD that already exists and is based on the (American/UK) English language or on the French language as written in France (apart from the fact that those languages are not representative of the level of variety we are trying to achieve through IDN). However, due to its multicultural environment the English language in a country like, e.g., South Africa may have totally assimilated non-English words (from local origin) that are not found elsewhere. A new TLD application based on such words, even by an English speaking community in this case, may account for IDN depending on if by IDN we just mean a non-ASCII based script, or a different lexis and access for different (more local) users. In general and on the long run, local communities should be empowered and entitled to a ?representation? in the TLD space and in different scripts, as long as there is a demonstrated support and commitment to sustain the IDN-TLD. Even in countries where there are local languages different from, not only the official, but the national language due to national sovereignty (e.g., French territories in the West Indies), there shouldn?t be barriers at ICANN level for the local communities in those territories to apply for IDN, irrespective to whether or not the national language has already been introduced into the TLD. Indeed, the creole languages in West Indies or elsewhere, either based on French, English or Dutch, should be able to apply for IDN-TLD in the eyes of ICANN, though it might be advisable that the latter seeks consensus from the GAC and the countries involved. The same applies, obviously, to African languages, from those with a long writing tradition such as the Amharic (Ethiopia) with its ancient and original script and the Swahili for example, to those spoken by millions of people and that are also being more and more written and coded, such as Hausa, Bambara, Wolof, etc. "What is the accepted representation of a country name in non-Latin scripts? As ISO 3166 provides for translations of its labels into other scripts, what status should be given to these translations regarding IDN based strings? Should there be a requirement that any party aspiring to run an IDN version of a ccTLD must be located within the geographic territory associated with the ccTLD?" "What considerations need to be made for languages and scripts used across multiple countries?" [p. 6] Axiom 5: -------- Where ISO-3166 provides for translations of its labels into other scripts, the IDN-ccTLD in the corresponding language and script shall be consistent with ISO-3166. However, there is no reason to think that IDN-ccTLDs will be proliferating all over the world. Given that ccTLDs are intended for more specific uses under country-specific policies, it will be mainly up to the country to figure out whether or not they want IDN version of their ccTLD and if so, in what language scripts. Apart from ASCII and scripts that are of significance for the concerned country, it is unlikely that they request more IDN-ccTLD. The IDN-ccTLD should follow at least the same requirements as the ccTLD. However, it might be relevant to add more specifications, given a narrower and more localized client/user base. In any case, at a time of increasing ccTLD redelegation where countries are being recognized sovereign over the ccTLDs (all active only in their ASCII version so far), it wouldn?t make sense to give less recognition to IDN-ccTLD. The language behind the ASCII standard has no special virtue per se (or in nature), other than the fact that it is more practiced internationally than other languages. Regarding languages that have some variances in their script (orthography?), French and English are spoken with some variances in different countries but the UN, for example, only use one standard French and one standard English. It should even be more feasible to standardize naming scripts (not based on full names but on a few coding letters/characters) in languages that have comparable variances. Where in some places, e.g. in Asia, the script is substantially different and used in different countries, the issue should be regarded as of two different languages; for IDN can be seen, at least from ICANN perspective, first as a question of ?graphics? with cultural and political identities attached to it, and it should be concerned with the ?graphics? but stay away from any temptation of establishing linguistic norms, or language classification or taxonomy. In sum, ICANN should establish clear procedures for the application process and assessment; it should consult with country representatives (GAC, ccTLD, etc.), and should call, and encourage particularly the communities involved, for public comments and inputs. After due process, its decision should be final. Attachment:
IDN Axiomatics_v1.1.doc |