Managing variants at the top-level

by Tina Dam on August 21, 2009

Variant top-level domains (TLDs) and how they are managed is one of the most hotly discussed topics we are facing at the moment. What are variant TLDs, you ask? Well, that’s where the discussion begins…

ICANN’s staff is currently producing implementation plans for both the IDN ccTLD Fast Track Process and the New gTLD Process. What guides that process for the topic of variants, is three things:

  1. Following the direction of policy advice already provided
  2. Taking broader community needs into consideration, and
  3. Ensuring the continued stability of the DNS and the namespace in general

In the course of doing this for the issue of variant TLDs there were two different proposals.

  1. Reserve desired variants & block all other variants; and
  2. Delegate desired variants & block all other variants

Following public comment periods on both proposed implementation methods (none were agreeable across the community), it was decided during the Sydney meeting this June that ICANN staff would seek implementation assistance from the community. This is usually the case on policies that have technical implications and hence are difficult to implement.

As a result a small team has been asked to volunteer their time (you can read more about that team and another issue the team is looking at in the post Solving the remaining IDN issues).

Community discussion on this topic is very important as we strive to reach a conclusion that works for all involved. Variant TLD management is especially important to make the introduction of IDNs work well for the end-users. The IDN Tables that hold and define the character variants are the most important piece of the management of variants, as these tables are developed to reduce the potential for confusion to end users by the introduction of IDNs.

In the most recent paper [pdf] published on this topic, a variant is defined as follows:

“Variant characters are two or more characters that are similar in appearance and result in two domain names to be visually confusing.

As such the resulting “variant strings” that are obtained by replacing the original characters with the variant characters, are visually indistinctible and, if used for separate purposes, could create user confusion. In some cases this could result in visually similar strings having the same meaning.

As such, the term “variant” designates orthographic equivalence on the character level, such as that between “æ” and “ae” in “encyclopædia” and “encyclopaedia”, but not in the broader sense that pertains to the variant spelling of words, as “encyclopaedia” vs. “encyclopedia” or “color” vs. “colour”. The IDN Tables that define variant characters are useful because they enable TLD registries to develop registration policies that will reduce the potential for confusion that could result from typographic similarities in domain names.

Recent discussions have suggested that the definition might be better if more technical stringent (for example by following the definition in the JET Guidelines: “One conceptual character can be identified with several different Code Points in character sets for computer use”) and then add various examples of variants, where some are confusingly similar visually and others are not.

The same paper proposed the following way of managing IDN TLD variants:

“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.

“In order to reserve the possibility of allocating variant strings to the appropriate entities, ICANN will ensure that all variant strings are reserved or blocked for allocation for now. Blocked strings will be considered as “existing strings” when incoming requests are checked for conflicts with existing TLDs. Therefore, any later request for the same string will be denied.”

The reservation of desired variants was thought to be the safest way of securing adequate variant management until a solution has been found on how to manage them at the top level. The community response to the temporary solution was mixed. There is a concern in certain regions that a blocking of variants will disfranchise certain user communities. However, at the same time the response received stated that solving this problem should not in any way slow down the Fast Track introduction.

While we continue work on the subject with the industry experts, one thing seem to be clear: variant TLDs will be identified using of the IDN Tables that are required in either a Fast Track request or an IDN gTLD application.

This means that for the sake of the end-users, the usability of IDNs globally, and therefore the adoption of IDNs across applications on the Internet, we better get these tables right!

I have previously blogged about what could be the worst case scenario. We really want to avoid this. We are in the last step of making IDN TLDs a reality for users globally which will be an amazing step for all involved.

{ 4 comments… read them below or add one }

Dave Wrixon 08.23.09 at 10:08 am

Frankly, ICANN actually getting anything up and running would be an “Amazing Step”.

David Cohen 08.23.09 at 10:11 am

Hi Tina,
When can the community expect to see the blocked/reserved variant lists for idn gTLD’s and ccTLD’s?
Will the idn fast track include any idn gTLD’s?

Tina Dam 08.25.09 at 1:41 am

Hi David Cohen, you question is illustrating part of the problem. If we had such list that was agreeable for the entire community then i think the topic of variants would be much easier. However, different language communities have different opinions on whether a character is a variant and not. That can work fine at the second level, but when you move to the top level there need to be a more concise decision on this to avoid confusion and hence instability.

The variant are defined/found via the IDN Tables. IDN Tables exists for some languages and some scripts, but not for all. IDN Tables are required as part of a Fast Track request or an IDN gTLD application. Depending on which characters are used in the requested/applied-for string, and whether these characters have variants, and which ones, we get a list of variant strings. Some of these variant strings are desirable for use and others are not. One of the reason for desired use is that users will either type in the requested/applied-for string or the desired-variant-string, not knowing which one they are actually typing nor understanding the difference between them. Hence in order for IDNs to be _really_ useful, in certain regions, there is a need for for these desired-variants to be delegated as well.

However, as long as we dont know which strings we will get requests/applications for, and as long as we dont have the IDN Tables for all languages or scripts, this is adding to the complication of adding this to the top level.

I dont think we will have any such list or anything close to it in the short term. I think we need to move forward and get some IDN TLDs in the root and then move from there. That can be considered as an unfair advantage to first-movers, however, we also cannot wait for all IDN Tables to be developed in the world, especially considering the changing nature of languages.

Tina

电驴 09.08.09 at 8:38 pm

这一直都是ICANN的重要议题。

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image