There's no "I" in IDN, part 3: There's no "I" in DIY, either!

by Michael S. Kaplan, published on 2011/05/25 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/05/25/10168228.aspx

Prior blogs in this series:

• There's no "I" in IDN, part 1: If you're not Unicode, you're just wrong!
• There's no "I" in IDN, part 2: Try not to use the wrong functions!

As I started deciding what I was going to write in this third part, I thought back to the initial guidance.

And how both initial parts strongly encouraged people to be calling the appropriate functions, since calling the wrong ones are never such a great idea.

But looking at the current landscape, for all intents and purposes the only Microsoft application that works properly here (most of the time) is Internet Explorer. And even it gets the answer wrong some of the time (a fact only discovered a few months ago, even though the bug has apparently existed since Internet Explorer 7's RTW -- some specific scenario where IE takes a URL already in UTF-8 and converts it to UTF-8 again, with the expected cottage-cheese-inducing results).

For all applications, there are several different possibilities for any Internationalized Domin Name access:

• INTERNET (everything is registered as Punycode)
  • If you convert the URL to Punycode
    • Everything works!
  • If you don't convert the URL to Punycode
    • Everything fails!
• INTRANET (everything is [usually] registered as UTF-8)
  • If you're calling the right functions
    • Everything works!
  • If you're not calling the right functions
    • Everything fails!

 Now this little tree of options looks awfully simple, here on this blog.

But unfortunately it isn't simple at all -- because there is a real lack of a standard method to distinguish Internet from Intranet at the application level.

And IE is a messy clusterf*** of meaning trying to make sense of it, as KB articles like 2028170: Enabling "Automatically Detect Intranet Network" on a domain member computer will enable all the three Intranet Options automatically hint at:

By default in Internet Explorer 7 and Internet Explorer 8, "Automatically Detect Intranet Network" will be enabled to automatically control the following three options of Intranet detection: 

Include all local (intranet) sites not listed in other zones

Include all sites that bypass the proxy server

It is marked as by design, and the resolution section gives complex instructions explaining how to override these settings through administrative templates.

Not for the meek!

Of course the engineer immediately jumps to an obvious question: why not require Punycode names to be assigned as aliases for even the INTRANET scenario?

Such a requirement would have made everything easier, for everybody!

But you have to consider the original reason for Punycode: to support IDN without requiring the existing infrastructure to change.

Well, the Intranet has been working just fine on UTF-8 and in some cases even with legacy code pages, and trying to force a change in all those cases would break a lot of people.

Though I still believe publishing as a recommendation would really have made life easier for a lot of people, it was not be. In the current situation such INTRANET Punycode server names represent an easy way to test that the Punycode scenario works for anyone smart enough to convert to it for later INTERNET testing. Given the role that proxy servers place, testing resolution within an organization would be quite difficult without using Punycode resolution within the INTRANET.

For now, if you use IE's zone-based support (or one of the few others like that inherent in AD/Exchange), you too will work as well as they do.

Or you can DIY (Do It Yourself), which can be pretty complicated, depending on your scenario.

There are many who feel that this is not good enough in the long run, that both Windows and .NET both need to try to make this easier. So people look to the future with interest.

Some of those people are doing nothing until they see some signs of future improvements, while others are doing the things like those from Part 1 and Part 2 of this series, and keeping those endpoints in discrete bits of their code so that if they eventually still need to add a DIY piece they can add it, but just in case the system underneath comes up with the right answers everything might just work.

I think that latter group will be in the best position to later either do nothing or in the worst case do a small amount of work.

Realistically, few will do their own work to do what IE/AD/et. al. are doing here. There really is no "I" in DYI since it will take a lot of work, and definitely implies a "we" with a lot of developers and testers!

referenced by

go to newer or older post, or back to index or month or day