[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libidn2 tr#46 support
From: |
Tim Ruehsen |
Subject: |
Re: libidn2 tr#46 support |
Date: |
Tue, 13 Dec 2016 13:50:51 +0100 |
User-agent: |
KMail/5.2.3 (Linux/4.8.0-2-amd64; KDE/5.28.0; x86_64; ; ) |
On Tuesday, December 13, 2016 9:25:03 AM CET Nikos Mavrogiannopoulos wrote:
> On Tue, Nov 8, 2016 at 10:16 AM, Evgeny Grin <address@hidden> wrote:
> > 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.
>
> What is it missing to have a backwards compatible libidn which
> supports IDNA2008? As far as I understand idna_to_ascii_8z() can be
> mapped to libunistring + idn2_lookup_u8 from libidn2. The
> idna_to_ascii_4z/lz are also about combining libunistring with the
> previous function.
I didn't closely look into libidn code, but already had a similar thought.
IDNA2003 and IDNA2008 very likely share lot's of code. Once Simon accepts my
code/branches pushed to his repo on Gitlab I would jump in to investigate this
and likely merge libidn2 into libidn. (If there is any other volunteer, please
say so.)
> The idna_to_unicode_* do they require any mapping
> at all? As far as I understand rfc3492 should apply on IDNA2008
> encodings as well, and the reverse process should be identical, right?
punycode_decode() does not need any mapping, but the IDNA2003 'stringprep'
does a mapping of the input string. Maybe similar to what TR46/UTS#46
transitional does.
Basically IDNA 2008 should replace IDNA 2003 A.S.A.P., due to some
compatibility issues. UTS#46 transitional should fix these and at some point in
time everybody should switch to UTS#46 non-transitional ;-)
Regards, Tim
signature.asc
Description: This is a digitally signed message part.