Home / Blogs

How Does the Acceptance of All Domain Names in Open-Source Software Look in 2021?

A recent study carried out by Governance Primer on behalf of the Universal Acceptance Steering Group (UASG) identified trends in the acceptance of all domain names in software hosted at Github, the largest open-source repository globally. This research builds on top of previous efforts aimed at identifying the underlying issues that result in problems when different applications need to handle Internationalized Domain Names (IDNs) and new gTLDs, particularly when it comes to email addresses.

The goal was to obtain real-world data on the usage of software libraries, which are prewritten pieces of code that act much like building blocks, providing a specific functionality required by the developer so that they do not have to reinvent the wheel every time a feature needs to be implemented. For example, the Pillow library for Python provides image processing functionalities so that an application in which changes can be made to digital images does not need to have coded from scratch the manipulation of pixels, as well as common features such as transparency, blur, sharpening, and so on.

In the case of domain names, libraries of particular concern are the ones that somehow deal with validation, allowing the input of certain characters and structures, while disallowing others. To give a practical example, our previous research tested the validation of email addresses in the “form” field (often found in contact sections) of the top 1.000 websites in the world according to Alexa’s rankings. These results were subsequently updated in 2020 by another team, and this is what the acceptance landscape looked like:

Test case201720192020
Right-to-left (RTL)8%7%11%

What these results tell us is that the code being deployed on the Web is fairly competent at dealing with new gTLDs of four characters or less, but already starts to struggle with those with longer ones and see a dramatic drop when IDNs are introduced. The question that followed these findings was: what does the landscape look like when it comes to software? While many validation processes are carried out on the Web, several others happen in non-Web applications.

To perform this analysis, the most used coding languages in open-source software were targeted, Java and Python, and a crawler was created to aggregate all valid (as per Guthub’s guidelines) software, extracting their “dependency” file. This file is basically responsible for telling anybody who wants to do any work with a given application what libraries it relies upon so that those can be included in the final software for it to perform its tasks correctly.

While some lists of most used libraries do exist, their methodology is not based on the direct sampling of projects, and not enough metadata is provided for correlations to be made between projects and the libraries they use. This means that it would be hard to map out what projects use an insufficient library and engage with them to stimulate changes to their codebase, implementing a more compliant library compliant with Universal Acceptance. Further, metadata about the projects was collected to generate a ranking of the most relevant applications (based on an algorithm that considered data points such as the number of forks), which is a feature not provided by Github.

Thanks to the “Universal Acceptance Compliance of Some Programming Language Libraries and Frameworks” study, the compliance status of some libraries was already known, and the team proceeded to evaluate the status of others that were deemed to be relevant. In essence, a library that makes use of the newer IDNA2008 standard is “UA-Ready”, while one that makes use of the older IDNA2003 standard is “Not UA-Ready.” There is also the possibility that it follows neither, which leads to a reasonable assumption that it is “Not UA-Ready.”

It is not the case that by incorporating a UA-Ready library, the application automatically becomes able to accept all domain names, as, unfortunately, other factors are involved, including whether the library is implemented correctly by developers. However, this makes decision-making around resource allocation for engagement and remediation much more rational, as priorities can be better established, such as, for example: “testing and reaching out to projects that place highly in the ranking and are likely to be UA-Ready.”

The results are presented below.


“RegEx via annotations” seems to be a popular method of performing validation in Java, which is unfavorable to the UASG’s interests, as it is not a uniform way of validating strings, and any arbitrary expression can be used to make that check. This means we cannot be sure of what kind of processing is being performed under the hood, but it is likely not helping the application become UA-Ready. The most relevant libraries making use of this method are: validation-api ranking at 55th and its derivative hibernate-validator placing even higher at 21st springfox-bean-validators also ranks quite high at 79th.

Dataset: 1.3 million dependency files; occurrence in entire dataset: 70,182; approx. 6%.
LibraryOccurrence (projects)Status
hibernate-validator62963Not UA-Ready. RegEx via annotations; Hibernate implementation ofvalidation-api.
validation-api25190Not UA-Ready. RegEx via annotations.
springfox-bean-validators12501Not UA-Ready. RegEx via annotations; SpringFox implementation ofvalidation-api.
commons-validator4906Not UA-Ready. Relies on a static list of TLDs from 2017.
icu4j886UA-Ready. IDNA2008.
libidn29Not UA-Ready. IDNA2003, deprecated and ported to the Java language as “java.net.IDN”.


Out of the entire Python dataset, the idna module ranks 6th overall in terms of usage, which is a favorable result to the UASG’s interests. It can also be a key argument in engaging with the Python language developers to port that module to the language’s core, replacing the default IDNA2003 implementation. This would be a significant gain to a coding language that is in increasing demand.

Dataset: 450 million dependency files; occurrence in entire dataset: 70,813; approx. 37%.
LibraryOccurrence in projectsStatus
idna70789UA-Ready. IDNA2008.
validators1660Not UA-Ready. Email validation based on Django validator; URL validation based on RegEx.
email_validator1178UA-Ready. IDNA2008.
pyicu243UA-Ready. IDNA2008.
idna_ssl10UA-Ready. IDNA2008.

The complete study can be found at this link.

Many thanks to project contributors Sávyo Vinícius de Morais, Edson Celio Ferreira Araujo, Jonas Mendes Fiorini.

By Mark Datysgeld, GNSO Councilor at ICANN

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



IPv4 Markets

Sponsored byIPv4.Global


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix


Sponsored byDNIB.com