Many software applications rely on validation routines to check the validity of domain names. By validation, I mean here to test the string submitted by the user and see if it matches a pre-defined pattern. A typical example are web forms that need to validate e-mail addresses.

This is by no means a new issue. It first appeared with the introduction of the .info TLD. Before that TLDs were only two or three letters long, and many validation routines could not cope with the 4 letters of .info. At the time, ICANN had developed a testing tool which allowed developers to test if their code took into account the requirement for 4 letters. Still, you find today on the Internet tons of library routines that do not support 4 or more letter TLDs.

Some of these routines also rely on a hard-coded list of TLDs. Even today, I sometimes find that some web sites cannot deal with my .eu domain, which was introduced 4 years ago.There are hundreds of thousands of these routines written in Javascript, PHP, Perl, ColdFusion, ASP and just about any programming or scripting language you can think of.

In the Draft Applicant’s Guidebook to new gTLDs, ICANN has clearly indicated that it does not guarantee universal acceptance of the new TLD, and rather place the burden on the registry operator to educate its customers. This made sense during the previous new TLD rounds, where there were only a few added, one at a time and with long intervals between them.

With the new gTLD round, ICANN plans to add a lot of TLDs, potentially at very close intervals, if not at the same time. The figure most often heard is 500. That is a quantum leap forward. All those hard-coded lists deeply buried in software will need to be updated. It will not happen overnight. It may take years. This time also, we are throwing into the mix TLDs which could be long strings, like .coca-cola. We are also adding IDN (internationalized Domain Names) in non-ASCII characters, which will be a real issue with all environments that do not process double-byte strings. There are tons of legacy applications that do not support that, and some never will.

The good news is that programmers do not need to worry about their job. There is plenty of work ahead. The bad news is that most of them are not aware of these upcoming TLDs, let alone the implications it will have on the code they wrote, or the code they use and written by someone else.

So, it does not make sense now for ICANN  just to say it is someone else’s problem. If the new gTLDs cannot be processed on the client platforms, this will mean their acceptance by the user community will be low. This means less revenue for registries, registrars and finally ICANN. This would also mean a partial failure of the whole new gTLD program, for which ICANN will be accountable for. It could cost ICANN much of its credibility, because it would not be the failure of one specific TLD for which the registry could be blamed, it would mean the failure of several, all for the same reasons.

Hence, I suggested today to ICANN to plan a workshop at the Seoul meeting to help identify these issues, so that clear guildelines can be given to the software community and an awareness campaign can be launched. It is absolutely crucial to identify the issues, the amount of work they represent and the time it will take to fix the code before the introduction of these new top level domains.

The IRT has released a draft report.  The composition of the  team is strongly biased towards North American intellectual property interests. Unfortunately, individuals were not represented.  Neither were potential new gTLD operators.  There was only one US-based registrar present and only one incumbent US-based registry.  In summary, this report is partial, both because it does not cover the whole picture and because it is strongly biased towards the interests of a specific group.

Quite confusingly, it was published on 24th April, with a 30 day comment period. However, one needs to comment before 6 May if it wants the IRT to consider the comments. Strange tactics.

As others have pointed out, the effective 7 day comment period over this draft report is way too short. It may be wise that the ICANN board does not consider this report before the community has had a real opportunity to comment.

I totally support Michele Neylon’s comments on the whois model  contemplated by this report. It would be in breach with many privacy regulations throughout the world. Further, if the ability to comply with the whois recommendations, as set forth in this report, would become one of the evaluation criteria for the new gTLD applications, this would favour registry operators located in countries with little or no privacy laws. This would put at a competitive disadvantage those businesses which need to comply with local laws. Questions to the IRT:

• Did the IRT consider if their recommendations regarding the whois were actually compliant with relevant legislation throughout the world ?
• Will the ability to comply with the whois recommendations, as set forth in this report, be a part of the evaluation process of new gTLD applications ?

Regarding the IP clearinghouse, it is stated that “The recommendation should not result in unnecessary or undue costs, either to trademark owners or to legitimate users and consumers”. Does this mean that the registry operators will have to bear all the increase of their operating costs for protecting third parties interests? The net effect of this is that operators will need to shift the increasing cost among all their customers, including those who have no IP rights to protect. This will mean raising the unit price of domain names for every customer, making the TLD less attractive and potentially be a cause of registry failure. In the case of community-based TLDs that focus on a limited market through a not-for-profit model, this may simply mean that the potential costs  and legal risks may be disporportionate for them to bear.

There is a major concern that different levels of protection for marks may put the registry operator in a position to have to arbitrate between second level domain name  applications and become legally involved in disputes between third parties. Unlike trade marks, which can be multiple according to industrial sectors and geography, domain names are by nature globally unique. As technical operators, registries should have no business in deciding who is the legitimate intellectual right owner.

If such IP clearinghouse system is put in place, it should, at a minimum:

1. Be automated and implementable at a marginal cost by registries and registrars
2. Exempt the registry operators from further legal consequences if it has demonstrated that it queried the database at registration time.

In addition to the above, I think it would be only fair that whatever policies are decided as a consequence of this process are also made mandatory for the existing gTLDs. The new entrants should not be the only ones having to bear the weight and costs of these policies.