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

[Anthony Jones]

I would prefer the default behavior to be as if AI_IDN/AI_CANONIDN were specified. As noted in other responses, requiring applications to know about the different encodings will likely result in some apps still getting it wrong. In my opinion, having the platform automatically perform IDN is preferable and then provide flags for opting out. I think having other configurable knobs is a good idea as well. For example, being able to opt either the entire system out of the IDN behavior or on a per application basis. There may also be instances where a given domain has both Punycode and UTF-8 resources such that a policy mechanism for giving a specific encoding for a FQDN or domain would also be useful.

-Anthony


On Tue, Jun 15, 2010 at 09:40:38AM +0200, Simon Josefsson wrote:
> I've published my getaddrinfo extension writeup as an IETF document, to
> facilitate discussions.  See announcement below.

Thank you Simon.  This is very useful.

> It isn't clear from the writeup, but this code has been shipping in GNU
> Libc for many years, so if you are running GNU/Linux chances are you
> have had this functionality for quite some time.  You can test it
> through a code snippet like this:

Ah, it's good to know that this is shipping.

I think it might be a good idea to add AI_NO_IDN and AI_CANON_NO_IDN
flags.  That way in the future we could change these functions to behave
by default as if the application had used AI_IDN/AI_CANONIDN.

I can see the default behavior of getaddrinfo()/getnameinfo() being
configurable system-wide, at least initially until we obtain enough
deployment experience.  Specifically, I'd like to see what, if anything,
breaks if getaddrinfo()/getnameinfo() act as if the application had used
AI_IDN/AI_CANONIDN; I suspect there will be very little breakage, and if
that's so then I think we can stand to get much more benefit from having
that be the default behavior than from it being optional.

Comments?

Nico
-- _______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update