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:

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:

 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

Include all network paths (UNCs)
If "Automatically Detect Intranet Network" is enabled on a computer that is a member of a domain, all three of these options will be enabled regardless of what is configured through domain policy.

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!


no comments

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)

2011/09/16 There's no "I" in IDN, part 9: Who needs IDN support? How much? When? (Part 1)

2011/08/12 There's no "I" in IDN part 8: Punycode don't do the PUA

2011/07/28 There's no "I" in IDN, part 7: IDN comes to AdWords

2011/07/14 There's no "I" in IDN, part 6: It isn't like there's an "I" in EAI, either!

2011/06/29 There's no "I" in IDN, part 5: Stephen Colbert's job is not in any jeopardy

2011/06/17 There's no "I" in IDN, part 4: the 'path' to Hell is paved with IDN bugs

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