The ICANNblog

Practical Implications Regarding ICANN’s IDN TLD Evaluation Deployment in the Root Zone

In my blog post, titled, “Evaluation Deployment in the Root Zone” I discussed ICANN’s program to enable routine introduction of TLDs (Top Level Domain) within IDN (Internationalized Domain Name) labels that utilize non-ASCII code sets. While some may be VERY familiar with the ASCII code set, others may not be aware that ASCII even exists. “Hey, a letter is a letter, right?” So, whether we know it or not we are used to using the ASCII character set. ICANN’s program, however, looks at utilizing non-ASCII code sets.

Since my last post on this topic I have had a chance to talk with a couple of people from non-English speaking countries to examine the practicality of the program’s end result.

In one instance I was told by one person how difficult it is for his wife, who is Chinese, to communicate current URLs to her friends in China when talking on the phone. For example, when talking about URLs, simple communication moves to translation, where possible, of each letter found in a URL. So in this example, utilizing non-ASCII sets within IDNs would be extremely helpful.

But as another person stated, “I thought the Internet was to be global!” In other words, if we start including non-ASCII character sets to allow for multiple languages, might we loose the global aspect the Internet represents today? Would people start thinking more regionally instead of globally? Is this a good thing? Is this a bad thing? I am interested in your thoughts.

However, let’s take this discussion out of the high level to a more practical view.

I had a detailed chat session over this topic with a friend of mine who lives in Sweden. Even if, or when IDNs are in place, will applications, other than browsers, be able to support non-ASCII character sets? For several years the “.SE” country code has been recognized. Great! You would then think that with an internationalized, or in this case the Swedish, version of Microsoft Office that all would be well and that Swedes could now begin using simple characters such as å ä ö. This may work well in Word, for creating documents, but when it came time to entering www.göteborg.se, the browser would not recognize the “ö”. It was only after IE 7.0 was introduced that “ö” was even recognized. But by this time, everyone was used to entering www.goteborg.se (with an “o”) instead of www.göteborg.se (with an “ö”). In other words, people are used to using the English-based character set instead of their native Swedish-based character set. Well, you say, “If now supported in IE 7.0, well all is good then, right?” Perhaps not. Let me answer a question with a question, “Do you suppose EVERYONE has upgraded to IE 7.0?” My take on this would be “no”.

To take this a step further, is it only the browser we need to be concerned with? No. Let me explain, as my Swedish friend and I were chatting over Yahoo! Instant Messenger, we were tossing URLs around. What he pointed out, which is common for his fellow Instant Messaging (IM) Swedes is when you enter a URL via your IM chat session, Yahoo! will underline the URL. You know, like what we are used to seeing, such as www.goteborg.se. However, when we used the letter “ö”, in the URL, such as www.göteborg.se, the underlining stops at the “ö”, thus displaying www.göteborg.se.

OK, so you say, “That’s Yahoo!’s problem!” Are you sure? Is this oddity limited to Yahoo! Instant Messenger? Test this out with other IM packages and let us know.

OK, so you now say, “Could this be a Microsoft issue?” Well not exactly as we tested Linux as well. To be specific we used a Linux-based system only to find that when sending an e-mail to someone whose e-mail address included a normal Swedish character, such as “ö” or “å”, the e-mail would result in an error message to the sender. For the purpose of example, I am changing my name from Chuck Kisselburg to Chuck Kåsselburg. My “NEW”, fictitional e-mail would now be chuck.kåsselburg@icannwiki.org. When sending an e-mail to myself the error message I would receive would be, Syntax error in mailbox address chuck.k?sselburg@icannwiki.org (non-printable character). So, this is another example where people will be forced to deviate from their native language, to continue using the English-based ASCII character set.

So, while my Swedish friend said, “While this may work well from the TLD perspective, everything needs to catch up.”

Someone also told me that when the Country Codes, managed by IANA (Internet Assigned Numbers Authroity) came out, some organizations moved to secure their “.com” equivalent with their respective country code, or country codes. Still, a couple of years after acquiring their respective URLs with their respective country code extensions, they were not really able to use them because, while defined, had not yet been fully implemented. Some felt this was a way for money to be made without providing the associated value. Also, what was discovered was as the country codes came out, many businesses did not realize this, so other people purchased an organization’s .com country code equivalent, placing that organization either at risk or facing a potentially expensive alternative to purchase back their country code specific URL. Some did not bother to acquire their .com equivalent.

True, some people would say talking with a couple of people does not represent a proper scientific, statistical sample. This by no means exhausts all of the issues surrounding ICANN’s IDN TLD program, but it does raise issues to think about.

What are your thoughts? Have you had similar experiences? Let us know!

1 comment August 16th, 2007