Page 33: http://www.icann.org/en/topics/new-g...04oct09-en.pdf
Note on Variants -- Currently, the gTLD application process
is established so that each application is for one string,
whether ASCII or IDN. There has been comment that
applications for IDN strings should also accommodate
variant strings. Discussions on possible methods of
managing variants at the top level have indicated that
restricting variants from being delegated in the DNS root
zone might disenfranchise certain regions that otherwise
would benefit greatly from the introduction of IDN TLDs.
Delegating variant TLDs in the root zone without a
mechanism for ensuring that the TLDs are treated in a
method that guarantees a good user experience is a
stability concern related to confusability for end-users. This
can be compared to the “companyname.com” situation,
where two domain names (one with all Latin characters
and the other with mixed Latin and Cyrillic) look identical,
but were different technically. Users clicked on the
“wrong” address leading to a site different than expected.
This activity resulted in a change in the IDN Guidelines,
requiring that scripts not be mixed in domain names unless
there is a linguistic reason for doing so (e.g., in the case of
Japanese that is represented by mixing of four scripts). This
is also a requirement for TLDs, but does not solve the
At the same time, disallowing or blocking variant TLDs
means that some users will have a very difficult time using
the IDN TLDs. In some cases it is not possible for the user to
know which character he or she is typing. Some keyboards
will offer one or another variant character but not both. In
this way, without the variant TLDs in the root, communities
may be getting error messages when attempting to reach,
for example, a web address with a domain name under
one of these IDN TLDs. This is not the intent of IDN
deployment. Rather, the objective is to help all
communities have equal access to the Internet.
Not all variants are visually confusing. To maximize benefit,
ICANN has attempted to define variants in a narrow
manner, only including variants that are visually confusing.
The intent was to allow variant TLDs that are not visually
confusable with others to be delegated in the DNS root
zone while a stable solution was found to address the
variants that are similar.
At this time it is an open question whether stability issues
include variant TLDs that look different, and are typed
differently, but are used interchangeably for the same term
by the users.
Another open question is the content of an agreement
between the IDN TLD operator and ICANN requiring that
registrations under two variant TLDs be handled (say, in a
bundled or aliased manner, following RFC 3747, or a
different technical solution) in a certain manner.
Finally, there is the question of whether it is necessary to
enforce rules required for the development of IDN Tables.
IDN Tables hold information about the characters that
should be treated as variants. The TLD operators develop
IDN tables. Presently, TLD operators are urged to consider
linguistic and writing system issues in their work of defining
variants, and cooperate with other TLD operators that offer
the same or very similar looking characters. This is not
always practically possible, and there are currently no rules
about defining variants. There also are no defined dispute
mechanisms in cases where communities may disagree on
a variant definition.
An implementation support team of technical and
linguistic experts is examining this set of issues and expects
to publish a proposed solution for managing variants at the
top level. The proposed solution would then be available
for public comment.