Re: libidn2 tr#46 support

[Tim Rühsen]

On Dienstag, 8. November 2016 10:29:07 CET Simon Josefsson wrote:
> Den Tue, 8 Nov 2016 12:16:28 +0300
> 
> skrev Re: libidn2 tr#46 support:
> > On 08.11.2016 11:18, Simon Josefsson wrote:
> > > Tim Ruehsen <address@hidden> writes:
> > >> Simon, well known problem everywhere :-( Too less time and more
> > >> and more projects needs attention... huge lack of developers as it
> > >> seems.
> > > 
> > > Right.  I am really looking for help with libidn and libidn2, so if
> > > anyone reading this would like to step up: the sky is the limit :-)
> > 
> > May be I can help.
> > My idea was to create libidn3 which should be mostly
> > backward-compatible with libidn (as most widespread version) and have
> > minimal (or zero) external dependencies.
> > And it must be portable to GNU/Linux, Free/Net/OpenBSD, Darwin,
> > Solaris and W32.
> 
> Thanks for the offer to help!
> 
> Any reason you don't want to put this into libidn2?  As far as I
> understand, the remaining tasks for libidn2 are:
> 
> * Unicode TR46 implementation
> * APIs for some Unicode primitives like NFC to help apps
> * APIs to decode ACE strings
> 
> My goal is minimal external dependencies, right now it uses gnulib to
> be able to be standalone, but optional linking to libunistring is
> probably a good idea.  Packagers like Debian don't like embedded code
> copies.  Libidn2 is already portable to many platforms.
> 
> Regarding backwards compatibility, what is the key here is TR46.  More
> compatibility than that is probably not possible.  We could provide
> plug'n'play APIs to convert existing libidn users to libidn2, however
> since the algorithms are so different it really is impossible to make
> it a complete drop-in replacement.

I started some work at https://github.com/rockdaboot/tr46.
It already implements the TR46 UTS#46 transitional and non-transitional 
processing using libunistring (Unicode 8.0.0 AFAICS). For to/from punycode 
conversion the code uses libidn2 (Unicode 5.2.0). 

The project uses the latest Unicode 9.0.0 tables and tests. Many tests fail 
due to libidn2 still using old Unicode 5.2.0 tables (error: string contains 
unassigned code point).

Libidn2 'make test' fails when updating to Unicode 6.3.0... Simon, maybe you 
can update it (e.g. using a separate branch). Unicode 8 or 9 would be nice for 
me to test further.
The alternative is that I implement IDNA 2008 on my own... (not preferred).

Once all works out, we can hopefully move the code into libidn2.

Regards, Tim

signature.asc
Description: This is a digitally signed message part.