The popular “emoji” smiley faces are banned as gTLD domain names for technical reasons, according to ICANN.
Emojis are a form of emoticon that originated on Japanese mobile networks but are now used by 12-year-old girls worldwide due to their support on Android and iPhone operating systems.
It emerged last week that Coca-Cola has registered a bunch of smiley-face domain names under .ws, the Samoan ccTLD, for use in an billboard advertising campaign in Puerto Rico.
.ws was selected because it’s one of only a few TLDs that allow emojis to be registered. Coke is spinning its choice of TLD as an abbreviation for “We Smile”.
This got me thinking: would emojis be something new gTLD registries could start to offer in order to differentiate themselves?
Coke’s emoji domains, it turns out, are just a form of internationalized domain name, like Chinese or Arabic or Greek.
Emoji symbols are in the Unicode standard and could therefore be converted to the ASCII-based, DNS-compatible Punycode under the hood in web browsers and other software.
One of Coke’s (smiley-face).ws domain names is represented as xn--h28h.ws in the DNS.
Unfortunately for gTLD registries, ICANN told DI last night that emojis are not permitted in gTLDs.
“Emoticons cannot be used as IDNs as these code points are DISALLOWED under IDNA2008 protocol,” ICANN said in a statement.
IDNA2008 is the latest version of the IETF standard used to define what Unicode characters can and cannot appear in IDNs.
RFC 5892 specifies what can be included in an IDNA2008 domain name, eliminating thousands of letters and symbols that were permissible under the old IDNA2003 standard.
These characters were ostensibly banned due to the possibility of IDN homograph attacks — when bad guys set up spoof web sites on IDNs that look almost indistinguishable from a domain used by, for example, a bank or e-commerce site.
But Unicode, citing Google data, reckons symbols could only ever be responsible for 0.000016% of such attacks. Most homograph attacks are much simpler, relying on for example the visual similarity of I and l.
Regardless, because IDNA2008 only allows Unicode characters that are actually used in spoken human languages, and because gTLD registries are contractually obliged to adhere to the IDNA2008 technical standards, emojis are not permitted in gTLDs.
All new gTLDs have to provide ICANN with a list of the Unicode code points they plan to support as IDNs when they undergo pre-delegation testing. Asking to support characters incompatible with IDNA2008 would result in a failed test, ICANN tells us.
ICANN does not regulate ccTLDs, of course, so the .ws registry is free to offer whatever domains it wants.
However, ICANN said that emoji domains are only currently supported by software that has not implemented the newer IDN protocol:
Emoticon domains only work in software that has not implemented the latest IDNA standard. Only the older, deprecated version of the IDNA standard allowed emoticons, more or less by accident. Over time, these domains will increasingly not work correctly as software vendors update their implementations.
So Coke, while winning brownie points for novelty, may have registered a bunch of damp squibs.
ICANN also told us that, regardless of what the technical standards say, you’d never be able to apply for an emoticon as a gTLD due to the “letters only” principle, which already bans numbers in top-level strings.
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.
You can check out the repository in its unfinished state here.
ICANN is getting involved in a coordination role. After the UASG’s inaugural meeting in Washington DC a few weeks ago, ICANN hosted a session during ICANN 52.
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.
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.
Executive director Kurt Pritz blogged:
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.
Twitter has started recognizing new gTLDs on its web page and on Tweetdeck.
As of some point in the last 48 hours, you can type something like “nic.berlin” or “fire.plumbing” in a tweet and Twitter will automatically turn it into a clickable link.
The switcheroo seems to have happened in the last two days, as this conversation may illustrate.
But there seems to be some delay — about a month, by my reckoning — in the support.
Domains such as nic.sexy, which is in a TLD delegated November 14, become clickable, but domains in more recent delegations such as .okinawa, which hit the root on Wednesday, are not.
Going back through the DI PRO Calendar, it seems that any TLD delegated on February 5 or earlier gets clickable links in Twitter and those delegated over the last four weeks do not.
I’m not sure why TLDs delegated in the last month are not supported, but I imagine it could be an annoyance during registries’ pre-launch marketing.
It’s difficult to overestimate how important application support is for the new gTLD program.
If new gTLDs don’t look like web addresses, there’s going to be a big barrier to adoption. A .link domain that isn’t clickable isn’t much use and nobody wants to have to copy-paste URLs.
Support for new gTLDs for Twitter’s 232 million active users is a big step along the road to universal acceptance of all TLDs, which ICANN has identified as a problem.