Back

Universal Acceptance

Author: Valeria van der Poel
0 MIN READ TIME
4/19/2016
Uncategorized

Earlier on this year, being in the middle of our regular ICANN contractual compliance audit, we received an e-mail from ICANN: “New gTLD registrations – quote requested”. Was this some kind of trick to secretly perform some audit tasks, for example on registrar pricing?

No, on the contrary! It appeared to be one of the highlights in our new gTLD strategy so far. ICANN was searching for a single registrar who could provide them with one domain registration in all new gTLDs, at a realistic price. Their goal: investigating “universal acceptance” – how well are the new gTLDs recognized and supported throughout the internet. Their main interest: IDNs, extensions in a non-Latin script such us Chinese, Arabic or Russian.

What is “Universal Acceptance”?

Universal Acceptance (UA) is the concept of removing all technical barriers that might hinder a user from accessing any name in any top-level domain from any web browser, email client, or other Internet application on any computer or electronic device. I think some examples may clarify this a bit further:

  • Web browser acceptance is defined as “does a web browser support a certain extension?” What happens if you type in a domain name with a new extension? Safari users may remember that it took a long long time before they could visit domains with a new extension without explicitly typing “http://” in front of the domain name. Omitting it made Safari think they were searching for that term, and it opened a search window. Nowadays, most browsers support it correctly.
  • E-mail client acceptance is defined as whether or not an e-mail client supports new extensions. Will e-mail at info@openprovider.newgtld be accepted by both the sending mailserver as the receiving party, and will it end up in the correct mailbox in the end?
  • Application acceptance covers a wider scope. There are huge web applications like Twitter and Facebook. How long did it take until those platforms automatically recognized a domainname.newgtld as a domain name – and automatically created a link from it? Pretty long, to be honest. On a smaller scale, let me ask you a question: does your customer signup form accept an e-mail address containing a new gTLD, let’s say a .photography or .москва? I suggest you check it right now!

With many hundreds and in the future thousands of new extensions this is an important aspect. At this moment, according to ntldstats.com, almost 8 million domains have been registered in the new gTLDs. Still, 65% is reported as “parked domain”, but reverse that percentage and almost 35% – 3 million domain names – is a non-parked site!

Selection of domains

Back to ICANN’s project. From the beginning we have been very transparent towards them: we do not offer all extensions, and they should be aware of the fact that some other extensions have eligibility requirements that ICANN does not meet. The list that they could register, together with our quotation based on our Flat Fee Packages, let them decide to register the domains at Openprovider and we are very proud of that.

From a technical point of view we faced some challenges, as many registries have put the name “icann” on their reserved lists, preventing this domain from being registered. Luckily in nearly all cases we could lift this restriction and register the domains.

In the end, more than 300 different domains have been registered which will be used for all kinds of testing purposes.

The first study: DNS and browser acceptance

The first study performed is a numeric analysis of new gTLD acceptance on the web, on the levels of DNS and browser. The basis of this study is a Google Ads campaign, ensuring a huge test base. Each served ad contained a script to retrieve an invisible image from five random domains and report whether or not it was successful. Together with the web server logs this gives a complete overview of which extensions led to a successful result and those who did not can be tracked down to a DNS-based problem or a browser-based problem.

It seems that 96% of all queries was successful, with no significant difference between the extensions. Just one big exception showed up: IDN support, one of the key points from the research, dropped to 80%. Further analysis showed that this is due to the test method: Adobe Flash was used, and apparently that breaks something when used in combination with Internet Explorer or Firefox. Repeating the test with an HTML5 script brought back the success rate to 94%.

So far, no real surprises or worries. Or, as ICANN’s CTO David Conrad says: “These results were in-line with our expectations. However, there will need to be changes to systems and software to fully leverage the global opportunities these new TLDs enable.”

Even without surprising results on the new gTLDs, ICANN included one ccTLD because of frequent reports of visibility issues: the Israeli .co.il. It appears that this extension is filtered out by Iranian and Syrian ISPs. A similar result was found for .sexy domains in Iran.

For those interested, the full PDF is available.

Future studies

Now that browser compatibility has been investigated, ICANN may want to continue testing support on DNS level. Another study that probably will be performed is one on DNSSEC support: one of the requirements that ICANN puts on registries.

All of these studies are the expertise area of a steering group that is created for this specific purpose: the Universal Access Steering Group or UASG.

There are many more studies on the new gTLDs that are performed by ICANN itself or one of its steering groups or external parties. We have already written about theawareness of new gTLDs, but be assured that every tiny aspect of the current round of new gTLDs will be scrutinized. We will write about any interesting results, so keep an eye on our newsletter and website!

If you plan to attend the ICANN meeting later this month in Dublin, take a look at theagenda: there are a couple of Universal Acceptance-related sessions.

0 Views
0 Likes

Share this:

More Topics Like This

Openprovider response to the vulnerability in Apache Log4j

Openprovider is not vulnerable to CVE-2021-44228 as we don't use Log4j. Learn more about the Log4j vulnerability and its impact on other services.

Read more

Our statement on Net4India’s current situation

The past days, some inaccurate news has been spread regarding Openprovider and Net4India. Read Openprovider's statement on the situation here.

Read more

Follow us on

;
Image not found

Not a Member yet?

Become a Member today and get access to exclusive deals.