June 2017 - UA-discuss - lists.iana.org

FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
by Mark Svancarek July 6, 2017

July 6, 2017

FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update(a)alvestrand.no Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd-unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts(a)ietf.org To: i-d-announce(a)ietf.org Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce(a)ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update(a)alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update

8 10

Call for Participation: IAB workshop on Explicit Internet Naming Systems
by Mark Svancarek July 1, 2017

July 1, 2017

https://www.iab.org/2017/06/22/call-for-participation-iab-workshop-on-expli… Just seeing this, sorry for late notice.

6 7

8 India IDN ccTLDs delegated
by Andre Schappo June 30, 2017

June 30, 2017

The remaining 8 India/Bharat IDN ccTLDs are now in DNS Root. ಭಾರತ ഭാരതം ভাৰত ଭାରତ بارت भारतम् भारोत ڀارت This brings India to a seriously impressive 15 IDN ccTLDs See https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#Internatio… for complete list of all 15 India/Bharat IDN ccTLDs André Schappo

2 1

DRAFT: UA103 - Programming Hacks
by Don Hollander June 29, 2017

June 29, 2017

https://docs.google.com/document/d/1i4OAeojY5dj3ZAG8sHcrpSdaG1vN_R011MOuza4… As part of our efforts to raise awareness, we’re producing editorials/guest blogs that we’re getting published in various professional body newsletters and such. Our third editorial is focusing on Programming Hacks. Editable copy is available at the link above. Here’s the current draft. Comments please, by the 10th of July. Thanks. Don Programming language hacks UA103 Computer programmers are nice people. They are intelligent. They are wise. (Their mothers would say they are good looking J). They know that if people have a chance to make a mistake, they will. So, the wise, intelligent (and good looking) computer programmers build their systems to help prevent mistakes at the source. Computer programmers are also very efficient (their siblings might say lazy) and will reuse code – either their own or someone else’s. For years computer programmers have been putting the same data validation of email addresses and domain names into their code to reduce the amount of Garbage In. And this now turns out to be a mistake. What’s happened is that while the validation code has been pretty static, email addresses and domain names have been changing quite radically. Since 2001, Top Level Domain Names (TLDs) have been longer than two or three characters. Since 2010 Top Level Domain names have been available in non-ASCII characters. And since 2013, the number of TLDs and their frequency of entry into the Root Zone has gone off the charts! And today we also have mailbox names (the label to the left of the ‘@’) that can also be in non-ASCII characters! So, it’s time for computer programmers to update their code to accommodate these new domain name options. So here are some tips and tricks for computer programmers to use when updating their code: Input Data fields that accept domain names or email addresses should be able to accept ASCII and non-ASCII characters. UTF-8 is the key here. This will affect both programs that accept data from a keyboard or other data sources and the database where its stored. The good news is that most modern databases will have no problems with this. Validation The easiest way to deal with this is to only use syntactic validation against the specifications in the RFCs[1]. There are other ways of making sure the data entered is what the user meant, such as requiring entry of the field twice and doing a compare. If you need to validate further, use a DNS lookup – that’s the most certain. Or if you’re going to use a local table, make sure that it’s from an authoritative source and that it’s updated at least daily. Storage The easiest way to deal with storage is to support UTF-8. But for applications that can’t, there is an algorithm (Punycode)[2] that allows transformation of domain names between ASCII and non-ASCII strings. NB: the Punycode conversion may NOT work for the mailbox name in an email address. Alternative encoding schemes exist and should be applied. Processing There are times when two different representations of a domain name are not the same but are equivalent. For example, when a non-ASCII domain name has been converted using the Punycode algorithm. When processing or sorting, it’s important that they are treated as equivalent. This will require some policies for the application or indeed the organization as to how domain names and email addresses are being dealt with. Display Because domain names in non-ASCII characters (and mailbox names too) are growing more popular, you’ll need to make sure that you’re able to display them in a way that works for your community. Public facing applications should certainly display in native scripts and not an ASCII resulting from a Punycode transformation. Check Libraries A growing number of libraries, particularly Open Source Programming Language Libraries, will be correcting their validation routines, so being able to be UA Ready may be as simple as recompiling the code using the latest versions of the library. The UASG is encouraging remediation work in quite a number of libraries. Github and SourceForge are also two good places to look to find working code. The UASG also publishes some good reference material at www.uasg.tech/documents. Most efforts to get applications UA Ready will fall into the ‘Bug Fix’ level of effort. It’s time to get applications up to scratch. [1] https://uasg.tech/wp-content/uploads/2017/06/UA006-Relevant-RFCs.pdf [2] https://www.ietf.org/rfc/rfc3492.txt

3 2

FW: Call for Participation: IAB workshop on Explicit Internet Naming Systems
by Mark Svancarek June 27, 2017

June 27, 2017

