by Michael S. Kaplan, published on 2011/09/16 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/09/16/10212216.aspx
Previous parts in this series:
In an ideal world, IDN support will in future be utterly complete.
And I don't just say that as an owner responsible to get people in the company to be supporting IDN. :-)
Luckily, failing to live up to that ideal is not a requirement!
Now conversion to Punycode is obviously a support requirement, but by itself that doesn't help so much.
At this point it would be very helpful to lay out three basic categories of "IDN" requirements and talk about the relative importance of each....
ISSUE 1: Can use services like web sites that people publish which use Internationalized Domain Names:
This is the first and most basic requirement, being able to get to sites that are hosted on domains that use characters beyond the subset of ASCII that used to be required for domains.
Eventually everyone will need to be able to do this if we don't want larger and larger pieces of the Internet to evolve and leave the other parts behind unable to reach anyone.
Most commonly required is web sites, but over time many others can be required....
This is something Internet Explorer (IE) started doing in version 7.0 -- clumsily at first but steadily getting better and better (though without many web sites using IDN it was not as crucial for them or anyone to get better.
In theory others could do it before browsers did the work, but they had to do it all on their own.
The most impressive version of #1 is any application or protocol or platform that can do the steps laid out in part 3: There's no "I" in DIY, either!.
ISSUE 2: Can host services like web sites that can be published to others that use Internationalized Domain Names.
Obviously not everyone is an ISP or service provider or product that cam manage web sites and services that need this, but for those who do this is important.
And this is where a product like Internet Information Services (IIS) comes in, with later versions able to host themselves as whatever site you want them to.
Someone has registered an International Domain Name with an ISP and then they can host it in a product like IIS.
They may also need the ability to get referrer names from addresses and those names may themselves be International Domain Names. But that part is pretty easy on a machine that knows how/when to convert into and out of Punycode....
ISSUE 3: Can machine names support the full range of Unicode too?
This issue is the reason I put IDN in quotes -- because the only real connection it has to IDN is how many different services/applications on each machine -- like IIS or Terminal Services or Remote Desktop or SQL Server or whoever -- that uses the machine name by default.
In some cases, those services and applications have a way to create other names, and in some cases they don't.
But the fact that the default is so often the machine makes it compelling in the former cases and required in the latter.
For this issue, the support is incomplete.
This incompleteness is something I'll cover in the next part of the series.....
Stay tuned for the next exciting episode!
referenced by
2013/10/17 There's no "I" in IDN, part 19: There's no "I" in IPv6, either!
2013/10/08 There's no "I" in IDN, part 18: There isn't even an "I" in John C. Klensin's name!
2013/09/13 There's no "I" in IDN, part 17: EAI made it to China, and everybody knows it!
2013/04/19 There's no "I" in IDN, part 16: It's a good thing they decided to call it EAI!
2012/10/12 There's no "I" in IDN, part 15: Still no 'I' in EAI.... but we could use an US sometime soon!
2012/08/08 There's no "I" in IDN, part 14: It turns out there's no "I" in IE, either
2012/05/18 There's no "I" in IDN, part 13: Desktop and Managed and Metro; oh my!
2012/02/27 There's no "I" in IDN, part 12: Emoji + IDN == U+1F4A9 (PILE OF POO)
2011/10/25 There's no "I" in IDN, part 11: There's no place like ::1, not even 127.0.0.1!
2011/09/21 There's no "I" in IDN, part 10: Who needs IDN support? How much? When? (Part 2)