Mapping and Variants

John C Klensin klensin at
Mon Mar 9 22:42:43 CET 2009

--On Monday, March 09, 2009 14:30 -0700 Tina Dam
<tina.dam at> wrote:

> Hi everybody, sorry for catching up late on this thread. I was
> a bit occupied last week at the ICANN Mexico meeting.
> The IDN Guidelines correctly states that mixing of scripts is
> not allowed at registration time unless there is a linguistic
> reason for doing so (such as in the case of Japanese). It
> should further be noted that while the IDN Guidelines are not
> a requirement for ccTLD operators today (but only for gTLD
> operators) - it will, looking forward be a requirement for any
> new TLDs allocated in either the new gTLD Program or the IDN
> ccTLD Fast Track Program.

Of course, they are, at best, suggestions for any zone below the
second level.
> In these two processes it is also a requirement for applicants
> to develop and submit their IDN Tables (this is ICANN
> terminology for where variants are identified). While TLD
> operators can choose to block, bundle, reserve or otherwise
> deal with variant strings at registration time, ICANN have
> proposed one method forward when it comes to the top-level,
> that is:
> - strings will be allocated if they have the same meaning as
> the applied-for string (for example a country name) and
> otherwise fulfill all the string requirements.
> - all other variant-strings will be blocked for allocation.

"Will be allocated" as in "you intend to put more than one entry
per application into the root zone"?  

 -- If so, do you intend to enter them as delegation records
(i.e., same entity gets two or more new TLDs)?   If so, what
requirements do you expect to impose on the relative uses of the
two (or more) TLDs?

 -- Or do you intend to put DNAME records into the root?

 -- Or perhaps associate the extra, variant, labels with DWIM
records pointing to the applied-for label?   I don't think the
DWIM record has been entirely defined yet, but I believe that
DNSEXT should be able to finish it up on the first day of next
month, after which it should be just a small matter of

> I am wondering if there is anything in these processes or
> requirements that could be made stronger from a technical
> standpoint and help the IDNA process forward?

I think they are just another example of guidance to registries
with, in this case, ICANN acting both as the generator of the
guidance and the registry applying it.

But I am really curious about what the words actually mean.


More information about the Idna-update mailing list