IDNA and getnameinfo() and getaddrinfo()

Nicolas Williams Nicolas.Williams at
Tue Jun 15 19:40:56 CEST 2010

On Tue, Jun 15, 2010 at 04:54:46PM +0000, Shawn Steele wrote:
> We're in agreement, I think.  I'd rather have IDN work for getname,


> etc. by default though.  (Then maybe it'd "just work"?)  Instead of

Indeed, I think I might even want to reverse Simon's flags' semantics:
the default behavior should be to use U-labels as canonical and to
support searches by un-prepared text.

However, if Simon has already deployed his extensions...  Simon?

I think Simon's playing it safe, and perhaps a conservative approach
that results in A-labels by default in UIs is better.  I'll have to
think about this, but my gut feeling is that there's no reason that we
couldn't reverse the default sense of Simon's extensions.

> ToUnicode(), which is very specific, I'd prefer a more general
> "GetPrettyDNSName()."  Then, if more steps than just ToUnicode() are
> ever interesting, the gory details are hidden from the app.

At the abstract API level I think ToUnicode() is perfectly fine.  For
actual programming language bindings something else is needed to provide
the context.  For a language with "package" names that something else
could be a package name -- "DNS::IDNA", say.  For a language like C,
with a flat namespace we'd need the function name to be more indicative
of what it does, as in your suggestion.


More information about the Idna-update mailing list