March 2016 - UA-discuss - lists.iana.org

UA Topics from the Public Forum
by Don Hollander March 22, 2016

March 22, 2016

The following two passages from the Public Forum on Thursday in Marrakech: KAREN YU: Okay. I'm Karen Yu from ZDNS. We are an RSG member, but I'm acting as my personal capacity for this question. So we have talked about universal acceptance for a while, but it seems it has been moving really slow. So I think ICANN make -- do something to accelerate the development of this. So, for example, to our best knowledge, ICANN currently only use ASCII domain for the official website. So maybe why not ICANN adopt an IDN for the website, for example, to all? [ Applause ] MIKE SILBER: Thank you very much, Karen. As an interested observer, I've noticed some significant effort. But Ram is the chair or co-chair - - I can't remember -- of the universal acceptance working group. Maybe you could respond to that. RAM MOHAN: Thank you, Mike. Thank you for bringing this up. It's a very important topic. Universal acceptance is crucial for the people of the world to actually access the Internet the way it was intended and not only in ASCII or -- so I think your idea is very good. There are many other ideas like that that come through. We will certainly make sure that staff take a look at that and make a determination. And I would go even further. It's not just the website but it's also how emails come through, what happens when emails come in for registration on the ICANN website, for example, where they're internationalized email addresses. So there's a whole host of it. Thank you for your comments, and we take it fully on board. There's very strong support from the board, from the staff, and to the community on universal acceptance. — Yes. Good afternoon. My name is Tony Harris. I'm with the ISPCP constituency. I'm also a new registry. And I just wanted to thank the board for having helped us launch the universal acceptance steering group. I am extremely impressed with the progress we are making. We have a dream team of technical experts from some of the largest companies, the community, and staff, and I do have to say I disagree with comments that I heard today about it going slowly. On the contrary, we are making great progress. Obviously, a lot of evaluation had to be done how to address the vast community of programmers, implementers, and system administrators worldwide, and collect the relevant materials to be able to address this successfully. I'm happy to say this is very much on track and I just wanted to say this is great work being done. Thank you very much. RAM MOHAN: Thank you to everyone in the community. This is really a community effort, and I think from the board, what you'll find is very strong and sustained and persistent support for this program. In many ways we're trying to emulate what the board had done with the IDN program several years ago with providing strong support. There's an overlap of IDN and universal acceptance as well.

2 3

Quick Guide to Linkification
by Don Hollander March 22, 2016

March 22, 2016

https://docs.google.com/document/d/1Fde7P7jrufo-HGmd6aNyi4MHDMECiqIzONyJAm3… I’ve created a first draft of a Quick Guide to Linkification I would very much appreciate comments & correction, etc. An editable copy of the document can be found in the link above. A copy of the text can be found below for your convenience. Can I please have responses by the end of the month? Thanks. Don DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT:: Universal Acceptance Steering Group Quick Guide to Linkification 20 March 2016 Background Universal Acceptance (UA) is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet- enabled applications, devices and systems. Due to the rapidly changing domain name landscape, many systems do not recognize or appropriately process new domain names, primarily because they may be more than three characters in length or in a non-ASCII format. The same is true for email addresses that incorporate these new extensions. The Universal Acceptance Steering Group (UASG), supported by Internet Corporation for Assigned Names and Numbers (ICANN), is a community-led, Internet industry-wide initiative working on creating awareness and identifying and resolving problems associated with the universal acceptance of domain names. The purpose of these efforts is to help ensure a consistent and positive experience for Internet users globally. For more information on the UASG and recent development, visit www.uasg.tech<http://www.uasg.tech>. Linkification Modern software sometimes allows a user to create a hyperlink simply by typing in a string that looks like a web address, email name or network path. For example, typing “www.icann.org<http://www.icann.org>” into an email message may result in a clickable link to http://www.icann.org being automatically created if the app treats “www.” as a special prefix or “.org” as a special suffix. Linkification should work consistently for all well-formed web addresses, email names or network paths. Linkification is the action where an application accepts a string and dynamically determines whether it should create a hyperlink to an Internet Location (URL) or an email address (mailto:) Linkification uses algorithms and rules created by software developers to determine whether a string should be deemed a link – or not. Related to this is how people can identify a string as a domain name. While browsers, email clients and word processors are obvious places, there are many more applications that make these decisions.   Good Practice Recommendations 1. Attempt to linkify based on protocol prefixes (e.g. “www”, “http://”, ftp://”, “mailto:”) but only complete the action if the rest of the string is well formed (RFCXXXX?)   2. Do not require a DNS check. Do we recommend validated the TLD? 3. Attempt to linkify any well formed string without a protocol prefix. * Label.label * Label.label/label * label(a)label.label<mailto:label@label.label>  4. Do not assume a prefix if it is not explicitly stated (i.e. don’t automatically convert “icann.org<http://icann.org>” to http://www.icann.org) § However, is the average user expected to know what prefix to use?  IS THIS RIGHT 5. Map the Ideographic Full Stop “。” (U+3002) to Full Stop “.” (U+002E) (e.g. http://田中<http://xn--fiqx46g>。com à http://田中.com<http://xn--fiqx46g.com>) if string is well formed (RFCXXXX?)   6. BIDI – What are the unique challenges with BIDI?  

