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.

For example, current practice dictates that gTLDs contain at least three characters – two-character Latin TLDs are reserved for country-code top-level domains (ccTLDs). However, in certain languages (you probably can think of more than one) one or two characters commonly express a complete word – and they would not be confused with present-day ccTLDs.

Prohibiting the registration of names of less than three characters in certain languages may hobble IDN use in certain languages but it is difficult to fashion a uniform set of rules to govern a potential relaxation of this requirement that works universally.

ICANN’s approach to this issue is similar to its approach on many issues regarding implementation of the policy for the introduction of new gTLDs.

1. Get expert advice on the matter. The use of experts allows ICANN to obtain experience and skill economically outside its core competencies and develop material for public discussion in a timely manner.
2. Use that advice to formulate some sort of model.
3. Then conduct public discussion on the issue (the discussion is clarified by existence of a model).
4. Iterate the model and hold another round of public discussion.
5. Iterate the model, and so on.

This process has been used effectively thus far in the new gTLD implementation. ICANN has consulted with: technical, DNS, risk management and linguistic experts, dispute resolution providers, and others.

In this case of character limits and IDNs, ICANN is engaging a small team to evaluate this problem and provide expert advice from both sides of the problem: that IDNs must be effectively engender regional participation and that the rules must provide stability, i.e., that the domain name system (DNS) work in a way predictable to users.

Given the importance of the issue, we saw a large number of volunteers – all of them competent to take part – but from which only a few of which were chosen for the team so initial advice could be developed relatively quickly.

That not to say that those not in the team can’t participate effectively now and in the future. Right now, there are a number of comments on the issue but no jointly developed advice or model. The small working group is intended to move the discussion forward — but not conclude it. Rather, it will provide additional material for all those who are interested in ensuing discussion in ICANN meetings and public comment fora.

Again, that process for reaching implementation: identify issues, get expert advice, create a model for public discussion, discuss, iterate the model, and so on.

The idea is that the experts crystalise the discussion in a timely way and therefore encourage meaningful participation.

We are at step number two of this process that will include all interested parties. The process for developing a preliminary set of assumption will be publicly reported so the ensuing public discussion can be informed and timely.

Everyone at ICANN appreciates the comments made on this particular issue and other IDN issues – all going toward an effective way to increase effective regional participation in the Internet.

Yesterday, they were in New York; tomorrow, they’ll be in London. Then Hong Kong on 24 July and Abu-Dhabi on 4 August (see here for more details). The idea is to spread the word as well as gather more input on the process. And the biggest bone of contention at the moment is the issue of how to deal with trademarks with a whole new raft of Internet extensions.

The New York meeting was visible online using our new conferencing software that we also used at the Sydney meeting, which includes video, audio, presentations, a chatroom and a Q&A box. And you can see a full archive of the meeting in links below.

What was most interesting out of the discussions (from my perspective anyway) was a blog post produced by the New York Times on the day. It is a pretty good summary of events and also helps put it in context. It’s useful to get the outside view when you spend too long in the ICANN bubble.

The post, Brokering Peace Between Brand Owners and Domainers, pretty much hits the nail on the head when it comes to a lot of ICANN’s work – particularly from the staff perspective, where a huge amount of the work is trying to find a solution that people with strong and opposing views can live with.

Anyway, an interesting piece, have a read when you have a second.

The video archive of the New York meeting is available in four parts:

Part I: Run through of the Trademark Protection report produced by the Implementation Recommendation Team
Part II: Reports from WIPO and eNom on the trademark issue
Part III: Public feedback and questions from the floor
Part IV: Malicious conduct panel discussion

And the archive for the London meeting is also in four parts:

Part I: Intro and summary of the IRT report on trademark protection
Part II: WIPO recommendations on trademark protections; eNom reflections on IRT report. Other reflections on IRT report and other suggestions for solutions to trademark issue. Some questions from the floor
Part III: Public feedback and questions from the floor
Part IV: Malicious conduct panel discussion

With Sydney opening on Monday 22 June, we strived to have this information up before this morning, Monday 1 June.

As such, it is probably as comprehensive a set of documents as ICANN has published for any meeting – addressing hard issues on IDNs, an important report on intellectual property issues as related to domain names, another huge piece of comment and analysis related to new TLDs, new financial analysis, more on community travel (which is coming), and other areas. I’m also pretty confident that this is the earliest (relative to an ICANN meeting) that this kind of material has been available.

So what was included?

IDNs: We posted the third revision to the Fast Track Implementation Plan. This was accompanied by explanatory memos that discuss: the form of agreement we will have with IDN TLD operators, financial contributions to ICANN, and the use of variant tables. The bottom line – we plan to launch this process right after the meeting in Seoul.

New gTLDs: We posted the Analysis of public comment, as we did before the Mexico City meeting. This document is intended to demonstrate ICANN’s careful consideration of all the comment. We decided to not publish a new version of the Guidebook since the overarching issues are not yet resolved.

Instead, we have identified several areas where the Guidebook can be amended and published excerpts – just those sections that are changing. We also published explanatory memos: discussing whether Chinese, Japanese, and Korean TLDs should be allowed to register one or two-character names since complete words in those languages are generally that short; describing all the research that has been done regarding morality & public order issues; describing a process for contractual compliance in community-based TLDs; and advocating a requirement that registries maintain thick Whois databases.

IRT and Trademark Protection: The Implementation Recommendation Team was created by a resolution of the Board to develop solutions to trademark protection issues. The IRT made its final report, it was posted yesterday. The report represents a ton of work by the 18 members of the team for which we are very grateful.

As an ICANN staff member closely associated with this important and huge amount of work, I would like to thank everyone from staff and the community that worked so hard in making it possible to publish this in time for review and discussion in Sydney.