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 ith 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 1 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 ā) It’s harder on a PC.
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 land 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/.世界)
Can be ASCII or Unicode
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 multipied 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 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 120 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 Customisable Blog Posts.
Become a local hero and expert.

20. Moving forward Test your own email address
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

22. Accept UASG Recommendations
User interface elements must support:
Unicode.
Strings up to 256 characters.
ASCII A-label domain names as well as Unicode.
Unicode shown by default.
A-label shown only when it provides a benefit.
The process by which an address or domain name is received as a string of characters from a user interface, file or API.
UASG Recommendations
User interface elements requiring user to type domain name/ address must support Unicode and strings up to 256 characters
Users should be allowed to enter ASCII Compatible Encoded text (“Punycoded”) in place of Unicode equivalent
Unicode should be shown by default
Punycoded text should only be shown when provides a benefit

23. Validate UASG Recommendations
Easiest way to ensure all valid domain names are accepted.
Should not occur unless required. If yes:
Verify TLD against DNS.
Query domain name against DNS.
Validate address with confirmation message.
Validate characters using U-label rules.
Limit to few, whole-label rules defined in RFC
The process by which an address or domain name – received or emitted – is checked for syntax correctness.
Many programmers have been trained to validate by following heuristics that require checking that a top-level domain has the “correct” number of letters, or that the letters are from the ASCII character set. These heuristics are no longer applicable because of the introduction of domain names with more than three characters, and Unicode (non-ASCII) characters.

24. Store UASG Recommendations
Apps / services should support Unicode
Information stored in UTF-8 whenever possible
Consider end-to-end scenarios before converting between A-Labels & U-Labels
Clearly mark addresses and domain names during storage
The long-term and / or transient storage of domain names and addresses.
Regardless of the lifetime of the data, it should be stored in RFC-defined formats (preferred) or other formats which can transform between RFC-defined formats.
UTF-8 (Unicode Transformation Format). Some systems may require support for UTF-16 as well, but generally UTF-8 is preferred. UTF-7 and UTF-32 should be avoided.
Consider all end-to-end scenarios before converting A-Labels to U-Labels and vice versa when storing. It may be desirable to maintain only U-Labels in a file or database, because it simplifies searching and sorting. However, conversion may have implications when interoperating with older, non-Unicode-enabled applications and services. Consider storing in both formats.
Instances where addresses and domain names have been filed under the “author” field of a document or “contact info” in a log file have led to the loss of origin as an address.

