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

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

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. .닷넷 .ストア . дети

What’s Changed .amex .ファッション .aaa .ভারত ‏.קום .公益 .москва .accountant 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 .amex .asia ‎ ‏.كوم‎ .accountant .ファッション .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 email system.

But… It Doesn’t All Work Together http://soap.organic http://tokyo.ストア http://bank.com Bank X X Email 测试@普遍.世界 X Not a valid email address. In 2017, only 8% of the top websites could handle our sample set of non-English email 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 Email 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 email 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.

The Role of Universal Acceptance UA- ready http://soap.organic http://tokyo.ストア http://bank.com Welcome to organic TOKYO Bank SOAP 当社の製品を購入します Email 测试@普遍.世界 We make the best soap in the world. It’s 100% organic. Email validated. Account created. Not ready http://soap.organic http://tokyo.ストア http://bank.com Bank X X Email 测试@普遍.世界 X Not a valid email 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 email 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.

Let’s See… Test your own email address - https://uasg.tech/eai-check/ 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 email address - https://uasg.tech/eai-check/ Presenter should use their own EAI ready email address for this example. The goal here is to see if people’s existing email systems are able to send an email 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 AppleMail, Yahoo, Yandex or many other applications will not be able to do this.

Anatomy of an email address username@example.com 测试5@普遍接受-测试.世界 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 email address of their choice for the Chinese addresses shown here.

Universal Acceptance | Real World Benefits

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 email 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 email addresses. This gives us an average revenue per email 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 email 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 email 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 email services, retailers and e-commerce websites, travel sites, social networks, email 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.

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, email 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.

Why Bother Allows people to use their preferred identity through the new TLDs Seamless acceptance of all domain names and all email 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 - https://uasg.tech/whitepaper/ This information is from the UASG WhitePaper

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.

UA Progress and What’s Ahead Reference documents and resources Use and test cases Industry events and university course slides Social media and email software & services evaluation and programming language remediation Influencer outreach and encouraging email 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

Better UA = Better user experience Better support for non-English speakers Better support for screen readers (accessibility issues) URL: https://www.naturalreaders.com/online/ [naturalreaders.com] Test String 1: You may reach me at info@mysite.москва Test String 2: You may reach me at info@mysite.xn—80adxhks

Five Verbs to UA Readiness Accept Validate Store Process Display

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 email addresses Comprised of more than 170 companies (including Afilias, Apple, CNNIC, Go Daddy, Google, Microsoft, THNIC and others), governments and community groups

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.

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.

Moving forward Test your own email address Secure an EAI address Use DataMail or Install DataMail App Use CoreMail 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

Principles of Universal Acceptance What Does “Universal Acceptance” Mean? Some software does not recognize or correctly process all domain names and all email addresses. Domain names can include strings in the top-level position that are longer than the older familiar ones, and domain names and email 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 email 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 email 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: www.uasg.tech. 1ASCII is the character encoding historically used on the Internet, defined in the Internet standard RFC 20 (https://tools.ietf.org/html/rfc20). Unicode is defined by the Unicode Consortium (http://unicode.org).

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 email 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 email address should be converted into Unicode Normalization Form C (NFC) before further processing. Process by which a domain name or an email 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 email address can have a local part (the part before the @-sign) 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 email 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 email 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” (https://www.unicode.org/reports/tr15/tr15-47.html).

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 email 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 email address twice may detect typing errors. In most cases, all of the components of a domain name or email 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 email 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 email 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 IDNA20085. 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 email address, validate the domain part as described above. Because the local part of an email 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 email address twice may detect typing errors. In most cases, all of the components of a domain name or email 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 (https://www.unicode.org/reports/tr39/#Restriction_Level_Detection), 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” (https://www.icann.org/resources/pages/tlds-2012-02-25-en).

Store UASG Recommendations Typically, domain names and email addresses should be normalized according to Unicode Normalization Form C (NFC) before storing. In most applications, domain names and email 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 email 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 email 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 email 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.

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 email 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 email 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 (https://www.gnu.org/software/libidn/#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 email addresses. Some of those considerations are addressed in IDNA7 (for domain names) and an Annex to the Unicode Standard8 (for email 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)” (https://tools.ietf.org/html/rfc5893). 8See UAX#9, “Unicode Bidirectional Algorithm” (http://unicode.org/reports/tr9). 9See the Unicode “Supported Scripts” (http://unicode.org/standard/supported.html).

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 email 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 email 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” (https://www.unicode.org/reports/tr39/#Restriction_Level_Detection), for its Moderately Restrictive and Highly Restrictive restriction levels to check that the scripts in a Unicode sequence follow good practice.

Tools & Resources for Developers Authoritative Tables: http://www.internic.net/domain/root.zone http://www.dns.icann.org/services/authoritative-dns/index.html http://data.iana.org/TLD/tlds-alpha-by-domain.txt See also SAC070: https://tinyurl.com/sac070 Internationalized Domain Names for Applications: Framework: https://tools.ietf.org/html/rfc5890 Protocol: https://tools.ietf.org/html/rfc5891 Tables: https://tools.ietf.org/html/rfc5892 Right-to-Left Scripts: https://tools.ietf.org/html/rfc5893 Rationale: https://tools.ietf.org/html/rfc5894 Internet Standard RFC 20: https://tools.ietf.org/html/rfc20 GNU Libidn2 Library: https://www.gnu.org/software/libidn/#libidn2 Unicode: Security Considerations: http://unicode.org/reports/tr36/ Security Mechanisms: https://unicode.org/reports/tr39/ Bidirectional Algorithm: http://unicode.org/reports/tr9 Normalization Forms: https://www.unicode.org/reports/tr15/tr15-47.html Supported Scripts: http://unicode.org/standard/supported.html Universal Acceptance Steering Group info & recent developments: www.uasg.tech

Featured Case Studies The Government of the State of Rajasthan, through India’s RajMail project, has provided all its citizens with a free email address in either Hindi or English, using its own secure email platform provided by local company XgenPlus. This is an important step in the state’s eGovernance project. RajMail: https://uasg.tech/wp- 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 Email Address Internationalization (EAI) initiatives, which facilitate the use of email addresses using the .ไทย IDN. This is an important step in increasing Thailand’s Internet penetration. THNIC: https://uasg.tech/wp-content/uploads/2016/11/UASG013A- 161031-en-case-study-thnic-digital.pdf See all case studies: https://uasg.tech/case-studies/

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 www.uasg.tech/subscribe Get your own systems UA Ready Spread the word…

Contact Information Contact the UASG: https://uasg.tech/contact/ Meet the people of the UASG: https://uasg.tech/about/people/ Participate in UASG Discussions: https://uasg.tech/subscribe Report UA problems with other applications: https://uasg.tech/global-support- centre/

Thank You