1 0

Quick Guide to Tender and Contractual Documents
by Don Hollander March 22, 2016

March 22, 2016

https://docs.google.com/document/d/1P6yvyBlLAYRWebKljF7mWvXSkjOUDiPDXgE2fNw… One of the items raised by Ashwin during his presentation in Marrakech was having some contractual clauses that focus on UA issues. I’ve prepared a draft Quick Guide to the topic. Link to an on-line editable document is above. I’ve also add sample clauses for DNSSEC and IPv6 - these samples come from the ICANN contracts. I would welcome your feedback (or the feedback from the lawyers that you know) on the document and the clauses. Text of the 1st draft is below to make it easier for you to follow. If you have any problems accessing the document to edit, do please let me know. Don DRAFT Universal Acceptance Steering Group Quick Guide to Tender and Contractual Documents 20 March 2016 Background Universal Acceptance (UA) is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet- enabled applications, devices and systems. Due to the rapidly changing domain name landscape, many systems do not recognize or appropriately process new domain names, primarily because they may be more than three characters in length or in a non-ASCII format. The same is true for email addresses that incorporate these new extensions. The Universal Acceptance Steering Group (UASG), supported by Internet Corporation for Assigned Names and Numbers (ICANN), is a community-led, Internet industry-wide initiative working on creating awareness and identifying and resolving problems associated with the universal acceptance of domain names. The purpose of these efforts is to help ensure a consistent and positive experience for Internet users globally. For more information on the UASG and recent development, visit www.uasg.tech<http://www.uasg.tech>. Tender and Contractual Documents One way of working toward Universal Acceptance of all domain names is to ensure that such a requirement is included in Tender and Contract documents. ‘Broccoli Issues’ The term ‘Broccoli Issues’ is used here to identify issues that are good and useful but not particularly exciting to the rest of the world. With respect to Internet issues, this will include provision of IPv6 and DNSSEC compliant services. This document includes Good Practice clauses for Universal Acceptance as well as IPv6 and DNSSEC. Additional clauses may be added for other ‘Broccoli Issues’. Universal Acceptance Sample Clause UNIVERSAL ACCEPTANCE OF TLDs COMPLIANCE (Universal Acceptance (UA) is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet-enabled applications, devices and systems.): To the extent the Services and/or Deliverables include development or provision of software and/or devices that support network or Internet connectivity of any kind, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the following provision: In whatever manner a Service/Deliverable handles a domain name, the Service/Deliverable shall do so consistently for all standards compliant names in all top-level domains listed in IANA’s Root Zone Database (accessible via https://www.iana.org/domains/root/db) at the time of delivery and guarantees consistency for three years. IPv6 Sample Clause IPV6 SPECIFICATION COMPLIANCE: To the extent the Services and/or Deliverables include development or provision of software and/or devices that support network or Internet connectivity of any kind, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the Internet Engineering Task Force (IETF) Internet Protocol, Version 6 Specification, sometimes referred to as the IPv6 Specification; and, in addition, will be fully backward-compatible with the Internet Engineering Task Force (IETF) Internet Protocol, Version 4 Specification, sometimes referred to as the IPv4 Specification, including without limitation having the capabilities: (a) to create or receive, process, and send or forward (as appropriate) IPv6 packets in mixed IPv4/IPv6 environments, and (b) to interoperate with other iPv6 compliant software, devices and websites on networks supporting only IPv4, only IPv6, and both IPv4 and IPv6. The expectation is that any networked application or service developed for “US” would operate irrespective of whether such services were accessed using IPv4 or IPv6. DNSSEC Sample Clause DNSSEC COMPLIANCE: To the extent the Services and/or Deliverables include development, provision, and/or use of the domain names, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the following provisions: a) The Service/Deliverable is consistent with the definitions contained in the following list of RFCs and applicable errata, as the RFCs apply to the Service/Deliverable. The titles given here are representative, not the full name to improve readability of the list. b) For Services/Deliverables making use of data obtained via DNS responses, DNSSEC validation must be active, use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor, and support the updating of the Key Signing Key via RFC 5011 (and any revisions) c) Services/Deliverables publishing zone data must DNSSEC-sign the zone data and describe the signing procedure in a document as described in RFC 6841, A Framework for DNSSEC Policies and DNSSEC Practice Statements.