25. Process UASG Recommendations
Check code points not defined when application / service was created – shouldn’t “break” user experience.
Use supported Unicode-enabled APIs.
Use latest IDNA Protocol & Tables documents for Internationalized Domain Names.
Process in UTF-8 wherever possible.
Occurs whenever an address or domain name is used by an application or service to perform an activity, or is transformed into an alternate format.
Activity (e.g., searching or sorting a list)
Alternate format (e.g., storing ASCII as Unicode).
Additional validation may also occur during processing. Domain names and addresses can be processed in an unlimited number of ways*, which reinforces the need for conventions that ensure data is being understood and classified consistently. *Examples: Identify people in New Zealand by searching within the .nz ccTLD; identify pharmacists by searching for addresses.
Recommendations:
Since the Unicode standard is continually expanding, code points not defined when the application or service was created should be checked to ensure they will not “break” the user experience. Missing fonts in the underlying operating system may result in non-displayable characters (frequently the “” character is used to represent these), but this situation should not result in a fatal crash.
Use supported Unicode-enabled APIs.
Use the latest Internationalized Domain Names in Applications (IDNA) Protocol [ and Tables [ documents for Internationalized Domain Names (IDNs).
Process in UTF-8 format wherever possible.
Ensure that the product or feature handles numbers as expected. For example, ASCII numerals and Asian ideographic number representations should be treated as numbers. [RFC5892, link above]
Upgrade applications and servers/services together. If the server is Unicode and client is non-Unicode or vice versa, the data will need to be converted to each code page every time the data travels between server and client.
Perform code reviews to avoid buffer overflow attacks. When doing character transformation, text strings may grow or shrink substantially.

26. Process (continued) UASG Recommendations
Ensure numbers are handled as expected
Treat ASCII numerals & Asian ideographic number representations as numbers when appropriate
Upgrade apps & servers/services together
Perform code reviews to avoid buffer overflow attacks
Occurs whenever an address or domain name is used by an application or service to perform an activity, or is transformed into an alternate format.
Activity (e.g., searching or sorting a list)
Alternate format (e.g., storing ASCII as Unicode).
Additional validation may also occur during processing. Domain names and addresses can be processed in an unlimited number of ways*, which reinforces the need for conventions that ensure data is being understood and classified consistently. *Examples: Identify people in New Zealand by searching within the .nz ccTLD; identify pharmacists by searching for addresses.
Recommendations:
Since the Unicode standard is continually expanding, code points not defined when the application or service was created should be checked to ensure they will not “break” the user experience. Missing fonts in the underlying operating system may result in non-displayable characters (frequently the “” character is used to represent these), but this situation should not result in a fatal crash.
Use supported Unicode-enabled APIs.
Use the latest Internationalized Domain Names in Applications (IDNA) Protocol [ and Tables [ documents for Internationalized Domain Names (IDNs).
Process in UTF-8 format wherever possible.
Ensure that the product or feature handles numbers as expected. For example, ASCII numerals and Asian ideographic number representations should be treated as numbers. [RFC5892, link above]
Upgrade applications and servers/services together. If the server is Unicode and client is non-Unicode or vice versa, the data will need to be converted to each code page every time the data travels between server and client.
Perform code reviews to avoid buffer overflow attacks. When doing character transformation, text strings may grow or shrink substantially.

27. Display UASG Recommendations
Display all Unicode code points supported by underlying operating system.
When developing app/service, or operating a registry, consider languages supported.
Display data as Unicode.
Avoid display or processeing old pre- Unicode encodings
End user should see “everyone.みんな” vs. “everyone.xn--q9jyb4c.”
Display occurs whenever an address or a domain name is rendered within a user interface.
Displaying domain names and addresses is usually straightforward when the scripts used are supported in the underlying OS and strings are stored in Unicode; however, application-specific transformations may be required otherwise.
Recommendations
Display all Unicode code points which are supported by the underlying operating system. If an application maintains its own font sets, comprehensive Unicode support should be offered to the collection of fonts available from the operating system.
When developing an app or a service, or when operating a registry, consider the languages supported and make sure OS and applications cover those languages.
Convert non-Unicode data to Unicode before display. For example, the end user should see “everyone.みんな” as opposed to “everyone.xn--q9jyb4c”. (This conversion is an example of UA-ready processing).
Display Unicode by default. Use Punycoded text to the user only when it provides a benefit. Augment Unicode display with Punycoded hover text as a mitigation.
Consider that mixed-script addresses will become more common. Some Unicode characters may look the same to the human eye, but different to computers. Don’t assume that mixed-script strings are intended for malicious purposes, such as phishing, and if the user interface calls the strings to the user’s attention, be sure that it does so in a way which is not
prejudicial to users of non-Latin scripts. Learn more about Unicode Security Considerations at:
Use Unicode IDNA Compatibility Processing in order to match user expectations. To learn more, go to:
Be aware of unassigned and disallowed characters. Learn more at RFC 5892:

28. Display (continued) UASG Recommendations
Display Unicode by default
Show A-labels only when it provides a benefit
Consider that mixed-script addresses will become more common
Use Unicode IDNA Processing to match user expectations
Be aware of unassigned & disallowed characters
Display occurs whenever an address or a domain name is rendered within a user interface.
Displaying domain names and addresses is usually straightforward when the scripts used are supported in the underlying OS and strings are stored in Unicode; however, application-specific transformations may be required otherwise.
Recommendations
Display all Unicode code points which are supported by the underlying operating system. If an application maintains its own font sets, comprehensive Unicode support should be offered to the collection of fonts available from the operating system.
When developing an app or a service, or when operating a registry, consider the languages supported and make sure OS and applications cover those languages.
Convert non-Unicode data to Unicode before display. For example, the end user should see “everyone.みんな” as opposed to “everyone.xn--q9jyb4c”. (This conversion is an example of UA-ready processing).
Display Unicode by default. Use Punycoded text to the user only when it provides a benefit. Augment Unicode display with Punycoded hover text as a mitigation.
Consider that mixed-script addresses will become more common. Some Unicode characters may look the same to the human eye, but different to computers. Don’t assume that mixed-script strings are intended for malicious purposes, such as phishing, and if the user interface calls the strings to the user’s attention, be sure that it does so in a way which is not
prejudicial to users of non-Latin scripts. Learn more about Unicode Security Considerations at:
Use Unicode IDNA Compatibility Processing in order to match user expectations. To learn more, go to:
Be aware of unassigned and disallowed characters. Learn more at RFC 5892:

29. Tools & Resources for Developers
Authoritative Tables:
dns/index.html
See also SAC070:
Internationalized Domain Names for Applications:
Framework:
Tables:
Rationale:
Protocol:
Unicode:
Security Considerations:
Universal Acceptance Steering Group info & recent developments:

30. Next Steps… Read the documents at www.uasg.tech/documents
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…