IDNA and getnameinfo() and getaddrinfo()
dthaler at microsoft.com
Mon Jun 14 21:14:12 CEST 2010
> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at oracle.com]
> Sent: Monday, June 14, 2010 10:27 AM
> To: idna-update at alvestrand.no
> Cc: Dave Thaler; john+ietf at jck.com; cheshire at apple.com
> Subject: IDNA and getnameinfo() and getaddrinfo()
> Hello, I'm not subscribed to this list, so please Cc' me on replies.
> Over in the NFSv4 WG we're discussing how to fix NFSv4.1 to properly handle
> IDNA. In the process of doing so I ran into draft-iab-idn- encoding, which has a
> cogent discussion of name service switches (pictured in figure 2).
> draft-iab-idn-encoding aims for Informational status. I'm wondering if we could
> publish a Standards-Track document describing how getnameinfo() and
> getaddrinfo() should handle IDNA.
> For example, one could say that when using DNS getnameinfo() should:
Be careful not to confuse getnameinfo() with DNS.
As noted in draft-iab-idn-encoding and RFC 3493, DNS is just one of a number
of mechanisms used under getnameinfo().
> - perform the DNS lookup
> - apply ToUnicode() to the resulting domainname
> - attempt to convert the address' name to the caller's locale's codeset
> if that codeset is not UTF-8
> - if failure, then return the A-label as the canonical hostname
> - if success return the U-label (in the caller's locale's codeset)
> as the canonical hostname and the A-label as an alias
> And that when using DNS getaddrinfo() should:
> - convert the given host/domainname from the caller's locale's codeset
> to UTF-8 if necessary
> - apply ToASCII(), perform DNS lookups
As discussed in draft-iab-idn-encoding section 3, it's not that simple.
The ACE form applies in the public DNS but does not apply in many
private DNS clouds.
> - if success, return the IP address(es) found, the given name as the
> canonical hostname, the A-label form of the hostname as an alias,
> and the U-label form (converted to the caller's locale's codeset)
> as an alias if different from the given hostname.
The addrinfo structure returned by getaddrinfo() does not return
"aliases" per se. It can return a single string which is:
char *ai_canonname; /* canonical name for nodename */
> Would you agree? This would greatly simplify the application of IDNA to various
> application protocols, such as, for example, NFSv4. NFSv4 has several
> domainname slots, and several more coming from ancilliary protocols in current
> development. Being able to send un-pre-processed Unicode in NFS because the
> peer's getaddrinfo() must handle that correctly seems like a very good approach
> -- this way IDNA does not have to interfere with non-DNS name services.
In my view, yes you're on the right track in having NFSv4 not want to do
encoding conversion itself for name resolution but in expecting it to be
done under getaddrinfo/getnameinfo.
> Unfortunately we probably cannot rely on getnameinfo()/getaddrinfo() doing
> the Right Thing. A Standards-Track RFC on this would probably help.
Well API RFCs (like RFC 3493 for getnameinfo/getaddrinfo) are Informational,
not Standards-Track. But yes an RFC would probably help.
More information about the Idna-update