help-libidn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libidn2 0.13


From: Nikos Mavrogiannopoulos
Subject: Re: libidn2 0.13
Date: Tue, 3 Jan 2017 10:00:53 +0100

On Mon, Jan 2, 2017 at 10:17 PM, Tim Rühsen <address@hidden> wrote:

>> * APIs more like libidn's that take a full domain name and do proper
>>   operations on them.  In several forms, UTF-8, USC-32, locale encoded,
>>   etc.
>>
>> * APIs to decode a IDNA2008 domain from ACE to Unicode format.  That is
>>   not described by the IDNA2008 RFCs, interestingly enough, but I
>>   suspect people will want it, hah!
>
> Wget used to use ACE decoding from libidn, but only for logging/displaying
> purpose. Since we switched to libidn2, the UTF-8/locale named will not be
> displayed any more :-). With such a function I would reactivate the logging
> code.

For gnutls unfortunately the reverse is really necessary and that's
the reason we are stuck with libidn. We need to be able to print the
actual name of the certificate and not only the punycode which is
non-human readable for most languages.

[...]

> IMO, all applications that use DNS lookups should be updated to use TR46
> transitional.
> There are still uses for IDNA2003 - e.g. as Nikos Mavrogiannopoulos found out,
> domain names in TLS certificates are still encoded by IDNA2003.

The thing is that RFC5280 references the IDNA2003 RFC, though this has
been obsoleted by IDNA2008 (RFC). Thus one can assume that the latter
is to be supported now (though details on whether TR#46 is to be used
are left as an exercise to the reader).

regards,
Nikos



reply via email to

[Prev in Thread] Current Thread [Next in Thread]