[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libidn2 tr#46 support
From: |
Tim Rühsen |
Subject: |
Re: libidn2 tr#46 support |
Date: |
Sat, 19 Nov 2016 23:17:54 +0100 |
User-agent: |
KMail/5.2.3 (Linux/4.8.0-1-amd64; KDE/5.27.0; x86_64; ; ) |
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.