1 0

UA-Coordination Meetings
by Don Hollander March 22, 2016

March 22, 2016

FYI: There will be a UA Coordination Group call Friday/Saturday. It is to cover some administrative actions. I expect to have a UA Discuss call in early April. Please let me know if there are any topics that you'd like included. Don Agenda UA Coordination Group March 2016 https://icann.adobeconnect.com/universalacceptance MobileUSA tel://1-719-325-2630,*,,7375086559#<tel://1-719-325-2630,*,,7375086559> MobileNZ: tel://0800-459-127,*,,7375086559# MobileHK tel://800-968-082,*,,7375086559# MobileUK tel://0800-368-0950,*,,7375086559# Phone Only Controls : https://go.conferencinghub.com/1n1zr Other numbers available by request. March 2016 1.Attendance/Apologies 2.Review of January Meeting Notes 3.Actions from January Meeting *Review the Charter - Don & Ram - DONE *Organise Logistics for Marakech - Don - DONE *Make Adjustments to Quick Guides - Mark, Luisa, Dennis - DONE *Review Documents for consistency of language - Mark, Gwen - DONE *Compile, format, print and publish Quick Guides - Don- DONE *Produce Projections for EoY - Don - DONE *Produce Help Wanted Documents for PR/Comms - Gwen, Christian - DONE *White Paper - Don, Ram - DONE *Review EAI Skills from Microsoft to attend ECO's April Event - Mark, Lars - DONE *Publish Expected Standards of Behaviour - Don - DONE 4.Approval of new Charter 5.Changing Coordination Group *Remove: Top-level, International, Measurement & Monitoring. *Add: EAI *Keep Community Outreach 6.Unbudgeted Projects 7.Help Wanted Project Evaluations *Translation *Comms/PR *Programming Language Review *UA Use Case Platforms *Popular Browsers 8.Financial Delegation 9.UA Announce List During discussions at the ICANN meeting in Marrakech, a number of people expressed interest in subscribing to a UASG announcement list. They had been 'turned-off' by some of the actors on the list, but still wanted to be aware of major activities. Proposal: To create a UA Announce mailing list that will include information leading up to a meeting, results of meetings, and other published information of note. 10.UA @ GDD Summit 11.UA @ ICANN56 12.UA(a)Nerdear.la<mailto:UA@Nerdear.la> 13.Registry of Interests 14.AoB

1 0

UA @ APRALO
by Don Hollander March 21, 2016

March 21, 2016

The APRALO is organising a webinar later today Tuesday @ 05:00 UTC to introduce UA & EAI to their community. Details can be found at https://community.icann.org/pages/viewpage.action?pageId=58727895 It’s an open call, so participate if you find the time and interest. Don

3 2

Help Wanted - Technical Editor
by Don Hollander March 17, 2016

March 17, 2016

Please find attached a Help Wanted note for a copy editor. Please share it with your respective networks. Thanks. Don

1 0

EAI Addresses for Testing
by Mark Svancarek March 16, 2016

March 16, 2016

