1. An Introduction to Universal Acceptance
Presenter Name / Event Name / DD Month YYYY

2. UA in a Nutshell
People from around the world can effectively use any domain name and any address in any application for their personal and business use.

3. The Internet Has Evolved
2006
2016
Generic
(22 total)
Country Code
(Over 200 total)
Generic
(Over 1,200 total)
Country Code
(Nearly 300 total)
.com
.edu
.uk
.jp
.com
.edu
.org
.uk
.jp
.org
.net
.de
.fr
.net
.aero
.info
.de
.cn
.aero
.asia
.cn
.in
.bank
.bar
.club
.in
.br
.mobi
.travel
.br
.mx
.car
.global
.london
.рф
.台灣
.info
.rio
.vote
.sky
.한국
.ଭାରତ
.संगठन
.在线
.ابوظبي
.닷넷
.ストア
. дети
The Internet is growing increasingly complex with more users, professions, industries and scripts than ever before.
Since 2006, the landscape for domain names has changed markedly – in overall number of top-level domain names (TLDs), TLD character length and TLD scripts. But the majority of Internet-enabled applications, devices and systems are often still developed using rules created over 20 years ago. On top of that, while most people in the world are not native English speakers, 56 percent  of all websites are in English.
The Internet is adapting so that we can continue to expand the Internet for more people.

4. What’s Changed .amex .ファッション .aaa .ভারত .公益 .москва ‏.קום .asia ‎
More Top-Level Domains (TLDs) available
No longer just two or three characters
No longer just in ASCII
List of TLDs is no longer static. Names added and deleted frequently.
Mailbox names also no longer just in ASCII
.accountant
.asia ‎
‏.كوم‎
.amex
.ファッション
.aaa
.ভারত
.公益
.москва
‏.קום
These changes really started happening in 2010 with the introduction of IDNccTLDs, got accelerated in 2013 with the introduction of more than 1000 new gTLDs and further advanced in 2014 with the introduction of the first EAI ready commercial system.

5. But… It Doesn’t All Work Together X X
Bank X
Not a valid address.
In 2017 only 8% of the top websites could handle our sample set of non-English addresses and top-level domains longer than the traditional two or three English characters.
Only one of the top browsers met all our evaluation criteria.
In some ways, this is a hidden problem, but a significant issue nonetheless. 
UA points to the way you might expect the Internet to work globally, yet it doesn’t right now. 
However, this issue can be addressed quite easily. 
Details on the stats:
The “Evaluation of Websites for Acceptance of a Variety of Addresses” report (UASG017) found that of the 749 websites tested, just 7 percent passed all the test cases, which included attempts to register seven diverse types of addresses – both in non-English language and those with top-level domains longer than the traditional two or three characters.
After testing 17 URLs in eight browsers on six different operating systems, “The Universal Acceptance of Popular Browsers” report (UASG016) found only one – Internet Explorer – was fully UA-compliant. The majority had challenges with non-English domain names. In these cases, the browser either displayed search results instead of loading the expected web page or did not render URLs properly in the tab title bar.

6. The Role of Universal Acceptance
UA- ready
Welcome to organic
TOKYO
Bank
SOAP
当社の製品を購入します
We make the best soap in the world. It’s 100% organic.
validated. Account created.
Not ready X X
Bank X
Not a valid address.
Universal Acceptance is a key aspect of accelerating the expansion of the Internet.
Through UA, and by making systems UA-ready, Internet users can be assured that all domain extensions and addresses – regardless of character length or script – can be used by all internet-enabled applications, devices and systems.
These are examples of UA and non-UA ready sites to illustrate the issues that can arise if unaddressed.

7. Let’s See… Try to send an email to: kōrero@ngāpukapuka.nz
(On an iPhone or Mac, hold down the ‘o’ to choose ō and hold down the ‘a’ key to choose ā)
Test your own address -
Presenter should use their own EAI ready address for this example.
The goal here is to see if people’s existing systems are able to send an to an EAI ready address. Those who use Gmail or Outlook.com should have no problems. Outlook 2016 also works. As at November 2018, those using Appl , Yahoo, Yandex or many other applications will not be able to do this.

