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 shouldnt
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 wouldnt
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.
