Good idea, wrong test. IDN & Email is still under standardization

http://www.ietf.org/dyn/wg/charter/eai-charter.html

Even RFC 5336 is still only experimental, not full standard yet.

James,

Actually, it is a bit more complicated than that. the EAI WG works on how a SMTP server and POP3/IMAP4 server deals with Unicode, mostly on the left hand side of the e-mail address.

I understand from the original posting that the test was more on how forms on web sites accept and process IDNized e-mail addresses. I had a similar post, related to the fact that web forms validate e-mail addresses according to software routines, and that many of these have not been updated for some time. Just google for “email address validation javascript” and you will see what I mean. My concern was more related to the acceptance of new TLDs, but obviously this is also true at the second level.

I guess the result of the test would have been quite different if Th. Kühne had submitted .(JavaScript must be enabled to view this email address), rather than user@??.com.

This will be a major issue and showstopper for the wide adoption of IDN TLDs in my opinion.

Patrick, noted the differences.

But I disagree it is a show-stopper.

It is a chicken and egg problem. Do programmers of the website fixed their javascript and backend first before we deploy or do we deploy and let them encounter problem so they can be fixed?

The issue here is most people don’t even realize they have a problem until they encounter it. Afterall, IDN isn’t that widely used in most of the US sites.

This is also somewhat true for a lot of Asian website but I will bet they will get fixed faster, once people started using IDN.

I agree with James Seng that the inability of a piece of software to support an IDN should be a show-stopper. However there is a more complex discussion of the relationship between a DNS address and a protocol.

When RealNames introduced country and language namespaces back in 1999 we explicitly focused on the browser address bar as an input mechanism and nationally specific and language specific namespaces as an modus operadi. Our reasons for doing so were multiple:

1. The browser sends country and language settings in its header, allowing us to be intelligent about user-inputs and our responses.
2. The ability to set namespace level rules was important to us. Korean, Chinese, Japanese etc all want to maintain their own rules governing how to behave in various circumstances.
3. We wanted to focus on the http protocol, which is a big win as a first-to-market feature, even though we knew adoption for various other protocols would be slower.

When we partnered with veriSIgn in 2000-2001 over IDN v1, http was certainly the target and the most asked for protocol.

So…that said, I think that as IDNs are rolled out, being smart about disclosing issues and focusing on what works now versus what will work later is a key take-away from our experience.

Best
Keith Teare

Typo above. I mean that I agree with James that the inability of a piece of software to support an IDN should NOT be a show stopper.