This is the mail archive of the
mailing list for the glibc project.
Re: What to do about libidn?
On 11/09/2016 12:30 AM, Joseph Myers wrote:
On Tue, 8 Nov 2016, Florian Weimer wrote:
This has several problems:
8. Updating libidn would be problematic for license reasons (it's
non-FSF-assigned and upsteam is now LGPLv3).
9. Unicode UTS #46 uses an IDNA2008 customization mechanism to get
behavior which is closer to IDNA2003:
This suggests that as of 2016, we are still supposed to use the IDNA2003
compatibility mappings because the “transitional period“ is not over
(otherwise, why include it in the document?).
Reportedly, Chrome still uses transitional processing (or something
closer to IDNA2003 than to IDNA2008). I've verified that the Fedora
Chromium build does this. Internet Explorer 11 and Edge on Windows 10
also implement something more closely related to IDNA2003.
So libidn2 might not even be the right choice.
I wonder if we could define a protocol extension to offload these policy
decisions to the recursive resolver.
But then, an application which resolves host names probably needs to
display them as well, and this needs slightly different logic because a
IDNA host name could successfully resolve over the Internet, but the
application is not supposed to show the IDNA name, only the
“xn--”-encoded name. This suggests to me that the application needs
additional logic anyway (something we do not expose right now). The
canonical name and the AI_CANONIDN option is of no help here because the
canonical name is often a generic CDN host name, which is not really