Universal Acceptance and IDNs in the Age of AI-Assisted Coding

01 Oct 2026 | Mark W. Datysgeld

Introduction

Universal Acceptance (UA) has traditionally been framed as a problem of implementation. Long-standing standards already allow for Internationalized Domain Names (IDNs), longer top-level domains, and Email Address Internationalization (EAI), but applications still need to be built with those premises in mind for them to produce the desired results. This places a large part of the burden on software developers, who then need to know which libraries implement these standards correctly and which coding practices reproduce ASCII-only assumptions.

The rapid adoption of Large Language Models (LLMs) for software development may significantly change this equation. As developers increasingly delegate routine implementation work to coding assistants and agents, some of the small technical decisions that determine UA-readiness are also being delegated. This article examines the possibility that improving UA may no longer require reaching every individual developer if the tools generating their code already make UA-friendly choices by default.

Software development today

AI-assisted coding has become increasingly common. The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools in their development process, while 51% of professional developers reported already using them daily (Stack Overflow, 2025).

This change is less drastic than it might sound at first. For over a decade, coding has been optimized with auto-completion and assistive features such as Microsoft’s IntelliSense. At the same time, companies have outsourced the more routine aspects of software development to coders in lower income countries who often don’t work within the same environment as the ones writing the flagship features of the application (Rahman et al., 2024).

For the purpose of achieving UA, understanding where implementation decisions are being made is imperative, be it in the hands of humans or computers. Developers can now increasingly describe an intended function and leave the coding tool to decide how to implement significant parts of it, but this maps more or less onto what was already attractive to outsource: creating forms, validating inputs, connecting APIs, converting data, writing tests. These are exactly the “minor” features where UA often succeeds or fails.

This distinction matters because an instruction can be clear at the product level while remaining heavily underspecified at the implementation level. A developer may ask an AI assistant to "add a field for the user's email" without specifying the handling of IDNA2008, Unicode normalization, new gTLD lengths, and so on. The code produced by the assistant cannot retain this level of abstraction, and ends up needing to make real-world decisions based on its learned defaults and available context.

The mundane decisions blocking Universal Acceptance

Over years of UA research, we have identified that blockers usually emerge exactly at this point. An application may use a regular expression that accepts only ASCII characters, rely on a static list of older TLDs, impose an obsolete maximum TLD length, or use a library implementing an older version of IDNA. None of these choices are a deliberate rejection of internationalization. They are often inherited from examples, dependencies, old code, or assumptions about what a domain name or email address normally looks like.

The Universal Acceptance Steering Group (UASG) produced a significant volume of documentation on this topic, including UASG018A: UA Compliance of Some Programming Language Libraries and Frameworks, UASG033: UA-Readiness of Open Source Code Pilot, and UASG043: UA-Ready Code Samples in Java, Python, and JavaScript. Their logic is straightforward: dependencies create leverage. If thousands of applications rely on the same parser, framework, or validation library, improving that component is more efficient than fixing each application separately. AI-assisted coding introduces another layer above those dependencies because the model may now decide which component to use in the first place.

A 2026 study published in the Findings of the Association for Computational Linguistics tested eight LLMs and found clear preferences in their selection of programming languages and libraries. Models tended to overuse familiar technologies and defaulted strongly toward Python even in tasks where it was not the most appropriate choice. The authors concluded that models often prioritize familiarity and popularity over task-specific suitability (Twist et al., 2026). In other words, coding models develop implementation preferences. For UA, those preferences matter.

Moving the intervention upstream

Traditional developer outreach asks programmers to learn the problem and then implement the right solution. AI-assisted development adds the possibility that those components get selected without the developer even knowing what Universal Acceptance is. The desired behavior is broader than telling models to use one particular library or to avoid regular expressions. Different programming languages, frameworks and application contexts require different mechanisms.

Rather, an AI coding assistant should prefer maintained, standards-aware libraries and frameworks whenever presented with the choice, preferably relying on real-world test data to validate the result. The key is that this behavior should not depend on the developer adding "make this Universal Acceptance compliant" to the prompt. For example, if a developer requests domain-name validation in Python, an AI tool should know to use an appropriate IDNA2008-capable implementation rather than recreating the syntax using an ASCII-only expression.

ICANN has explicitly recognized this possibility. Its August 2026 Guidelines for Advancing Universal Acceptance Adoption include a guideline to "Enable AI tool support", calling for evaluation of AI tools' ability to produce UA-ready code by default, engagement with AI providers, and support for code that correctly inputs, validates, processes, stores and displays IDNs and EAI either by default or with simple prompts (ICANN, 2026).

The question then becomes where this behavior should be introduced into an LLM. Training data is one part of the answer, but not the whole of it. Simply knowing that IDNA2008 or EAI exists does not mean that a model will choose the appropriate solution when the user does not mention them.

A strong intervention can occur during post-training, where demonstrations and preference signals can teach the model which implementation should be favored among several functionally plausible alternatives. Contemporary alignment methods already use supervised examples and ranked outputs to shift model behavior after base pretraining (Ouyang et al., 2022; Rafailov et al., 2023).

UA has an advantage here because much of the desired behavior is testable. Generated code can be executed against datasets containing new and long TLDs, IDNs from multiple scripts, and internationalized email addresses. If one implementation rejects valid cases while another handles them correctly, the distinction hardly ever requires subjective assessment. The aforementioned UASG test cases and UA-ready code samples already provide much of the material needed to construct this kind of evaluation.

This suggests that UA should increasingly be treated as a code-generation benchmark. A coding model should not only be evaluated on whether its program compiles or passes the narrow examples in a prompt, but also on whether commonplace functions involving domains and email addresses end up inheriting outdated restrictions.

At the day-to-day level, this does not even need to wait for LLM providers to act. Coding assistants can already reliably use repository-level instructions coming from files such as “AGENTS.md”. Companies, groups or individuals can just add a single instruction to such files along the lines of “Make a best effort to prioritize maintained libraries, frameworks and implementation patterns with current IDNA2008 and Universal Acceptance support whenever applicable.”

The intervention can therefore exist at multiple layers at once.

Conclusion

There is also a reason for urgency. LLMs learn programming patterns from a software ecosystem that has accumulated decades of ASCII-oriented assumptions. In a previous article in this series, we traced how communications technologies repeatedly inherited the constraints of the systems that preceded them, from printing and telegraphy through ASCII and the early DNS. AI-generated software can either weaken that dependency or reproduce it at much greater speed.

This is therefore not simply a story about automation making UA easier. AI coding tools concentrate part of the decision-making that was previously distributed among millions of developers. That creates leverage, but also concentration risk. A poor default adopted by a widely used model can replicate technical debt across many unrelated applications. A good default can do the opposite.

As coding models increasingly sit between developer intent and concrete implementation, their defaults become another layer of Internet interoperability. A developer should not need to remember the entire history of IDNA, EAI, Unicode processing and TLD expansion every time a form asks for a domain name. If the standards-aware solution is already the ordinary solution produced by the tool, UA can spread without each implementation requiring a new advocacy effort.

Article by Mark W. Datysgeld