Here’s a clarification of the problem statement. I don’t think I have a position on this that I could have written up in time for the position paper deadline tomorrow. Suggestions or concerns? From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: Tuesday, June 27, 2017 12:25 AM To: Mark Svancarek <marksv(a)microsoft.com> Subject: Re: Call for Participation: IAB workshop on Explicit Internet Naming Systems On Mon, Jun 26, 2017 at 1:31 PM, Mark Svancarek <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> wrote: Ted, What are real world some examples of this? Because there is no common facility for varying the resolution method in the URI structure, those naming systems must either mint new URI schemes for each resolution service or infer the resolution method from a reserved name or pattern. The most recent example in the IETF came up in the reservation of .onion. The system envisioned there uses the TOR system for node resolution, rather than the DNS. Reserving that name was a very long process in which a lot of discussion was needed, and it is clear the model does not scale well. One other option considered was minting URI schemes like https-tor://tor-node/, but they would need a new scheme for every application wanting to use the resolution (so email, xmpp, etc. would each need to be created and deployed). Getting deployment of those was seen to be even harder. I hope this example helps illustrate the problem, regards, Ted Ted From: Peter Constable Sent: Monday, June 26, 2017 8:31 AM To: Shawn Steele <Shawn.Steele(a)microsoft.com<mailto:Shawn.Steele@microsoft.com>>; Mark Svancarek <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> Subject: FW: Call for Participation: IAB workshop on Explicit Internet Naming Systems You’ve probably seen this, but just in case… From: Unicore [mailto:unicore-bounces@unicode.org] On Behalf Of Lisa Moore via Unicore Sent: Sunday, June 25, 2017 8:25 PM To: unicore(a)unicode.org<mailto:unicore@unicode.org> Subject: Fwd: Call for Participation: IAB workshop on Explicit Internet Naming Systems For anyone who might be interested, please check the info at the IAB link below. Thanks, Lisa -------- Forwarded Message -------- Subject: Call for Papers Date: Sun, 25 Jun 2017 04:29:33 -0700 From: Ted Hardie <ted.ietf(a)gmail.com><mailto:ted.ietf@gmail.com> To: lisa(a)unicode.org<mailto:lisa@unicode.org>, Michel SUIGNARD <michel(a)suignard.com><mailto:michel@suignard.com> Hi Lisa, Michel, I mentioned to each of you the workshop that the IAB is planning; the CFP is now out: https://www.iab.org/2017/06/22/call-for-participation-iab-workshop-on-expli…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iab.or…> I'd be happy for you to circulate it to folks in the Unicode world who might be able to contribute. regards, Ted

2 2

Draft Report: Evaluation of Web Sites for UA & EAI Readiness
by Don Hollander June 27, 2017

June 27, 2017

Please find attached a draft report based on the evaluation of more than 1000 of the most popular websites to see if they are UA & EAI Ready. We welcome comments before the 10th of July, and expect to publish the final version mid-July Don

1 0

Emoji domain names
by Satish Babu June 25, 2017

June 25, 2017

Three-part series by John Harrison of 🌐.ws, with some interesting information on emojis and their use, particularly by Search engines: https://medium.com/@cjharrison/a-digital-marketers-guide-to-the-power-of-em… https://medium.com/@cjharrison/ws-dc61d2395007 https://medium.com/@cjharrison/emoji-domains-have-no-future-bfd843299d51 satish

1 0

AUTO: Ahmed Bakhat Masood is out of the office. (returning 06/29/2017)
by Ahmed Bakhat Masood June 22, 2017

June 22, 2017

I am out of the office until 06/29/2017. I will not be able to respond to your mail. For urgent queries, please contact Mr. Shageel Ahmed Dy Director (ICT) at shargeel(a)pta.gov.pk or Mr. Anwar Zeb IT Officer at anwar(a)pta.gov.pk Note: This is an automated response to your message "UA-discuss Digest, Vol 30, Issue 10" sent on 06/22/2017 5:00:05 PM. This is the only notification you will receive while this person is away.

1 0

Now available on the UASG.Tech website, a blog post looking at the EuRID/UNESCO World Report on IDNs.
by Don Hollander June 22, 2017

June 22, 2017

1 0

Email Address Validation service providers?
by Don Hollander June 17, 2017

June 17, 2017

After a review of more than 1,000 websites for acceptance (or not) of email addresses in a variety of forms, the following conclusion is produced: "We have also noticed that most of the websites are giving error message in the same style. That is to say there are only a few commonly used filtering providers. If these providers can be reached out, than their clients (websites) will automatically become UA ready.” For those who do development, are there email validation routines or utilities that are commonly used? If so, where do you go to find them.? Don PS: The work done by ICANN’s Global Support Team, based on work that Donuts started several years ago, will be published before the end of this month. Just putting some prose around the analysis and doing some additional reviews. Don Hollander Universal Acceptance Steering Group Skype: don_hollander

3 2