I-D Action:draft-josefsson-getaddrinfo-idn-00.txt

[Simon Josefsson]

Nicolas Williams <Nicolas.Williams at oracle.com> writes:

> On Tue, Jun 15, 2010 at 11:45:38PM +0200, Simon Josefsson wrote:
>> That could be tried in an experiment, but I believe any effort to make
>> that the default, or even any effort to standardize anything here,
>> should be co-ordinated with the Austin group.  That is also really the
>> place where the POSIX experts hang out and can tell whether this is a
>> good idea or not, from a POSIX standardization point of view.
>
> Hmmm, actually, POSIX/SUS cannot really control what is a canonical
> hostname here.  That's for the name services standards to decide, not
> for the API.  And since these functions do not list aliases, and since
> aliases are clearly supported by a variety of name service, it's clear
> that:
>
>  - making getaddrinfo() support lookups by IDNs encoded in the caller's
>    locale's codeset, converting to Unicode and applying IDNA as
>    necessary, is perfectly legitimate

Certainly.

>  - making getaddrinfo() return either A-labels or U-labels (in the
>    converted to the caller's locale's codeset) as ai_canonname when
>    AI_CANONNAME is requested is also perfectly legitimate

Yes.

> However, returning anything other than A-labels risks leaking of IDNs
> into IDN-unaware slots by IDN-unaware applications.

True.

> Therefore I think that getaddrinfo() should support lookups by IDNs
> encoded in the caller's locale's codeset as described above, but should
> return A-labels unless a hint is given that U-labels are preferred.

In other words, you want AI_IDN to be the default behaviour, but not
AI_CANONIDN.  There likely needs to be an AI_NO_IDN or similar if an
application for some reason wants to disable IDN processing of inputs.
I'm not sure what a use-case for AI_NO_IDN would be, but I suspect there
may be some.

/Simon