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

Nicolas Williams Nicolas.Williams at oracle.com
Fri Jun 18 19:40:26 CEST 2010

On Fri, Jun 18, 2010 at 03:01:29PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams at oracle.com> writes:
> > On Thu, Jun 17, 2010 at 10:12:41AM +0200, Simon Josefsson wrote:
> >> I'm not sure what a use-case for AI_NO_IDN would be, but I suspect there
> >> may be some.
> >
> > There's no harm in having such a flag.
> Great.  I'm thinking of updating my draft to specify this, and to make
> it a bit less internal-memo-like.

Sure, please do!

> > I also want a AI_NO_CANONIDN, in preparation for a future day when
> > getaddrinfo() returns U-labels as the canonical hostname by default.
> I'm not sure this day will come.  There will always be software
> components that are written simplistically without IDNA support.  But
> I'm not strongly against the flag.  The downside is that it adds
> complexity with uncertain gain, something I generally prefer to avoid.

Does it add complexity?  Where?  At most you have to check for mutually
exclusive flag uses.

> The AI_NO_CANONIDN flag could also be introduced later on, when we
> actually consider making the change you suggest, and we may be in a more
> informed situation to specify the flag more precisely at that point too.

I can certainly see a use for it now: if you want a canonical name
that's safe to place in an IDN-unaware domainname slot and want to allow
for a future when getaddrinfo() returns U-labels by default.

If we don't provide AI_NO_CANONIDN now then we will never be able to
have getaddrinfo() return U-labels by default.  That's painting
ourselves into a corner.  Why?


More information about the Idna-update mailing list