Re: libidn2 tr#46 support

[Tim Ruehsen]

On Tuesday, November 8, 2016 10:29:07 AM 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.

(Just since yesterday) Wget uses the gnulib ./bootstrap script (basically 
gnulib-tool) with the following modules:
libunistring-optional
unistr/base
unicase/tolower

As I understood, this links with libunistring if possible and else falls back 
to gnulib code. But it should also be pretty easy to do this check within 
configure.ac in case you like that better.

> 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 go with Simon in this point(s).

Tim

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