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

Nicolas Williams Nicolas.Williams at oracle.com
Fri Jun 18 01:39:31 CEST 2010

On Thu, Jun 17, 2010 at 11:30:38PM +0000, Shawn Steele wrote:
> > 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.

OK, that (try UTF-8 first, then ACE) could work.  Do you prepare the
UTF-8 in any way?  E.g., normalize it?  Case-fold it?  Or do you rely on
user input being in NFC already due to how input methods work?

> > 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.

My concern was: how do you do hostname resolution in an environment with
private sub-namespaces with non-IDNA IDN rules.

More information about the Idna-update mailing list