Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
Back in 2014, to foster innovation and to better the choice in domain names, ICANN introduced new generic top-level domains through its New gTLD Program. It was a monumental move that enabled businesses, individuals, and communities across the globe to mark their presence on the Internet.
Allowing users to be present digitally in their chosen language (non-ASCII characters and scripts) gave opportunities to local businesses, civil societies, and governments to better serve their communities.
Analysys Mason conservatively estimates that there is scope of $9.8 billion growth in potential revenue from both; existing users who are using new domain names and from new internet users coming online through Internationalized Domain Names (IDNs).
To achieve this, Universal Acceptance of new gTLDs and IDNs is critical in making the Internet more accessible to the next billion users. Founded in February 2015, the Universal Acceptance Steering Group (UASG) undertakes activities to promote Universal Acceptance of all valid domain names and email addresses.
Through its ambassadorship and local Initiative programs, UASG promotes Universal Acceptance globally. Their efforts are divided and executed through five working groups that include:
Before we get into the acceptance of new domain extensions (nTLDs), we must first understand what acceptance means and how it’s measured.
The Universal Acceptance Steering Group’s mission sums up acceptance in one short statement,
“All domain names and all email addresses work in all software applications.”
While this is a simple understanding of the concept, for an end-user of an nTLD, this statement further branches out into multiple questions such as:
The Universal Acceptance (UA) of all domain names and email addresses requires that every software is able to accept, validate, process, store, and display them correctly and consistently.
As a new domains registry, it was critical for us to understand what the gaps were and how to close them so that the Internet operates the same for nTLD users as it does for the legacy TLD users.
Initial research concluded that UA readiness issues occur when applications are not able to handle the following categories of a domains name or email addresses:
1. Domain Names
2. Email Addresses
For Universal Acceptance to succeed, it needs to be examined holistically.
Over the years, UASG working group members have conducted several gap analysis on programming languages and frameworks, networking command-line tools, web browsers, websites and have made great strides in the acceptance of new domain extensions.
According to UASG’s FY 2020 report, tests conducted on top websites showed that
Two important caveats should be remembered in this case:
However, these results may still be used to compare overall trends.
Universal Acceptance Readiness Report 2020 also segregated test websites as per different categories such as eCommerce, government, education, etc and the results were promising.
Such studies help UASG ambassadors and advocates to identify and focus on websites of a specific category that require immediate attention. We conducted a similar study at Radix, where we analyzed top websites belonging to different categories. These were the results:
While the acceptance rates for new short and new long cases is more than 80% under most categories, we see a drastic dip when a domain is on an IDN TLD. Such comparisons highlight problem areas and provide direction to ambassadors and members who are advocating for Universal Acceptance.
UA is something that affects nTLD users the most. This is why it’s crucial to focus on the feedback that we receive from them. At Radix, we work closely with our users to ensure we have first hand information on any UA-related issues faced by the customer.
The feedback could be about linkification, validation, or acceptance of emails on nTLDs on different websites and platforms. Radix also actively invests its resources in gap analysis by testing various websites and social media platforms. We are also part of the ambassadorship program promoting and supporting local and global UA initiatives.
Here are some of the UASG initiatives that Radix is part of:
At Radix, our objective is to ensure that nTLDs are accepted across websites and platforms. To achieve this, we actively work with UASG and share as many issues, and gaps noticed and reported by customers.
A key objective for most registries is to ensure great customer experience when it comes to their nTLDs and I’ve always admired it when registry operators have actively taken initiative and participated in the five UASG groups mentioned above.
One of the ways to do this is to capture all the queries and complaints reported by their customers/registrar partners and share them with UASG. This will help their support team direct their resources in solving the problems and encouraging those websites to become UA compliant.
When it comes to UA-related issues, registrars are the first in chain to receive a complaint or feedback from the user. Therefore, it’s crucial that their support teams have all the necessary information needed on how to best handle such complaints.
For now, they can:
The UASG is consistently compiling and sharing all the important information needed for organizations and developers to become UA-ready. This is not only about ensuring the readiness of a system to accept certain TLDs or emails, but also about realizing the full potential of an organization by connecting with people and businesses that might not even be on its radar.
Every successful step taken by an organization towards UA readiness is also a step towards equality and inclusiveness on the Internet.
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byVerisign
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.
So UASG is now “trying to close the barn door after the horse has bolted.” Just be honest, particularly to new gTLD registrants who have been deceived and defrauded. ICANN’s new gTLDs program was built on a scam and fraud as ICANN knew, or should have known, since 2003, that most new gTLDs would have usability issues or “fail to work as expected on the internet.” Read Ram Mohan’s illuminating 2014 article on circleid.com. Who, in their right mind, wants a domain name with usability issues? ICANN breached its fiduciary duties (as steward of the global DNS) by adding many of these “failing new gTLDs” to the internet root without warning or even informing prospective registrants about the “usability issues” and has yet to be held accountable. Here are Ram’s Three Rules of TLD Acceptance restated
in plain English for ALL Domain Name Registrants:
1. .COM, .NET, and .ORG domain names will be accepted more than any of the new gTLDs’ domain names.
2. An ASCII-only TLD will be accepted more than an IDN TLD.
3. A two or three letter TLD will be accepted more often than a longer ccTLD or gTLD.
ICANN tried to shirk its responsibility to registrants and the rest of the global internet community via Section 1.2 of its Base Registry Agreement with new gTLD registry operators:
Well, what about ICANN’s duty to inform registrants about new gTLDs’ usability issues? I have yet to see ICANN, or ANY new gTLD registry operator, or any ICANN-accredited registrar, warn or inform registrants of ANY of these known “usability issues” at or prior to the point of registration. Prospective new gTLD domain name registrants should be informed about new gTLDs’ “usability issues” prior to registration!
I read: “new gTLD registrants who have been deceived and defrauded”.
I was neither deceived nor defrauded.
I’ve been doing a lot of work recently on very small devices that usually are covered under the name “system on a chip”.
These things are often buried inside things ranging from household appliances (such as light switches) to vehicle engine control units (ECUs).
Many of these things have minimal memory and processing resources.
And most are under stringent reliability constraints.
These things often have DNS lookup code. That code is often buggy enough (especially when names are mapped into other names via CNAME records. [You would be surprised at how many large systems, such as Linux, are vulnerable to this kind of issue.])
Understandably vendors are going to strongly resist adding multi-script code to devices that:
* Do not present domain names to users
* Will never use any but ASCII names in normal operation.
* Have limited memory and processing resources.
* Must be careful to avoid opening up doors to failure whether through untested or weak code paths or hostile attack.
In the IoT world these notions of “universal acceptance” feel a lot like a mandate to put a swimming pool onto every airplane: unnecessary and likely to be a source of trouble.