8. Anatomy of an email address
Username/ 测试5
Mailbox name
Can be in ASCII or Unicode
Second and lower-level domain names (example/ 普遍接受-测试)
Can be ASCII or Unicode
Unicode can be represented as Unicode U-label or ASCII A-label
Top-Level Domain name (.com/.世界)
Unicode can be represented as U-label or A-label
Can be 2 to 63 characters long
Validate from the DNS, not obsolete static lists
Presenters can substitute an address of their choice for the Chinese addresses shown here.

9. Universal Acceptance | Real World Benefits

10. Economic and Internet Accessibility Benefits of UA
There is a combined USD 9.8 billion annual opportunity coming from software systems working in harmony with the common Internet infrastructure. This is a conservative estimate.
Support for IDNs, which allow domain names in all of the world’s languages, could bring 17 million additional new users online. These include users whose lack of local language services was previously a barrier to a complete online experience.
There is a combined USD 9.8 billion annual opportunity coming from software systems working in harmony with the common internet infrastructure. This is a conservative estimate.
This number is derived from:
3.6 billion of potential revenue from existing users using the new domain names
6.2 billion potential revenue opportunity from NEW internet users coming online through Internationalized Domain Names (IDNs).
The language benefits from IDNs may be particularly important towards increased growth of the Internet. With the widespread availability of mobile broadband, the availability of Internet access in emerging regions is no longer the impediment it once was – instead, the challenge is to increase interest in the Internet to convince non users to adopt, and existing users to increase their usage. As such, local content, relevant to local interests, is key, and language is a significant element of locally created content.
English language content far outweighs English speakers in general, as well as English speakers online, whereas languages such as Chinese and Arabic are significantly underrepresented online. Increasing the ability to use domain names in those languages with UA would help decrease these unbalances, and bring the cultural, social, and economic benefits of the Internet to everyone, not least the software and application providers who accept the new domain names.
(methodology breakdown below)
How did you arrive at the USD 3.6 billion revenue opportunity for online purchases?
This is specific to existing users.
First, we broke it down by estimated spend per address (not per user), which we estimate to be USD 360 per annum.
To get this, Statista estimates the global e-commerce revenue is USD 1, 548 billion and Verisign and Radicati estimate there are at 4.3 billion addresses. This gives us an average revenue per address of USD 360 per annum.
Then, we then calculated the proportion of those that are based on new gTLDs to create a high-level estimate of the total e-commerce revenue that could potentially be generated by all users of the new domains if the retailers accepted all registrations with new gTLDs.
To get these numbers, we multiplied the average number of addresses per domain (13) by the total number of domains registered using gTLDs (11.7 million). We then multiplied by the proportion that do not accept the new gTLDs (13%), and then by the assumed proportion who don’t have multiple addresses (50%).
We then multiplied that by USD 360 to get USD 3.61 billion.
To determine the proportion of this that could be unlocked with UA, we multiplied by the proportion of e-commerce websites that are not currently UA-ready (13%).
Assuming .club’s findings are representative of gTLDs across the board, they tested 600 popular websites to determine if the applications running on them accepted the use of the .club domain. The websites included free services, retailers and e-commerce websites, travel sites, social networks, newsletter services and music services. 13% failed to accept .club, showing that these sites have not implemented UA.
This yields a potential revenue of USD 3.6 billion per annum globally, just in the first year.
Note - this figure does not take account potential future growth in e-commerce spend, or in the registrations of the new domains. It is therefore a conservative metric.
How did you come up with the USD 6.2 billion per annum from new Internet users?
The USD 6.2 billion per annum specifically looks at the five language groups and the additional increase of Internet services among non-users. We then multiplied the number of new users by USD360, which is the global average spend for online purchases.
Again, this does not take account of future growth in online spend per user, nor the other languages benefitting from UA, and as such is a conservative estimate.

