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@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_pabcZ172nC... - 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