Don:
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.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?
In the narrow, technical sense, our UASG018 Programming Languages Evaluation Criteria 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).2) Is there a test suite that can be used to test Punycode converters?
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
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.
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.Thanks. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander
--
--Jim DeLaHunt, jdlh@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
multilingual websites consultant
355-1027 Davie St, Vancouver BC V6E 4L2, Canada
Canada mobile +1-604-376-8953