11. UA Benefits
If left unaddressed, businesses and organizations face the potential of lost revenue, lost customer satisfaction and more.
Ensuring readiness to accommodate the use of new domains and writing systems will:
Connect the next billion Internet users
Bring better accessibility to the world via internationalization of the Internet
Enable culture, society and economics
Deliver a better UX, resulting in customer satisfaction and retention
Responsibility to comply with standards
Provide uninterrupted support for users of new domain names
Reduce customer support burden
Businesses have a responsibility to be make sure their systems work with the common infrastructure of the Internet – the domain name system. When businesses are UA-ready, it means that their systems and services will work harmoniously with the continuously expanding domain name space and will help set those organizations up for future opportunities and success.
UA-ready websites, applications, and services provide leads to a better user experience. When a company is UA-compliant, addresses in any language from any extension will reach their destination, and not bounce. When a site is UA-compliant, it will allow customers with new TLD suffixes to use the site and its forms without any issues.
For example, if customers are unable to complete a transaction as a result of their domain extension not being recognized by a company’s website.

12. Why Bother
Allows people to use their preferred identity through the new TLDs
Seamless acceptance of all domain names and all addresses – reduced support costs
Better cultural connection – particularly to non-English speaking communities
Responsibility to comply with standards
Remediation is not onerous
From Analysys Mason White Paper -
This information is from the UASG WhitePaper

13. Key Organizations Engaged with UA
UA is such an important issue that the world’s leading technology firms are devoting time, resources and technical expertise to helping companies become UA-ready. Companies such as Apple, Google and Microsoft are quite advanced in the process of making sure their websites, apps and services can be used by any valid domain name – new or old.
Most recently, we developed use cases for Microsoft, APNIC, ICANN and THNIC which we can share with you once published.

14. UA Progress and What’s Ahead
Reference documents and resources
Use and test cases
Industry events and university course slides
Social media and software & services evaluation and programming language remediation
Influencer outreach and encouraging providers to adopt current standards
Key reference documents and resources
Use and test cases
Industry events
Automated Evaluation tool development for vendors
Influencer and media outreach

15. Better UA = Better user experience
Better support for non-English speakers
Better support for screen readers (accessibility issues) URL:  [naturalreaders.com] Test String 1: You may reach me at Test String 2: You may reach me at

16. Five Verbs to UA Readiness
Accept
Validate
Store
Process
Display

17. About the UASG Universal Acceptance Steering Group
Founded in February 2015
Tasked with undertaking activities that will effectively promote the Universal Acceptance of all valid domain names and addresses
Comprised of more than 170 companies (including Afilias, Apple, CNNIC, Go Daddy, Google, Microsoft, THNIC and others), governments and community groups

18. Enabling Universal Acceptance
Doers
Developers
Systems Architects
Directors
CIOs
Senior IT Management
Influencers
C* Suite Officers
Thought Leaders
Government Ministers and Officials
UA is a multi-stakeholder issue.
Developers of software that connects to the Internet’s domain name system and application developers have an important role to play in ensuring the adoption of UA as software and application design are fundamental to its success.
For CIOs, UA can help their company reach new audiences and create new revenue opportunities. Implementing UA removes the risk of customer denial of service.
Governments, public sector organizations and NGOs also need to be aware of UA and ensure their websites and other online properties are compliant to prevent the disenfranchisement of their constituents and stakeholders as the uptake of new Internet domains continues.
Governments, public sector organizations and NGOs have an opportunity to broaden the delivery of online services by ensuring their online properties are UA compliant.

