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