Internationalized (non-ascii) domain names (IDN) are a key issue for ICANN. Yesterday, the Board completed two days of workshop presentations about various matters (IANA, security, GAC relationships), and we were briefed on the IDN testing that is planned.

I thought it might be useful to make clear the distinction between the tests (which are testing mechanisms for IDNs) and the very difficult policy questions that confront ICANN. As several people explained to me yesterday, they’re different.

The test (announced here) will be looking at two approaches: DNAME and NS-records. DNAME essentially (as I understand it) makes an alias designation for an entire domain possible. So, if you were testing the top level domain .test (an imaginary domain) with DNAME, you’d be mapping all of .test into an IDN equivalent of .test. From the end-user’s perspective, whether you typed in susancrawford.test or [non-ascii script susancrawford].[IDN equivalent of .test], you’d go to the same place.

DNAME would make it possible for an existing TLD operator (for a real domain, not .test) to control registrations in other scripts.

The other approach, NS-records, permits the insertion of an IDN (encoded) into the root. So this means that a new non-ascii TLD using NS-records could be proposed. The test of NS-records would involve, e.g., seeing if different script versions of .test work when they are inserted into the root.

These are two mechanisms. The policy decisions—whether existing gTLDs or ccTLDs should control their script “equivalents” (and how to decide what an “equivalent” is) haven’t been made, and won’t be until the results of this test are known and can be evaluated.

And even once the tests are over, it doesn’t seem as if a single uniform global decision (either DNAME or NS-records) will necessarily result. These two methods aren’t mutually exclusive.

These are very difficult policy questions, but the test seems to me to be just that—a test of two mechanisms.