Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())

[Shawn Steele]

> So the OS knows about the intranet/internet distinction?

No, if you type Windows+R and http://somewhere.com, that URL is passed to the target app in Unicode, it doesn't matter where the target is.  The intranet (utf-8) / internet (ACE, actually, I did get utf-8 across the 'net years ago) distinction is currently handled by the application.  Basically it's a "Try UTF-8, if that doesn't work, try ACE" approach, but some apps do it the other way around.  Dave's looking at how to make the APIs smarter so the apps don't have to make silly guesses.

> And if the receipient is running FF on something other than Windows?
> (e.g., MacOS X, Linux, Solaris, *BSD.)

I don't have a clue how those work :)  

My understanding is that most browsers are happy to convert URLs to Punycode as necessary, I can't imagine why they'd have different logic on other OS's.  Certainly as a web author, I am NOT going to write href="http://xn--punycode".  Content authors are going to use Unicode (because they can read it).  So, unless you "fix" all the blog tools, etc. to convert Unicode to punycode, there's lots of hrefs in the wild that are outside of the ASCII space.

I've been led to believe that non-punycode hrefs have been seen "in the wild".  (Indeed I think they outnumber punycode ones).

I cannot imagine why you'd want to force a Unicode string to punycode to pass it between applications, unless you are doing a DNS query.  The canonical form should be U-label and that's what apps should exchange.

-Shawn