Are there any technical issues with having an 'internationalized' domain name?

Question

In my language there are numerous characters that are not allowed in the standard domain name. However, most of these can be easily replaced with safe equivalents (mostly dropping accents í becomes i etc.). So while we have often registered both forms (e.g. timarit.is and the proper Icelandic tímarit.is) we have always made the 'safe' form the default and the other merely redirects to it.

However, we are now in the position where the substitution is less favorable (æ becomes ae) and would prefer to use the internationalized name by default.

My question is simply if there are any known issues with this? Browser incompatibility comes first to mind, but I'm equally worried there are other things that aren't coming to mind.

BOUNTY

I started a bounty on this so I won’t have to post a duplicate question. I’d like to hear if there are any practical consequences using IDNs with (1) FTP and (2) e-mail servers/clients; and (3) which browsers struggle with the domains? (4) What about mobile devices‽ Also (5) has anything changed on the subject—it's almost a year since the question was asked.

Answer 1

Search engines generally do not have any problems with IDNs (I can't speak for the others, but at least that's the case for Google). Apart from issues on your side (maintenance, etc) and on the user side (browser issues - which are luckily going away as more users have modern browsers), I don't see much of a problem.

Some of the more general and only indirectly search engine related things that come to mind are:

• Some users may have trouble linking to your content, especially if they don't have the right keyboard layout, so it is generally a good idea to provide an easy way for users to copy & paste a link for reuse. If you are providing a HTML snippet, make sure you use the punycode version of the domain name so that you don't have issues with page encodings.
• Sometimes you may want to use multiple domain names to catch typos (eg. timarit.is vs tímarit.is). If you do that, make sure to pick a preferred domain name and use site-wide 301 redirects to that domain name.
• If you use non-7-bit-ASCII in path, file or query parameters, make sure to use UTF-8 for that. Also make sure that these are encoded properly for link snippets (see first point).

Answer 2

The character encoding of your content management system is one issue that comes to mind. Also, if you're promoting your website, a lot of URL validation inputs will probably break on your URL.

Answer 3

(1) FTP

It appears that you do need an FTP client that can handle IDNs as it does require special support. Based on what I've read while researching this, that support seems to be widespread and a common feature in all major FTP clients.

(2) e-mail servers/clients;

Based on the wikipedia article for International Email it looks like email support is not complete:

Since Traditional E-mail standards constrain all e-mail header values to ASCII only characters, it is possible that the presence of UTF-8 characters in e-mail headers would decrease the stability and reliability of transporting such e-mail. This is because most, if not all, e-mail servers, at the time of this writing, do not support these characters.

A method has been proposed, by members of the IETF, by which e-mail can be downgraded into the "legacy" all ASCII format which all standard e-mail servers should support. This downgrade mechanism fulfills the requirement that e-mail transport be as robust and reliable as possible.

.

(3) which browsers struggle with the domains?

It looks like all of the major browsers support IDNs and have done so for at least two years. The only real issue you may have is with older browsers that do not support IDN. But since IE seems to have supported it since IE7 and the other major browsers' userbase update quickly, this should be a small number of users.

(4) What about mobile devices‽

Good question. It appears as though the .mobi domain name does not support IDNs. I couldn't find anything specific to the devices themselves but I did find companies claiming they had solutions for IDNs on mobile so I am guessing that native support may not exist or is not complete.

(5) has anything changed on the subject—it's almost a year since the question was asked.

Some country specific TLDs have added support and it looks like spammers have found a way to exploit them. But that's about as much that has changed.

Answer 4

1. Squatters or competition *will* buy the romanized version of your domain name, eventually.

   So if it's of any importance (or that may gather importance with time) you will have to buy both.

2. Spammers and phishers.
   Unicode is full of characters that look a lot like latin ones.

   They're only starting to use them right now, but in some months, unnecessary IDN names might start to look phishy.

3. International visitors with a non icelandic keyboard layout might just hate you. But then, if you're not planning of putting that name on business card, that might not be such a big deal.

Anyway... ☺.com must be the state of the art of the un-necessary IDN usage

Post-Scriptum: Guess who doesn't support IDNs like ☺.com? Stackexchange :)
Had to dig for the xn-code by hand. :/

Answer 5

We tried using the IDN version of the domain as the default but eventually ran into problems with some browsers (including Firefox) and Adobe Reader where the IDN domain name just got mangled in the hand-off to the browser plugin.

So now we use the 'safe' mode and the IDN simply does a 301 redirect to it.