This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

  <http://www.unicode.org/reports/tr46/>

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 relevant here.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]