A little over a year into the live phase of the new gTLD program, a group of domain industry companies are getting together to make sure the expansion is supported across the whole internet.

A new Universal Acceptance Steering Group has formed, with the support of ICANN and the Domain Name Association, to help fix many of the compatibility problems facing new gTLD registrants today.

“The basic problem is that these new types of domains and email addresses just break stuff,” Google’s Brent London said during a UASG meeting at the ICANN meeting in Singapore last week.

“You try to use an internationalized domain or a long new gTLD, or even a short new gTLD, or certainly an internationalized email address and you’re likely to run into problems,” he said. “What we’re doing is going around asking developers to make their products work.”

Universal acceptance is a long-understood problem. Even 15 years after the approval of .info there are still web sites that validate email addresses by ensuring the TLD is no longer than three characters in length.

But the 2012 new gTLD round has brought the issue into sharper focus, particularly given the introduction of internationalized domain names, IDNs, which use non-Latin scripts.

Over the last year we’ve seen scattered examples of popular software — including browsers, instant messaging and social media apps — not recognizing new gTLD domains as domains. The problems I’ve seen are usually fixed quite quickly.

While I’ve not seen any deal-breakers that would prevent me registering a new gTLD domain, I gather that IDN email addresses are often basically unusable, due to the chain of dependencies involved in sending an email.

In my experience as a programmer, supporting all TLDs is not a particularly challenging problem when you’re coding something afresh.

However, when bad practices have been coded in to large, sprawling, interdependent systems over decades, it could be likened to the Y2K problem — the so-called Millennium Bug that caused developer headaches worldwide at the end of the last century.

There’s also a tonne of bad advice on the web, with coders telling other coders to validate domains in ways that do not support an expanding root.

UASG members think the problem is large-scale and that it’s a long-term project — 10 years or more — to fix it satisfactorily.

Members include Donuts, Google, Microsoft, Go Daddy and Afilias.

The DNA has started creating a repository of information for developers, with the aim of describing the problem in plain English and providing code samples. Along with other UASG members, there’s a plan to conduct outreach to make more people aware of the acceptance issue.

US cable ISP Comcast has become the latest company to experience problems caused by name collisions with new gTLDs.

In this case the gTLD in question is .network, which Donuts had delegated at the end of August.

Users of Comcast’s Xfinity service have been complaining about various issues linked to collisions ever since.

It turns out some Xfinity hubs use the domain home.network on residential networks and that this default configuration choice was not corrected by Comcast before .network went live.

The collision doesn’t appear to be causing widespread internet access issues — Xfinity has close to 20 million users so we’d have heard about it if the problems were ubiquitous — some things appear to be failing.

I’ve seen multiple reports of users unable to access storage devices on their local networks, of being unable to run the popular TeamSpeak conferencing software used by gamers, problems with installing RubyGems, and errors when attempting to use remote desktop tools.

Judging by logs published by affected users, Donuts has been returning the domain “your-dns-needs-immediate-attention.network” and the IP address 127.0.53.53.

Anyone Googling for 127.0.53.53 — the IP address selected to ICANN’s “controlled interruption” name collision management plan — will currently find this ad:

Cyrus Namazi, vice president of DNS industry engagement at ICANN, confirmed to DI that ICANN has received multiple reports of issues on Comcast residential networks and that ICANN has been in touch with the ISP.

Comcast is working on a permanent fix, he said.

Namazi said that ICANN has not received any complaints from users of other ISPs. Most collision-related complaints have been filed by residential users rather than companies, he said.

Verisign is trying to form a new industry standards-setting association for domain name registries and registrars.

To be called the Registration Operations AssociationTM (yes, according to its web site it is apparently already trademarked), Verisign wants potential members of the group to meet in October to figure out whether such an association is needed and what its remit would be.

But the Domain Name Association apparently has other ideas, suggesting in a recent blog post that the DNA would be the best place for these kinds of technical discussions to take place.

In the second of a series of three blog posts revealing the ROA plan, Verisign senior director Scott Hollenbeck said:

The primary purpose of an association would be to facilitate communication and technical coordination among implementers and operators of the EPP protocol and its current extensions to address interoperability and efficiency obstacles.

EPP is the Extensible Provisioning Protocol used by registrars to transact with all gTLD and many ccTLD registries. It’s an IETF standard written by Hollenbeck over a decade ago.

One of the problems with it is that it is “extensible” by design, so every time a registry extends it to deal with a peculiarity of a particular TLD, partner registrars have to code new connectors.

In a world of hundreds of new gTLDs, that becomes burdensome, Hollenbeck explained in his posts.

An industry association such as the formative ROA could help registries with common requirements standardize on a single EPP extension, streamlining interoperability.

That would be good for new gTLDs.

It’s no secret that many registrars are struggling to keep up with new gTLD launches while providing a good customer experience, as Andrew Allemann pointed out last week.

The need for cooperation seems plain; the question now is what is the correct forum.

While Verisign is pushing for a new group, the DNA reckons the task could be best-performed under its own umbrella.

