RE: IDNA and getnameinfo() and getaddrinfo()

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 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.  Specifially, on machines hosting both UTF-8 (or other code page) and Punycode DNS, the actual form of "pretty" could differ depending on how a name was looked up.

For email, at least, UTF8SMTP is much smarter.  The DNS layer is muddy still, but at least the addresses are "just utf-8", and don't get to this state of having strange encodings leaking all over the place.

-Shawn

 
http://blogs.msdn.com/shawnste

________________________________________
From: idna-update-bounces@alvestrand.no [idna-update-bounces@alvestrand.no] on behalf of Nicolas Williams [Nicolas.Williams@oracle.com]
Sent: Tuesday, June 15, 2010 9:51 AM
To: Shawn Steele
Cc: idna-update@alvestrand.no
Subject: Re: IDNA and getnameinfo() and getaddrinfo()

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
--
_______________________________________________
Idna-update mailing list
Idna-update@alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update