On Montag, 2. Januar 2017 12:11:15 CET Simon Josefsson wrote: > Dennis Clarke <[email protected]> writes: > >> Duh, sorry. Yes indeed. Watch me get it right in the 0.14 release :-) > > > > Actually I have been watching the fray lately with interest and popcorn > > and waiting for the dust to settle. I have to compile your releases on > > some seriously strict POSIX systems and using the Oracle Studio 12.5 set > > of compilers. So once the dust settles then I grab the release and give > > it a build/test cycle and report back what I see. The Oracle compilers > > are really just the re-branded Sun ones and those will find errors and > > syntax issues in places where we didn't even know those places exist. So > > that can be very useful to fix up for portability sake. > > Try 0.14. It is now in Debian, which is a good test of some > cross-architecture portability. I'm sure there are other cross-platform > issues remaining, but testing and reports are needed at this point to > fix them. > > I would like to add better APIs to actually make the library more usable > for applications though. Maybe we can take a look at the curl patch for > libidn2 to see how the library would be used in reality. In summary:
I maintain libpsl, wget and wget2 which use libidn2. I will update these projects to use the new TR46 code. Debian's libpsl is currently built with libicu (libicu | libidn2 | libidn selectable at built time), I will change that to libidn2 in the next days. > * 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. > Eventually maybe we could get curl to link to libidn2 for IDNA2008+TR46. > If they want that. They have to figure out whether they want IDNA2003 > or IDNA2008. Or both. It could be a switch. 'curl --idna2003 > fußball.de' or 'curl --idna2008 fußball.de' or 'curl --idna2008tr46 > fußball.de' or 'curl --idna2008tr46traditional' fußball.de'. 'curl > fußball.de' could toss a coin to decide. AFAIK, curl uses libidn2 only since a few weeks. There was a discussion ongoing about IDN security. That was one of the reasons, I wrote the TR46 code. Daniel Stenberg (curl maintainer) even suggested to built curl without IDN to avoid security issues with non-tr46 IDNA. 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. Tim
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Help-libidn mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-libidn