19. Inventory of Material Fact Sheet FAQs White Paper Webmaster Letters
Local Engagement Model
Knowledge Base
Quick Guide to UA in multiple languages
Use Cases
Relevant RFCs
Detailed Technical Documentation
Tender & Contract clauses
Quick Guide to Linkification
Blueprint for CIOs
Programming Language Criteria
Browser Evaluation
Website Evaluation
Slide Deck – UA
EAI Evaluation Study
Case Studies
Blog Posts
Generic Presentation Deck
Customisable Blog Posts
Slide Deck - EAI
Videos
Highlight that there’s a lot of material available, including customizable blog posts.
Become a local hero and expert.

20. Moving forward Test your own email address Secure an EAI address
Use DataMail or Install DataMail App
Use Cor
Get your own systems evaluated and fixed
Use UASG Blueprint for CIOs as a guide
Get your tendering and contracts to include UA Readiness Clauses
Use UASG Quick Guide to Tendering clauses
Report UA problems with other applications
UASG Issue Logging
Participate in the UASG Discussions
Join the UA Discuss Mailing List

21. Principles of Universal Acceptance
What Does “Universal Acceptance” Mean?
Some software does not recognize or correctly process all domain names and all addresses. Domain names can include strings in the top-level position that are longer than the older familiar ones, and domain names and addresses can now use characters drawn from a much larger Unicode-based repertoire than traditional ASCII1. Universal Acceptance (UA) is the state in which all valid domain names and addresses are accepted, validated, stored, processed, and displayed correctly and consistently.
The Universal Acceptance Steering Group (UASG) is a community-led initiative working on creating awareness and identifying and resolving problems associated with the universal acceptance of all domain names and addresses. Its goal is to help ensure a consistent and positive experience for Internet users globally. It is supported by ICANN (the Internet Corporation for Assigned Names and Numbers) and has participants from more than 200 organizations around the world, including Afilias, Apple, CNNIC, GoDaddy, Google, Microsoft, and Verisign. For more information on the UASG and recent developments, visit:
1ASCII is the character encoding historically used on the Internet, defined in the Internet standard RFC 20 ( Unicode is defined by the Unicode Consortium (

22. Accept UASG Recommendations
Input fields should be large enough to accept any valid input.
Applications and services should accept UTF- 8 encoded domain names and addresses.
Software should accept both A-labels and U- labels but convert A-labels to U-labels for display and for any processing that does not require A-labels.
In almost all cases an entered domain name or address should be converted into Unicode Normalization Form C (NFC) before further processing.
Process by which a domain name or an address is received from a user interface, file, or API (application program interface) to be used by a software application or online service.
UASG Recommendations
Input fields should be large enough to accept any valid input. Depending on how it is encoded, a domain name can require as many as 670 bytes. An address can have a local part (the part before of up to 64 bytes in addition to a domain name, for a total length of up to 735 bytes.
Applications and services should accept UTF-82 encoded domain names and addresses, and should recognize that the number of bytes occupied by the UTF-8 encoding may be greater than the number of displayed characters.
An IDN can be entered and displayed either in its original script or in an ASCII version designed for backward compatibility; for example 测试 and xn--0zwm56d. The Unicode encoding of the original script is called a U- label3; the equivalent ASCII-compatible encoding is called an A-label. Every A-label corresponds to one U-label and vice-versa. Software should accept both A-labels and U-labels, but convert A-labels to U-labels for display and for any processing that does not require A-labels.
In almost all cases an entered domain name or address should be converted into Unicode Normalization Form C (NFC)4 before further processing. Because NFC is not perfectly lossless, in rare circumstances it may be necessary to defer normalization until further processing has established the specific context(s) in which it should be applied.
2UTF-8 encodes each Unicode code point as a sequence of one to four bytes. It is defined in RFC 3629.
3Conversion between U-labels and A-labels is accomplished by the “Punycode” algorithm defined in RFC 3492 and RFC 5891.
4See Unicode Standard Annex #15, “Unicode Normalization Forms” (

23. Validate UASG Recommendations
All domain names should be validated against the Internationalized Domain Names in Applications standard, currently IDNA2008.
If an input string is expected to be an existing entry in the DNS, validate it with a DNS lookup.
Because the local part of an address is defined only by the mail system that receives mail, it is generally not possible to validate it. Asking the user to enter the address twice may detect typing errors.
In most cases, all of the components of a domain name or address (except the TLD name if it is not an IDN) should be in a single script or closely related scripts.
Process to check an address or domain name for correct syntax and, when appropriate, that a name that is expected to exist in the DNS actually does. Validation techniques may need updating to work with modern domain names and addresses.
UASG Recommendations
Input should be validated in a manner appropriate for its intended use. All domain names should be validated against the Internationalized Domain Names in Applications standard, currently IDNA This ensures that the name is syntactically valid.
If an input string is expected to be an existing entry in the DNS, validate it with a DNS lookup.
If an input string is expected to be a valid domain name that might not (yet) be in the DNS, it may still be possible to validate part of it. For example, the top-level domain (TLD) name can be checked against the authoritative list of valid TLD names maintained by the Internet Assigned Numbers Authority (IANA)6.
To validate an address, validate the domain part as described above. Because the local part of an address is defined only by the mail system that receives mail, it is generally not possible to validate it. Asking the user to enter the address twice may detect typing errors.
In most cases, all of the components of a domain name or address (except the TLD name if it is not an IDN) should be in a single script (e.g., Arabic or Han) or closely related scripts (e.g., Japanese Kanji, Katakana, Hiragana, and Romaji). Use Unicode Technical Standard #39, “Unicode Security Mechanisms ( to check that the scripts in a Unicode sequence follow good practice.
5See IETF RFCs 5890, 5891, 5892, 5893, and 5894 for the definition of IDNA2008.
6See “List of Top-Level Domains” (

24. Store UASG Recommendations
Typically, domain names and addresses should be normalized according to Unicode Normalization Form C (NFC) before storing.
In most applications, domain names and addresses should be stored in files and databases encoded as UTF-8, the most common and best-supported Unicode encoding.
Within application code, the most appropriate representation of Unicode depends on the programming environment.
Applications should choose a consistent internal representation—either U-labels or A-labels—for IDNs.
The temporary or long-term storage of domain names and addresses, which should be stored in well-defined formats regardless of the expected duration of the storage.
UASG Recommendations
In almost all cases domain names and addresses should be normalized according to Unicode Normalization Form C (NFC) before storing. Because NFC is not perfectly lossless, in rare circumstances it may be necessary to defer normalization until further processing has established the specific context(s) in which it should be applied.
In most applications, domain names and addresses should be stored in files and databases encoded as UTF-8, the most common and best-supported Unicode encoding. In some cases, where software has to interoperate with legacy databases, it may be easier to use the same encoding as the database.
Within application code, the most appropriate representation of Unicode depends on the programming environment. Many common programming languages including the python and perl scripting languages have built-in support for Unicode and automatic conversion to or from UTF-8 on input and output.
Applications should choose a consistent internal representation—either U-labels or A-labels—for IDNs. Because every U-label can be transformed into a unique A-label and vice-versa, either form is acceptable.

25. Process UASG Recommendations Occurs whenever
As Unicode evolves, upgrade software when practical to use the most recent version of the standard and any available graphics and fonts.
Use APIs that support UTF-8 input or output whenever available. Use standard well- debugged libraries to process and validate IDNs.
Give special consideration for scripts written right-to-left that are used in domain names and addresses.
When creating registries or other data structures that include script or language information, allow for as many as possible, ideally all that the Unicode Standard supports.
Occurs whenever
an address or domain name is used by an application or service to perform an activity or changed into an alternative format. Additional validation may occur during processing.
UASG Recommendations
As Unicode evolves, upgrade software when practical to use the most recent version of the standard and any available graphics and fonts. Consider that user devices, software libraries, and web standards may not support the most recent version, and therefore may display newly allocated characters incorrectly, as a generic box ( ), or not at all.
When APIs that support UTF-8 input or output are available, use them rather than APIs that do not. Use standard well-debugged libraries, such as the GNU libidn2 ( to process and validate IDNs; do not “roll your own.”
Scripts that are written right-to-left require special considerations when they are used in domain names and addresses. Some of those considerations are addressed in IDNA7 (for domain names) and an Annex to the Unicode Standard8 (for addresses).
When creating registries or other data structures that include script or language information, allow for as many as possible, ideally all that the Unicode Standard supports9. Be aware that some languages can be written using different scripts, and that some scripts can be used to write many different languages.
7See RFC 5893, “Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)” (
8See UAX#9, “Unicode Bidirectional Algorithm” (
9See the Unicode “Supported Scripts” (

26. Display UASG Recommendations Occurs whenever an
Consider that although modern software and devices can display nearly all Unicode code points, older systems may have limited support, and require that applications manage some of their old fonts.
Display IDNs in their native character form unless there is a specific requirement to display them as A-labels.
Some mixed left-to-right (LTR) or right-to-left (RTL) text makes sense to users, and some does not. Use the Unicode restriction levels criteria to flag potentially misleading strings.
In some cases it may be necessary to design applications separately for different languages or language groups.
Occurs whenever an
address or domain name is rendered visually by a user interface.
UASG Recommendations
Consider that although modern software and devices can display nearly all Unicode code points, older systems may have limited support, and require that applications manage some of their old fonts. Also, when Unicode adds new code points, devices and applications will not display them until their font libraries have been updated.
Display IDNs in their native character form unless there is a specific requirement to display them as A-labels.
Domain names and addresses can be displayed in left-to-right (LTR) text, as in English or Russian, or right-to-left (RTL) text, as in Arabic or Hebrew. Because Unicode assigns directionality attributes to individual code points—not to code point sequences—some mixed LTR and RTL (“bidirectional”) text makes sense to users, and some does not. Use the Unicode restriction levels criteria10 to flag potentially misleading strings.
Internet users read and speak many different languages. In some cases it may be necessary to design applications separately for different languages or language groups.
10See Unicode Technical Standard #39, “Unicode Security Mechanisms”
( for its Moderately Restrictive and Highly Restrictive restriction levels to check that the scripts in a Unicode sequence follow good practice.

27. Tools & Resources for Developers
Authoritative Tables:
See also SAC070:
Internationalized Domain Names for Applications:
Framework:
Protocol:
Tables:
Right-to-Left Scripts:
Rationale:
Internet Standard RFC 20:
GNU Libidn2 Library:
Unicode:
Security Considerations:
Security Mechanisms:
Bidirectional Algorithm:
Normalization Forms:
Supported Scripts:
Universal Acceptance Steering Group info & recent developments:

28. Featured Case Studies
The Government of the State of Rajasthan, through India’s RajMail project, has provided all its citizens with a free address in either Hindi or English, using its own secure platform provided by local company XgenPlus. This is an important step in the state’s eGovernance project.
RajMail: content/uploads/2019/02/UASG013E-en-case-study- rajmail-government-of-rajasthan.pdf
The Thai Network Information Center Foundation (THNIC) and the Thai government support the .Thai Internationalized Domain Name (.ไทย) and Address Internationalization (EAI) initiatives, which facilitate the use of addresses using the . ไทย IDN. This is an important step in increasing Thailand’s Internet penetration.
THNIC: content/uploads/2016/11/UASG013A en-case- study-thnic-digital.pdf
See all case studies:

29. Next Steps… Read the documents at https://uasg.tech/information/
UASG003 – Fact Sheet
UASG005 – Quick Guide
UASG007 – Introduction to Universal Acceptance
UASG011 – FAQs
Subscribe to the UASG Discussion list
Get your own systems UA Ready
Spread the word…

30. Contact Information
Contact the UASG:
Meet the people of the UASG:
Participate in UASG Discussions:
Report UA problems with other applications:

31. Thank You