Skip to main content

Universal Acceptance Initiative

An Abridged Roadmap

Introduction to the Roadmap

This is the Universal Acceptance Initiative Roadmap originally published on September 11, 2014.

Setting the Scene

The Universal Acceptance initiative is an effort to address potential user issues and obstacles observed in the use of new Top Level Domains, issues and obstacles rooted primarily in assumptions based on the TLD. This abridged roadmap, an outcome of the JIG Final Report on Universal Acceptance of IDN TLDs [PDF, 185 KB] plus other work, presents a proposal, based on community input including public comment, as to how ICANN's energy, resources, and actions should be applied as part of the initiative.

The abridged roadmap emphasizes ICANN's multi-stakeholder model by limiting its scope to ICANN's role and possible actions. Identifying and addressing the issues and obstacles require work and collaboration among many stakeholder groups who have documented their activity independently. ICANN views its primary role as one of active coordination and facilitation, acting as a catalyst in connecting relevant stakeholders with each other and with parties who are in a position to remove these obstacles. The vision includes implementing a 'corporate memory' as a central information depository of progress.

Creating a Sense of Urgency

The primary goal of ICANN's own efforts is to "create a sense of urgency", that is, to motivate stakeholders to take proper independent action. ICANN's efforts should be educational and pro-active, advocating activity that is needed to achieve universal acceptance. ICANN's main role will be the organization connecting those facing obstacles with those that can remove them.

The Goal

The goal of "domain names in a TLD must be useable in applications regardless of the written script, and length or newness of the TLD" roughly captures the observed issues and obstacles driving the discussion of universal acceptance. Nowhere is this more obvious than in the use of names in the IDN TLDs, combining all of the challenges mentioned in the goal as well as touching areas of concerns of generic and country-code TLDs. Registration of names must work, protocols must work, and services/applications impacting the user must work; work also in the sense that domain names and the identifiers built on them are useable in administratively permitted ways. Included in this goal is the usability of internationalized email addresses (RFC 6530).

Introduction to the Initiative

The Context

Preliminary investigations into universal acceptance have given a high-level picture of the challenge. The list of issues and obstacles as documented by stakeholders is highly dynamic. New entries in the list appear and some entries get solved without regard to any pre-determined calendar. Besides being dynamic, the list of what to solve is diverse and sometimes overlapping. Hence teams of stakeholders involved are necessarily dynamically formed, diverse and sometimes overlapping. This is not a project in the sense of traditional project management; a set of deliverables and milestones are replaced with plans for continuous engagements with stakeholders.

The Stakeholders

The roster of individual stakeholders is innumerable. There is a grouping that can be applied to help organize and focus energy.

  • End-user Communities
  • The Domain Name Industry (including Trade Associations)
  • Internet Service and Applications Providers
  • Protocol and Operations Standards and Forums
  • Information Technology Practitioners
  • Security Practitioners
  • Educational Institutions

Each of the stakeholder groups will benefit from universal acceptance and each as a role to play in the process. For each group, the end goal is somewhat different and therefore different approaches and discussions will need to take place. Some groups have a tight focus while others feature diverse interests.

In particular, "End-user Communities", has a very wide range of members. Not to be exclusive but to highlight some more detail on this group, this stakeholder group drives the definition of success. From this group we expect to get definitions of what success is in terms of using a TLD or written script. This group can also provide the drivers for other stakeholder groups by requiring services to meet their needs.

The Gap

With a varied roster of stakeholder groups, there is role to play for an active facilitator. There is a need to capture the list of issues and obstacles as well as successes. There is a need to capture lessons learned by one team and act as a resource to the next team. At times there will be a need for a catalyst in the deployment of solutions.

Elements of the Roadmap

Sustaining Momentum

The actions of ICANN, towards creating a sense of urgency, will focus on sustaining momentum (as it grows) of communications and collaborations among stakeholders involved with universal acceptance. When teams disband lessons of what was done to reach a conclusion is often forgotten leading to the next team to re-learn the same lessons and thus slowing progress and draining forward momentum. Fostering sustainable relationships among stakeholders will be the best way to serve the teams that are involved in the dynamic issues and obstacle space, and helping to create the needed forums for research and work.

ICANN's Role

ICANN's role as part of the initiative is to foster relationships among stakeholders involved with universal acceptance issues, whether the stakeholders are aware of the situation or not, i.e., conduct outreach where it is warranted. ICANN will have one of its focuses on the domain name registration ecosystem to ensure that it, as an enabling sector has adopted universal acceptance. This is a natural starting point, not only as an enabling sector but one where ICANN has existing relationships.

As it is not simply satisfactory that domain names work, ICANN will promote internationalized email as a way to enable full functionality of IDN TLDs. Although the standards for internationalized email are documented, deployment of the technology has reportedly not been progressing.

To build a corporate memory of the progress toward universal acceptance, ICANN meeting sessions will be scheduled in which stakeholders can come to present and/or exchange concerns related to universal acceptance, provide on-line tools, share experiences and solutions with each other.

ICANN will internally elevate awareness of universal acceptance to that of IPv6 and DNSSEC in terms of building it's own internal systems. This will give ICANN the experience of adopting universal acceptance, whatever obstacle might exist in terms of tool availability, and eventually enable ICANN to feature a fully capable information technology infrastructure itself. This will be used as a model of how universal acceptance can be enabled within enterprises.

ICANN will also develop a means to accept reports of problems, as well as successes, to pass information amongst stakeholders for resolution. ICANN will engage stakeholders in the effort to exchange information on universal acceptance, whether this is seen as informational or a means to gain insight into issues and obstacles. ICANN will develop a means to accept reports of problems, as well as successes, to pass information amongst stakeholders for resolution.

One of ICANN's capabilities is to act as a catalyst in raising awareness of the issues in order to derive needed solutions. ICANN will actively engage software developer and service providers on the topic of universal acceptance, providing information on the topic as well as addressing specific issues and obstacles. The aim of this effort will be to further awareness and universal acceptance of new TLDs in general and IDNs.

To "create a sense of urgency" ICANN recognizes that it is important and plans to peer with relevant stakeholders at the decision maker levels. Exchanges of information are not sufficient without the attention of decision makers.

Input is Welcome

ICANN is welcoming comments on the roadmap described. Suggestions to help foster universal acceptance will be appreciated as well as expressions of interest in the topic. Please send comments and suggestions to

Download the PDF version of the Universal Acceptance Initiative Roadmap [PDF, 586 KB].

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."