Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())
Nicolas.Williams at oracle.com
Fri Jun 18 01:14:49 CEST 2010
On Thu, Jun 17, 2010 at 10:56:28PM +0000, Shawn Steele wrote:
> > If a user e-mails another a URL using an IDN encoded in UTF-8,
> > and the receipient tries to load it with FF, and the namespace in
> > question uses UTF-8 instead of IDNA ACE encoding, will the FF
> > user be able to load that URL?
> It should, the OS sends the request to whatever your default browser
> is in Unicode, the browser better be able to correctly handle the
> link. AFAIK there's no big problems in this area in Windows (maybe
So the OS knows about the intranet/internet distinction? Dave Thaler's
comments had led me to believe it was IE that knew this. What if parts
of the intranet are not hosted on AD? Where's the intranet/internet
> some edge cases). Since we use *W APIs for everything, most of these
> scenarios work. Problem is only if the client doesn't know how to
> punycode, or if punycode gets injected unexpectedly into the *W API
> calls, or if there's some other protocol dependency that hasn't been
> updated beyond ASCII.
And if the receipient is running FF on something other than Windows?
(e.g., MacOS X, Linux, Solaris, *BSD.)
I'm guessing the answer is "no", "I don't know", or even "good luck" :)
The point is: your private-namespace-with-UTF-8-instead-of-IDNA solution
is almost certainly not interoperable in heterogeneous deployments.
(Pardon the redundancy. I shouldn't have to say "in heterogeneous
deployments", because that's implied, to me, by the word
"interoperable", but I do so anyways to be extra clear.)
More information about the Idna-update