Here are two addresses for testing. Please send some messages to these addresses, then share back the results. مارك(a)xn--wgbe5cxa.xn--mgberp4a5d4ar<mailto:مارك@رسيل.السعودية> 微软测试(a)xn--blq510jgwa.xn--fiqs8s<mailto:微软测试@互联网.中国> Please tell us your configuration: · OS · Browser version (if you used a browser mail application) · Email application version(if you didn’t use a browser) Also send us the results. Even if it worked perfectly, we need to know. If it failed or has an error, share the error text. If address was changed to punycode, share that also. Thank you for your help achieving Universal Acceptance in the email ecosystem! -Mark Svancarek

11 19

RTL Script Domain Names & Email Addresses
by Andre Schappo March 14, 2016

March 14, 2016

I have given some thought to how to handle/display domain names that are in a right to left script such as Arabic. After some thought and experimentation I think that each label of a domain name should be bidi isolated. Lets take a 2 level domain name: 2ndLevelD.TLD where each label is written in a Right to Left Script. In a Left to Right paragraph/document I want the ordering to be 2ndLevelD.TLD In a Right to Left paragraph/document I want the ordering to be TLD.2ndLevelD Using bidi isolation this can be achieved. In the case of html5 one can use the bidi isolate tag <bdi> So, I now write my domain name in html5 as <bdi>2ndLevelD</bdi>.<bdi>TLD</bdi> I then experimented with the html dir attribute and flipped the whole document between dir="ltr" and dir="rtl" and it gave me the results I wanted as above. I need to think a bit more about the possible permutations of the local part of an email address but if it is a single word then the following works eg <bdi>email</bdi>@<bdi>2ndLevelD</bdi>.<bdi>TLD</bdi> I believe that using bidi isolates leads to easier to comprehend domain names/email addresses for both Left to Right readers and Right to Left readers. So, for example, a Left to Right reader would see a domain name 2ndLevelD.TLD and one can easily comprehend the ordering is from minor to major from Left to Right. The text in each label is though Right to Left André Schappo

3 4

ODG: Re: EAI Addresses for Testing
by Dusan Stojicevic March 13, 2016

March 13, 2016

OS Android version 5.0 Mail client - commingled pre-installed with the OS Result for Arabic email address Resolving bidi issue. Message wasn't sent, because: User part resolved as domain part. Displayed as unicode Domain part resolved as user part, displayed as xn-- ---- Andre Schappo je napisao/la ---- >I was wondering how Mark had got an Arabic email address and decided to find out. I discovered the Raseel project http://رسيل.السعودية/raseel-arabic-email-addresses > > >I gather from the site though that, unfortunately, they are not taking any more requests for Arabic email addresses on their system??? > > >Apart from that the Raseel website is really good as, apart from the url above, the rest of the navigation urls are wholly in Arabic i.e. including the pathname part > > >http://رسيل.السعودية > >http://رسيل.السعودية/لقطات-من-رسيل > >http://رسيل.السعودية/شروط-الخدمة > >...etc... > > >André Schappo > > >On 6 Mar 2016, at 15:30, Mark Svancarek <marksv(a)microsoft.com> wrote: > > > > >Here are two addresses for testing. Please send some messages to these addresses, then share back the results. > > > >مارك(a)xn--wgbe5cxa.xn--mgberp4a5d4ar > > > >微软测试(a)xn--blq510jgwa.xn--fiqs8s > > > >Please tell us your configuration: > >· OS > >· Browser version (if you used a browser mail application) > >· Email application version(if you didn’t use a browser) > > > >Also send us the results. Even if it worked perfectly, we need to know. If it failed or has an error, share the error text. If address was changed to punycode, share that also. > > > >Thank you for your help achieving Universal Acceptance in the email ecosystem! > > > >-Mark Svancarek > > > > >

1 1

UA @ ICANN55
by Don Hollander March 12, 2016

March 12, 2016

Just in case your looking for a paragraph about UA in your ICANN55 report… The Universal Acceptance Steering group provided an update on activities to date and forthcoming. A surprising number of documents have been completed since Dublin, and the main technical document finished its first complete detailed reading on the Sunday. Coming up is an evaluation and mitigation of Programming Languages and Frameworks, Providing some UA Use Cases and landing pages, translation of core documents, and engaging a global PR company. The UASG, a community group supported by ICANN (and others) flipped its execution approach recently with the volunteers becoming more supporters than doers. More details of the documents UASG has published can be found in the Documents page of uasg.tech.

4 3