help-libidn
[Top][All Lists]
Advanced

[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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]