The User Experience with New TLDs: How to Avoid the Junk Mail file or ‘User Unknown’ Published in CircleID, May 25, 2011, by Architelos CEO Alexa Raad

As new top-level domains (TLDs) are launched, the industry mustn’t overlook the customer experience. A key question is this: Will the software applications we all use, recognize the new TLDs and know what to do with them in a timely fashion? Think email and even form-fill applications. I speak from experience here.

In 2006 when we launched the .MOBI TLD, there were arguably only a handful of .MOBI email addresses in existence. To my dismay, I found that often emails sent only from my .MOBI account were not being received at the other end. The reason: Email applications did not recognize the new TLD, and hence the emails were sent to the SPAM folder of the recipient. Web forms would also reject the email address for the same reason. At the time .MOBI was only one of the handful of new TLDs, which were added to the root.

But if new gTLDs are approved, this will be the first time in the history of the internet that a large number of TLDs are added almost simultaneously. Prior to the mid 1990s, there were few changes to TLDs and their numbers were relatively constant. It was assumed that TLDs were two to four letters in length and that two-letter domains were, with a few exceptions, country code TLDs. The country code list could be pulled from the International Organization for Standardization (ISO) list of codes for countries and similar entities [see IS3166]. So the heuristic rules for validating a TLD worked relatively well and the application developer’s job was relatively easy, as the list of generic TLDs was reasonably constant and could be kept locally and tested. Developers could poll the Internet Assigned Numbers Authority (IANA) list and then update their local list at regular intervals. By 2003 the list of valid non country code included TLDs such as .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO, .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA. A 2004 document titled “Application Techniques for Checking and Transformation of Names” suggests that “the better strategy has now become to make the ‘at least one period’ test, to verify LDH (letters, digits, hyphens) conformance (including verification that the apparent TLD name is not all-numeric), and then to use the DNS to determine domain name validity, rather than trying to maintain a local list of valid TLD names.”

With the release of potentially hundreds of new TLDs, my challenge to the industry is this: What is the most efficient way to communicate the changes and their timing to the application developers soon enough so that the first registrants of the new TLDs and their associated end-users have the same experience as they have now using a well established TLDs? More pointedly, what is the incentive for application developers to update systems and applications in a timely manner?

What we would hope is that developers do so for the benefit of the end-user, but frankly, experience has shown that the big application developers refuse to be at the mercy of registries’ timetables. Do you recall how long it took for Microsoft to update their browsers to be IDN aware?

It seems to me there should be a coordinating body that communicates not only the information about upcoming changes to the IANA table, but does so in a timely manner, giving major developers enough lead time—and perhaps the incentive—to update their applications. ICANN seems to be the best option as the coordinating body to do so, as it would be the first to know the list of approved names. I don’t know if the Internet Engineering Task Force (IETF) has any suggested improvements in the process by which application developers can effectively and easily update their files (local or otherwise) of new, valid TLDs. If they do, greater awareness and education of the new procedure would certainly be welcome.

Lessening the burden on developers by providing timely information, adequate lead-time, incentives and/or effective and updated procedures serves all of us. For the DNS industry, such facilitation would minimize user confusion and dissatisfaction and would bring to fruition the promise of new TLDs—expanded choice and innovation.

I am interested to see what work or procedures ICANN or other groups such as IETF have done in this regard and if those efforts are coordinated.

Alexa Raadis CEO of Architelos, Inc. and can be reached directly at [email protected].