December 2016 - UA-discuss

Merry Christmas - Big News for EAI
by Dr. AJAY D A T A Dec. 25, 2016

Dec. 25, 2016

Dear Friends,Wishing you all Merry Christmas. Today as Christmas Gift, we have enabled all DATAMAIL app customers with Webmail access, which was not there before. So now all EAI accounts have full web / mobile access. This webmail has features which no webmail (gmail/outlook/yahoo) has till now. Two days before a big push was given to EAI acceptance through BSNL - The largest Government owned telecom company. Now a FREE Email account on BSNL IDN domain डाटावन.भारत was enabled to 90 million customers powered by DATAMAIL. Please see the news link below. https://telecomtalk.info/bsnl-launches-free-linguistic-email-address-to-emp… can actually google "DATAMAIL BSNL" to see 100+ articles. Seasons Greetings,Best Wishes Dr. Ajay DATA | Founder &amp CEO Get email id like अजय(a)xn--c2bd1gb.xn--h2brj9c in your own language,visit www.xgenplus.com Do not Remove: [HID]20161225110701543[-HID]

2 1

iDNA language support
by Tex Texin Dec. 23, 2016

Dec. 23, 2016

Hi, I was wondering how well supported iDNA was in the more popular languages. A quick search for <programming language> iDNA shows that most of them support iDNA, some going back to 2006 or earlier. These languages and libraries support IDNA. I have used IDN is some of them and the support has generally been very good. java php node.js python .Net (C#, C++, F#, VB) ICU libIDN (C++, ruby) Most browsers also support IDNA very well. The one area that seems problematic (based on searching and problems reported) is JavaScript. Despite the browser support, native Javascript support seems problematic and the libraries (JQuery etc.) don’t do a good job. I am not surprised by the libraries as JS libraries often don’t do a good job of i18n support. However, I am surprised there isn’t a native dom function or ecmascript specification for ToUnicode or ToASCII. Maybe my quick search missed it. However, Node.js offers a punycode.js library for javascript users that is popularly recommended. I would normally consider the issue settled but I was concerned from the search that there may be several offerings out there called “punycode.js” that are not the same or the same quality. It bears a bit more research. I think the support for RFC 3490-3494 is very good. There could be a question about support for the newer specs RFC 5890-5895 since they have only been around since 2010. To me this raises the question of where UASG should focus. If the industry supports the older specs very well perhaps UASG should give attention to the newer features in the 2010 specs. I find myself questioning how much of a problem actually exists. UASG could consider a very superficial survey of where the problems are. For example, define a few test domains and perform the simplest tests with each of the programming environment. For example, in my own work I have an international domain I own (http://globalização.biz/) which I use for testing email and domain name support. UASG could set up its own international TLD and subdomains and email account, and ask its community of developers to verity they can access the site with both Unicode and punycode forms and then submit information thru a web page to update a google doc to identify the library/ or framework and success or fail. The email account would just have an auto reply that acknowledges receipt of the mail confirming sending to and from an IDN email address. The google doc would be something like: Language/Library Version Unicode Domain Test Punycode Domain Test Email Test Testers Name/Contact Info Tester’s Additional Notes … After the initial survey, if it proves helpful more elaborate tests can be surveyed. Or more focus can be given to those programming environments that seem problematic. tex

1 0

Criteria for Evaluating Programming Languages and Frameworks with regard to their UA Compliance
by Tex Texin Dec. 22, 2016

Dec. 22, 2016

Don, et al I have a couple comments, which will be critical but are intended to be constructive. I added a few other comments in the google doc. I think if we continue on the current path it will take a very long time to develop an acceptable document. The current document does not use the correct terminology or the terminology as it is used in industry. There also seem to be some basic misunderstandings. For example, the dependency on RFC3492 and Punycode is overdone and ignores RFC3490 and all the other steps (and specs) necessary to properly support IDNA. The way URLs, TLD, domain names, email addresses are mixed will be hard to unravel where the differences are important to discuss. My suggestion is to take a step back and outline what programmers do with URLs, domains, email addresses, and then determine the functions that they need supported. Clearly, the use cases include store, retrieve, syntax validate, identify, convert between Unicode and ASCII forms, compare for equivalence (match), parse, render/display, et al. There are also error detection cases we can enumerate. On the flip side, the components (libraries/frameworks/languages) that allege to provide support for these functions can be described and their minimum requirements and possible error cases enumerated. It is important that this be done in the context of the relevant standards and perhaps some of the existing well regarded libraries. (ICU for example). Once the outline is agreed upon, it will be easier to get agreement on the language of the specification, the acceptance list, and perhaps include test cases. The outline should perhaps be developed by one or more individuals that are very familiar with the IDNA (and email, IRL, etc.) specifications and have programmed their use. It is important that the document do a much better job of reflecting the language of the industry and the IDNA and other specifications and reflect typical usage. Sorry if this seems harsh but I think it is better to be frank and realistic to be constructive. Separately, I am going to have a heavy travel period beginning in January so may not be able to attend many calls. Best regards, tex From: ua-discuss-bounces(a)icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Don Hollander Sent: Monday, December 19, 2016 11:57 PM To: ua-discuss Subject: [UA-discuss] Notes from UASG Call: Criteria for Evaluating Programming Languages and Frameworks with regard to their UA Compliance (continuation) 2016-12-20 Attached are the notes from this morning’s call. Next steps: - comments open on document through 2016-12-25 https://docs.google.com/document/d/1oSFm8NeXzTvIvhzr9mKYVAk2t7KoD_pabcZ172n… - Document revised 2016-12-26 - 2017-01-08. - Next call schedule for week starting 9 January 2017. If there’s interest we’ll schedule two calls to allow all time zones reasonable access. Please let me know, or we’ll continue with the same time we’ve been using. Don

1 0

Notes from UASG Call: Criteria for Evaluating Programming Languages and Frameworks with regard to their UA Compliance (continuation) 2016-12-20
by Don Hollander Dec. 20, 2016

Dec. 20, 2016

Attached are the notes from this morning’s call. Next steps: - comments open on document through 2016-12-25 https://docs.google.com/document/d/1oSFm8NeXzTvIvhzr9mKYVAk2t7KoD_pabcZ172n… <https://docs.google.com/document/d/1oSFm8NeXzTvIvhzr9mKYVAk2t7KoD_pabcZ172n…> - Document revised 2016-12-26 - 2017-01-08. - Next call schedule for week starting 9 January 2017. If there’s interest we’ll schedule two calls to allow all time zones reasonable access. Please let me know, or we’ll continue with the same time we’ve been using. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Conference Call: Continuation of Review of Programming Language Review Criteria
by Don Hollander Dec. 19, 2016

Dec. 19, 2016

This is a meeting to continue the discussion on Programming Language Review Criteria. http://participate.icann.org/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# The documentation for review and comments is at https://docs.google.com/document/d/1oSFm8NeXzTvIvhzr9mKYVAk2t7KoD_pabcZ172n… If necessary, we will convene the next day, one hour earlier. Don

1 0

Conference Call: Continuation of Review of Programming Language Review Criteria
by Don Hollander Dec. 19, 2016

Dec. 19, 2016

This is a meeting to continue the discussion on Programming Language Review Criteria. http://participate.icann.org/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# The documentation for review and comments is at https://docs.google.com/document/d/1oSFm8NeXzTvIvhzr9mKYVAk2t7KoD_pabcZ172n… If necessary, we will convene the next day, one hour earlier. Don

1 0

Doodle Poll - Next call to Review Programming Language Evaluation Criteria
by Don Hollander Dec. 13, 2016

Dec. 13, 2016

Here’s a doodle poll to find a date and time for a continuation of yesterday’s call. http://doodle.com/poll/hzatbv4camnt33u2 <http://doodle.com/poll/hzatbv4camnt33u2> Please respond promptly and I’ll report the best date on my Sunday. Thank you. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Notes from UASG Call: Criteria for Evaluating Programming Languages and Frameworks with regard to their UA Compliance
by Don Hollander Dec. 13, 2016

Dec. 13, 2016

Attached are the notes from today’s call. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

2 1

💻Review of Evaluation Criteria for UA Readiness Review of Open Source Programming Languages💻
by Don Hollander Dec. 12, 2016

Dec. 12, 2016

This is an invitation to a call to review the Evaluation Criteria for UA Readiness of Open Source Programming Languages. The draft criteria are attached. Written comments are welcome for those unable to participate in the call. If you are not a software geek, but have colleagues who are software geeks, please encourage their participation. http://participate.icann.org/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# NB about the connection: This is an Adobe Connect link. If you’ve never joined this room, please give yourself five minutes to install any necessary software. Audio connections also available at the numbers above. The meeting will be recorded. Agenda: - Introductions - Setting the Scene/Objectives – Don - Overarching Comments - Review of the document – section by Section – Frank o Real-time editing via Google Docs o

2 2

💻Review of Evaluation Criteria for UA Readiness Review of Open Source Programming Languages💻
by Don Hollander Dec. 12, 2016

Dec. 12, 2016

This is an invitation to a call to review the Evaluation Criteria for UA Readiness of Open Source Programming Languages. The draft criteria are attached. Written comments are welcome for those unable to participate in the call. If you are not a software geek, but have colleagues who are software geeks, please encourage their participation. http://participate.icann.org/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# NB about the connection: This is an Adobe Connect link. If you’ve never joined this room, please give yourself five minutes to install any necessary software. Audio connections also available at the numbers above. The meeting will be recorded. Agenda: - Introductions - Setting the Scene/Objectives – Don - Overarching Comments - Review of the document – section by Section – Frank o Real-time editing via Google Docs o

1 0