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:
- Following the direction of policy advice already provided
- Taking broader community needs into consideration, and
- 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.
- Reserve desired variants & block all other variants; and
- 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.