Given its multi-functional and global diversity, the DNA will be an effective place to coordinate discussion of these issues and to involve broader domain name industry involvement.

Verisign isn’t a DNA member. In fact, it appears to be the only significant back-end registry provider in the western world not to have purchased a membership.

But Pritz said in his post that technical discussions would not be limited to DNA members only — anyone would be able to participate without coughing up the $5,000 to $50,000 a year the group charges:

Recognizing that industry-wide issues are… well … industry wide, the DNA Board determined that this work must include those inside and outside the DNA, welcoming all domain name industry members. Scott and others from Verisign and other firms are invited regardless of whether they join the DNA.

So is the industry going to have to deal with two rival standards-setting groups?

In the many years I was a general Silicon Valley tech reporter, I must have written scores of articles about new technologies spurring the creation of competing “standards” organizations.

Usually, this involved pitting an incumbent monopolist such as Microsoft against a coalition of smaller rivals.

It makes for great headlines, but I’m not sure the domain name industry is big enough to support or require multiple groups tackling the same problems.

With resource-strapped registries and registrars already struggling to make new gTLDs work in any meaningful way, I doubt their geeks would appreciate duplicating their efforts.

I don’t know whether the DNA or ROA would be the best venue for the work, but I strongly suspect the work itself, which almost certainly needs to be done, only needs to be done once.

Verisign wants interested parties to meet in Los Angeles on October 16, just as the ICANN meeting there concludes. The meeting may also be webcast for those unable to attend in person.

Called “controlled interruption”, it will see new gTLD registries being asked to wildcard their entire second level of their TLDs to point to the IP address 127.0.53.53.

If there’s a name collision on example.corp the company using that TLD on its network will notice unusual behavior and will have an opportunity to fix the problem.

Importantly, no data apart from the DNS look-up will leak out of their networks — the 127/8 IP address block is reserved by various standards for local uses only.

The registry will essentially bounce the DNS request back to the network making the request. If that behavior causes problems, the network administrator will presumably check her logs, notice the odd IP address, and Google it for further information.

Today, she’ll find a Slashdot article about the name collisions plan, which should put the admin on the road to figuring out the problem and fixing her network. In future, maybe ICANN will rank for the term.

Registries would be able to choose whether to wildcard their whole TLD or to only point to 127.0.53.53 those second-level names currently on their collisions block lists.

In either case, the redirection would only last for the first 120 days after delegation. That’s the same duration as the quiet period ICANN already imposes on new delegations, during which only “nic.” may resolve.

After the 120 days are up, the name collisions issue would be considered permanently closed for that TLD.

If this goes ahead, the plan will allow registries to unblock as many as 9.8 million domain names representing 6.8 million unique second-level labels, according to DI PRO collisions database.

It could also put an end to the argument about whether name collisions really were a significant problem (160,000 new gTLD names are already live and we haven’t heard any reports of collisions yet).

Pointing to the fact that new TLDs, some of which showed evidence of collisions, were getting delegated rather regularly before the current new gTLD round, JAS said in its report:

We do not find that the addition of new Top Level Domains (TLDs) fundamentally or significantly increases or changes the risks associated with DNS namespace collisions. The modalities, risks, and etiologies of the inevitable DNS namespace collisions in new TLD namespaces will resemble the collisions that already occur routinely in the other parts of the DNS.

However…

Collisions in all TLDs and at all levels within the global Internet DNS namespace have the ability to expose potentially serious security and availability problems and deserve serious attention.

JAS calls its plan “a conservative buffer between potential legacy usage of a TLD and the new usage”.

As wildcarding is currently prohibited by ICANN’s standard Registry Agreement (ironically, to prevent a repeat of Verisign’s Site Finder) an amendment is going to be needed, as the JAS plan acknowledges.

The drawback of the plan is that if an organization is relying on a colliding internal TLD, whatever systems use that TLD could break under the plan. The 127/8 redirection is a way to help them resolve the breakage, not always to prevent it happening at all.

For new gTLD registries it’s pretty good news, however. There are many thousands of potentially valuable premium names blocked under the current regime that would be made available for sale.

If you’re an applicant for .mail, however, it’s a different story. The JAS report says .mail should be reserved forever, putting it in the same category as .home and .corp:

the use of .corp and .home for internal namespaces/networks is so overwhelming that the inertia created by such a large “installed base” and prevalent use is not likely reversible. We also note that RFC 6762 suggests that .corp and .home are safe for use on internal networks.

…

Like .corp and .home, the TLD .mail also exhibits prevalent, widespread use at a level materially greater than all other applied-for TLDs. Our research found that .mail has been hardcoded into a number of installations, provided in a number of example configuration scripts/defaults, and has a large global “installed base” that is likely to have significant inertia comparable to .corp and .home. As such, we believe .mail’s prevalent internal use is also likely irreversible and recommend reservation similar to .corp and .home.

In other words, .mail is dead and the five remaining applicants for the string are probably going to be forced to withdraw through no fault of their own. Should these companies get a full refund from ICANN?