[idn] Interoperable IDNA implementations.

[Paul Hoffman / IMC <phoffman@imc.org>]

Greetings again. As part of the effort to move the IDNA documents 
from Proposed Standard to Draft Standard, we need to show at least 
two independent interoperable implementations of IDNA (talk about 
alliteration!). Of course, IDNA is not a client-server specification, 
so showing interoperability is not simply a case of creating a client 
and a server.

Instead, as part of the work performed at the IDNConnect event last 
month, I created what I hope to be a very complete test suite for 
IDNA. This includes testing every part of the IDNA spec, every part 
of the Nameprep spec, and every part of the Punycode spec (where 
"every part" means all the protocol steps, not just the MUSTs and 
SHOULDs). The full set of tests is described at 
<http://idnconnect.jdna.jp/Description.txt>. (IDNConnect and the 
continuing development of the testbed are funded by the Japanese 
Domain Names Association.)

The actual tests were created using the original set of tools that I 
created in Perl during the creation of the IDNA specs. During the 
event, implementers from around the world tested their code against 
the tests; we did not run the tests in a central environment, and 
results of the test were not kept. Most test participants reported 
that they found bugs in the software and have fixed them.

Subsequent to the event, I have validated one (unnamed, pre-release) 
IDNA system passes all the tests that it should pass, and fails all 
the test that should fail, as specified in the test description. This 
may be sufficient for two independent interoperable implementations: 
the creation of the UTF-8 and Punycode strings, and the system that 
interpreted each of them. I have been told by some developers that 
there are other implementations that pass all the tests, but I have 
not checked that myself. It is up to the Area Directors to decide 
whether or not the testbed tests every part of the RFCs, and whether 
having a single system that performs on each string is sufficient for 
two systems.

Please note that I could not test every part of the testbed as 
described. I could not perform 2-8-1 because I could not enter a 
string that contained a character that was later mapped out. (If 
anyone has an IME for Windows XP that lets me enter characters by 
their Unicode value even if they are not represented in a font, I 
would appreciate hearing from you!) Further, I could not perform 
2-8-2 through 2-8-5 because the name server we tested against 
wouldn't let me load an illegal name into the test zone. (If someone 
can show me how to hack BIND 9 in order to allow labels longer than 
63 octets in a zone, I would appreciate hearing from you!) Given that 
these tests (which exercise step 8 of ToASCII) are pretty obscure, I 
hope the ADs forgive the lack of these edge-condition tests.

While the ADs are mulling over the tests and whether these two 
systems are sufficient, I am quite open to suggestions for changes 
and additions to the items tested. Please read the description file 
mentioned above and let me know if there are any tests that I should 
have included but missed, or any that need to be clarified.

Developers who want to run their software through the testbed should 
see the information on the main IDNConnect web site at 
<http://idnconnect.jdna.jp/> and download the testbed themselves. The 
testbed requires Perl, BIND, and Apache, but should be able to be 
converted to other systems as well. It also includes tests for 
IDNA-aware mail clients and test harnesses. The testbed will continue 
to be developed and freely available, so any suggestions are always 
welcomed.

--Paul Hoffman, Director
--Internet Mail Consortium