Aliasing of TLD Variants

[Werner Staub <werner@xxxxxxxx>]

ICANN's current proposal for the treatment of TLD variants is described as 
follows on page 9 in the document
"proposed-implementation-details-idn-tables-revision-1-redline-29may09-en.pdf":

 "However, comments on that proposal have indicated that allocation of
 variant strings that do would cause technical stability problems for the
 name space.  The resource record DNAME was originally expected to enable
 the aliasing functionality in the root zone, as DNAME is being used for
 this purpose at the second level under various TLDs, however, analysis
 to date shows that DNAME does not function at the root level. The
 proposal made by ICANN in the previous version of this paper (as
 mentioned above) was to delegate the variant strings separately and then
 require that the TLD manager ensures duplication of the multiple zones.
 However, the technical complication with this proposal is that while a
 registry manager can duplicate zone immediately under a TLD, this will
 not function at lower levels. This would put a requirement upon the
 registrants (and their sub-domains) to duplicate zone contents at lower
 levels as well. There is no mechanism to ensuring that this takes place.
 Unless a technically sound solution is demonstrated to successfully
 demonstrate aliasing or duplication functionality the variant strings
 cannot be allocated at this time.
 ICANN understands the need expressed in the community for enabling
 allocation of variant strings, in particular for locations where some
 users will key in one string and other users will key in the variant
 string when accessing for example a website. ICANN urges the community
 to continue to discuss and develop a technical solution that will enable
 the allocation of variant strings in the root zone in a stable manner.
 Until then IDN ccTLD Fast Track requesters will need to select one
 string per script or language only or alternatively wait until a
 technical solution has been found."

This would mean that, for instance, that Iran could only operate
the variant of the IDN ccTLD that resulted from the use of a Farsi 
keyboard. Identical domains input with an Arabic keyboard would
fail the DNS lookup.

This also would mean, for instance, that China could only get the
simplified-script variant of IDN TLD for China.

There is no justification for any such restriction. Aliasing between
active variants is needed, but an aliasing method with zero configuration
is a nice-to-have, not a necessity.

It is technically possible to configure any second-level or lower level
domain to be correctly aliased between all the variants. It is not part
of ICANN's mandate to "guarantee" automatic aliasing down the delegation
chain. ICANN must leave it to the registries, domain holders and
internet application hosting companies to correctly process the
equivalence of domain variants. (Of course it is in the mandate of
ICANN to ensure that variants of the same TLD are managed by the same
registry.)

Even though the variants represent a single domain, IANA can put separate
sets of NS records into the root zone for each variant. Each registry
will then have to run as many zones as it has TLD variants. In doing so,
it can ensure that all equivalent domains have the same name servers in
the TLD zones. The registries can use policies and best practices to
obtain correct aliasing on lower levels. There is no stability problem
as long as the registries make sure that all variants are treated as
one domain and thus are in the hands of the same registrant.

It is worth remembering, in this respect, that ICANN has never bothered
to require alias management from gTLD registries. This would be necessary
for cases like telefonica.com (with an acute accent on the "o") where a
diacritic mark gives rise to variants . By contrast, the CJK registries
made sure from the start that simplified/traditional script variants
were treated as a single domain. The principle followed by the CJK
registries is exemplary and should be ICANN's recommended standard, be
it for aliases that arise from the top-level label or for alias that
arise from lower-level label.


Werner Staub