<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/3/2017 12:53 PM, Jim DeLaHunt
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:075eaa02-165e-7629-f6bc-58d05cf0008c@jdlh.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Don:<br>
</p>
In talking about punycode convertors that "produce bad results",
we probably have to distinguish between a narrow, technical view
of "bad results", and a more system-level, user view of "bad
results". Which did the UASG Workshop discussion refer to?<br>
</blockquote>
<br>
It's not just the converters in the browsers, it's converters in
various platform libraries as well. Some of those are not even well
documented, so you can't tell, without experimentation, what rules
they follow.<br>
<br>
In this context, will UASG adopt a position vis-a-vis UTS#46? That
standard attempts to somehow handle both IDNA2003 and IDNA2008
labels. I haven't looked into to what degree it fails valid IDNA2008
labels, but it certainly handles many IDNA2003 ones.<br>
<br>
Naively, "universal acceptance" would seem to mean you'd want this
kind of permissive handling, but it lands you deep in the morass of
emoji labels, among other things.<br>
<br>
A./<br>
<blockquote type="cite"
cite="mid:075eaa02-165e-7629-f6bc-58d05cf0008c@jdlh.com"> <br>
Specifically, to your questions,<br>
<br>
<div class="moz-cite-prefix">On 2017-11-03 09:42, Don Hollander
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D0E9DD38-2E9B-41C6-8EB6-DD6E4507A119@icann.org">
<pre wrap="">During the UASG Workshop in Abu Dhabi there was a brief discussion about Punycode converters.
1) Is anyone aware of any punycode converters (particularly in libraries) that produce bad results?</pre>
</blockquote>
As a software engineer, I'm confident that in the narrow technical
sense, many punycode converters produce bad results. In other
words, they probably have bugs. Most software does. They might
be rare, however.<br>
<br>
Also, I'm confident that many apps or systems which use
internationalised domain names do the conversion to and from
A-Label form (punycode conversion) wrong, even if the libraries
they use behave correctly. This would be due to bugs in how the
app or system uses the library.<br>
<blockquote type="cite"
cite="mid:D0E9DD38-2E9B-41C6-8EB6-DD6E4507A119@icann.org">
<pre wrap="">2) Is there a test suite that can be used to test Punycode converters?</pre>
</blockquote>
In the narrow, technical sense, our UASG018 <i>Programming
Languages Evaluation Criteria</i> document is a test suite, or
at least instructions on how to construct a test suite. The
obvious next step in the UASG018 is to implement actual test
suites, runnable software test code, which exercise the library's
Punycode conversion functionality (among other things).<br>
<br>
In the system-level, user view, our other evaluation activities
would be that "test suite". For instance, the <i>Evaluation of UA
Readiness of Popular Websites</i>, the <i>Universal Acceptance
of Popular Browser (UASG016)</i>, etc.<br>
<blockquote type="cite"
cite="mid:D0E9DD38-2E9B-41C6-8EB6-DD6E4507A119@icann.org">
<pre wrap="">3) Would the source of input (typed, cut/paste, input from a data file) make any difference? This probably has to do with RTL scripts
</pre>
</blockquote>
<p>In the narrow, technical sense, the source of input should make
no difference at all. The Punycode conversion algorithm doesn't
depend on the source of input. It starts with a sequence of
data, and the source of that data is not material.</p>
In the system-level, user view, the source of input might well
make a difference. I would expect that this takes the form of how
the app handles the data before it calls the library. When the
user selects a domain name, does the app select all the necessary
characters? Does the app implement the Unicode bidi algorithm
correctly, for text with both right-to-left and left-to-right
components? Does the app pass the domain name correctly to the
library? And so on.<br>
<br>
<blockquote type="cite"
cite="mid:D0E9DD38-2E9B-41C6-8EB6-DD6E4507A119@icann.org">
<pre wrap="">Thanks.
Don
Don Hollander
Universal Acceptance Steering Group
Skype: don_hollander
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--Jim DeLaHunt, <a class="moz-txt-link-abbreviated" href="mailto:jdlh@jdlh.com" moz-do-not-send="true">jdlh@jdlh.com</a> <a class="moz-txt-link-freetext" href="http://blog.jdlh.com/" moz-do-not-send="true">http://blog.jdlh.com/</a> (<a class="moz-txt-link-freetext" href="http://jdlh.com/" moz-do-not-send="true">http://jdlh.com/</a>)
multilingual websites consultant
355-1027 Davie St, Vancouver BC V6E 4L2, Canada
Canada mobile +1-604-376-8953
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>