This document represents a proposal by ICANN’s At-Large Advisory
Committee (ALAC) for global policies to be introduced regarding
internationalized domain names (IDNs). It does not, however, represent the
unanimous views of the ALAC members. The ALAC will continue to discuss the
principles enumerated below, and will provide additional comments and
statements on IDNs.
Members of the At-Large community are encouraged to share their views by
sending emails for public posting to <forum@alac.icann.org> *
__________________________________________________________
First of all, we would like to express our appreciation for the hard work
conducted by many parties to promote the development and the deployment of
IDNs in various top level domains. However, we stress that IDNs are not only
a technical or business matter, but rather a fundamental element of the
respect for cultural diversity and of the internationalization of the
Internet. As such, cultural and political considerations should not be given
lower priority than economic or technical ones – as apparently it has
been until today.
We think that the prompt introduction of full and non-discriminating
support for all scripts and languages in domain names, as well as in other
elements of the Internet that are directly used by the final consumers, is
one of the most pressing issues that need to be addressed by the global
Internet community. However, since the Internet will be a resource that will
likely be used for decades, if not for centuries, any mistake made in this
phase could compromise its future in the long term. This is why we think
that special care must be taken in ensuring an orderly and wise deployment of
IDN registrations.
We also note that ICANN is the only global policy-making authority in the
domain name space. As such, it cannot ignore its responsibilities in
defining global policies, and in encompassing and enforcing such policies in
the contractual obligations of the registries and registrars.
The following is a list of proposed principles that we submit for the
consideration of ICANN and the Internet stakeholder community:
1. The possibility of a coordinated adoption (as “best
practices”) of common standardized variant tables for each script
should be studied and, if possible, embraced.
Even if the feasibility of this idea still needs some general
discussion and study, the availability and widespread adoption of common
tables could be of great use. It would prevent the confusion users would
experience by having to cope with strings that are equivalent in some TLDs,
but not equivalent in others. Also, the availability of global best
practices would prevent the adoption of imprecise or plainly wrong variant
tables by gTLDs and by countries where the availability of linguistic experts
in a given script might be limited or non-existent.
2. It is the right and duty of the Internet communities who use a
certain script to develop and adopt the “best practice” character
and variant tables that pertain to that script.
This principle in not only offered as plain common sense, but it is
also necessary to respect the cultural diversities and the natural principle
of sovereignty of the peoples of the world. ICANN should act as convenor and
facilitator for the affected community to self-organize and come to agreement
on the tables, but should also ensure that these best practices are
implemented by those TLD registries that have contractual agreements with
ICANN.
3. “Equivalence” should be defined in terms of usage:
strings which would likely look equivalent to the average user must be made
technically equivalent and bundled to the extent possible.
The definition of equivalence must be developed based on the effect
it would have on final users, not for other considerations; thus, two strings
should be considered equivalent when they are very likely not to be
distinguished one from the other when written or read. Also, not defining
any equivalences is an unacceptable policy, because it would prevent the
adoption of any anti-cybersquatting and anti-confusion measures, since there
would not be any simple and standard way to define which strings could be
confused one with the other.
4. All equivalent variants of a given domain name should be either sold
and registered in bundle, or reserved to the first registrant of any of them,
so that no two variants of the same name can be assigned to different
registrants.
Domain names that look equivalent should not be used by different
registrants or for different services - otherwise a whole new category of
cybersquatting and phishing cases will emerge. The opportunity of bundling
registrations of equivalent domain names should be carefully considered.
5. Registrants should not be asked to pay more for a bundle than what
they would pay for a single domain name, especially if they are not going to
actually use all variants.
It is not acceptable to force users to pay two, four, or even ten or
twenty times the registration fee – as the number of variants for a
string may easily become very high – to protect their name from other
people's registration of equivalent strings. (As an alternate possibility,
as pointed out in principle 4, you could consider the option of reserving
– but not registering – all variants when a given string of the
bundle is registered, and asking the registrant to re-pay the fee only in
case he/she actually wants to make a variant active.)
6. Existing registrants of romanized versions of strings should be given
priority in the registration of all equivalent variants in non-ASCII tables.
It would lead to the foremost confusion if the owner of, say,“
liberte.com” would have to watch someone else register
“liberté.com,” since after IDNs become common no
French-speaking user would ever type that domain name without the accent. In
that case, the existing “liberte.com” registration would become
practically worthless, or even considered as a squatter to the new
“liberté.com” registration. Also, this would not be
respectful of any investment of time and money that individuals and companies
might have made to promote their Internet presence. However, this principle
should only involve equivalence as defined in principle 3 – that is,
graphical equivalence. It should not involve homophonies or semantic
equivalences – i.e. the owner of liberte.com should not get priority
rights on domain names meaning “freedom” in other languages and
scripts (nor on the same string under other TLDs).
- Global registries should be required to support all scripts.
If support for a given script would be left to pure market
considerations, it is likely that minority scripts (seen on a global scale,
i.e. also scripts which are maybe used by entire countries but that do not
represent at this time a significant percentage of the global Internet users)
would never be implemented in gTLDs. We think that all peoples of the world
should be enabled to register domain names in their own script under global
TLDs, and especially under gTLDs that hold a majority share of the gTLD
market, such as .com .
8. The status of existing registrations, and the opportunity of
proceeding with registrations before final rules are developed, should be
assessed as soon as possible.
The more we proceed with the introduction of IDNs in an uncoordinated
and unregulated manner, the more problems we will have in fixing the damage
that will have been done. We think that ICANN and the affected communities
should undertake a special effort to develop and approve a global IDN policy
in the shortest possible amount of time. In the meantime, there is the risk
that the existing registrations will conflict with the final policy, and will
be a source of confusion or complaints.
While not much can be done about existing registrations, it would be
good to consider immediately whether the adoption of interim rules to
restrict additional registrations that might later cause problems is
appropriate. This applies especially to gTLDs, which affect all the
languages and scripts (ccTLDs are, in practice, a more limited source of
potential conflicts, and ccTLD policies on IDNs are already being discussed
at the national level). In any case, if any existing registration ever would
be deemed totally incompatible with the final policies and thus denied
renewal, the registrant should be adequately compensated/receive a refund.
9. A plan for the complete internationalization of the domain name
system, including top level domains and protocol string names, should be
devised, in cooperation with the other appropriate entities.
It is not particularly useful to make the second level domain name
international, if the user will still be required to type in the Latin script
to complete URIs (i.e. to enter the top level domain part of the host name
or the protocol part (e.g. http) of the URI). All parts of the Internet
identifiers which are to be used by final consumers should eventually be made
available in any script and language. Thus, given that not all these issues
pertain to the DNS, ICANN (through its new President's Advisory Committee on
IDNs) should promote a cooperative effort with other entities in this field
(e.g. IETF, W3C, etc.) to ensure that this final goal can be promptly and
effectively reached and to understand at which level (infrastructure,
application, etc.) each of these issues should be addressed.
Also, all rules, policies and contracts under the responsibility of
ICANN – the UDRP, for example – should be assessed to determine
whether they would need revisions to take into account the future mass
deployment of IDNs.