Re: IDNA and getnameinfo() and getaddrinfo()

[Nicolas Williams <[e-mail]>]

On Tue, Jun 15, 2010 at 04:09:13PM +0000, Shawn Steele wrote:
> FWIW: I don't think that applications should need to understand how
> DNS works.  (Something of a seperation of business logic concept as
> probably taught in, like, CS101 - "Don't make your app know more than
> it has to.")  IMO it'd be nice if app developers that need to open a
> connection to a server had all the Punycode ugliness layered away by
> some nice set of DNS APIs, or even higher level at the open connection
> APIs or whatever.

Simon's extensions for getname/addrinfo() are the kind of APIs I'm
looking for.  I'm not sure if that's what you have in mind, but I'd love
to hear about it.

> Unforunately, Punycode means that some apps will want to decode the
> string anyway because they'd like pretty names.  Some sort of
> getcanonicalname() or something could help there.  I realize there's
> an "A" in "IDNA", but if every app has to do punycode conversion
> themselves there's going to be tons of odd inconsistencies in what
> they're doing.  It could also mean "tweaking" thousands of apps if the
> IDNA20xx rules change a little.  (Eg: like the bidi rules did this go
> around).

If an application is just dealing with hostnames then it's easy:
ToUnicode().  If the application needs hostname<->IP address resolution
then it needs something more like getname/addrinfo() with suitable
enhancements.  If the application needs to deal with e-mail addresses,
IRIs, etcetera, then the application is going to need APIs that are
specific to those.  The alternative is that the application must
implement all the relevant rules, all the time, and as draft-iab-idn-
encoding explains, that isn't always possible (the example being the
name service switch in typical operating systems).  It will be better to
have context-specific APIs.

> The good thing about Punycode/IDN is that it enabled DNS.  The bad
> thing is that suddenly any network app needs to become a DNS expert.

To some degree that's unavoidable, but with context-specific APIs we can
minimize the burden on applications.  We should do just that if we want
IDNA to succeed beyond the web browser (do we?).

Nico
--