[Update 11/02/17] The uasg.tech section, “Become Universal Acceptance Ready” will have resources for source code reviews & unit testing, manual testing, and automated testing. Software and online services are Universal Acceptance Ready when they are able to Accept, Validate, Store, Process and Display all domains and email names. |
Since 2013, the internet namespace has expanded to 1,000+ new top-level domains, like .NETWORK, .GOOGLE, .BIBLE, .中国 and many many more. This expansion is called the new generic top-level domain (gTLD) program, making it possible for domain names to use non-Latin characters like Chinese, Japanese, Hebrew, Arabic, Cyrillic, and other language scripts; this is known as IDNs (Internationalized Domain Names.)
But, not all softwares are yet fully-compatible to work with all of the valid internet domain names today. “Universal Acceptance” describes the requirement for all internet connected systems to accept all domain names. When a software is fully-compatible, it’ll earn the designation of being “UA-Ready.”
To get all websites and apps everywhere upgraded to recognize these newly valid fully qualified domain names that have non-Latin characters and more than 3 characters to the right of the dot has 2 primary challenges, IMHO.
First is the task of raising awareness for the necessity of Universal Acceptance. The existence of new gTLDs has yet to become commonly recognized by the general public and likely unknown in the software developers’ community. The solution to raise awareness is on-going marketing, communicating, educating, until one day, new gTLDs become a normal part of every day life for how people use the internet. But it’s not enough to know what the internet specifications and requirements are.
Secondly, the implementation of the software updates’ code base to become UA-Ready will differ from software to software. I believe what can accelerate this would be readily available resources and example code that makes it easy for developers to incorporate Universal Acceptance into their existing code, without hours upon hours of work. For instance, when someone comes up with a RegEx expression that is sufficiently robust to be UA-Ready, that’ll be really helpful to a lot of developers.
This is a list of example emails that can be used to test if the email portion of your software is UA-Ready:
info1@ua-test.link info2@ua-test.technology info3@普遍接受-测试.top info4@ua-test.世界 测试1@ua-test.link 测试5@普遍接受-测试.世界 دون@رسيل.السعودية
* This list of example emails are taken from Evaluation of Websites for Acceptance of a Variety of Email Addresses (UASG017), a study conducted by the UASG (Universal Acceptance Steering Group). Out of 749 websites tested, only 7% (54) were accepted all 7 types of emails.
Here’s the code repositories I’ve found so far–(note: just using these may not get your code to be UA-Ready):
- ICANN’s Universal Acceptance Toolkit for C#, C, Java, Perl, Python (note: this code does a lookup over a live internet connection)
- NPM JavaScript package repository for email validation – isemail() – claims to support all domains
Your help would be most welcomed. Please add a comment with other useful coding resources for how to become UA-Ready.
Ed.Note: This blog post will be updated with developer resources that are quick and easy to implement, something like plug and play, so that upgrading websites and apps to be UA-Ready will be simple. Stay tuned.