[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: providing a libidn compatibility API
From: |
Tim Ruehsen |
Subject: |
Re: providing a libidn compatibility API |
Date: |
Thu, 26 Jan 2017 14:46:29 +0100 |
User-agent: |
KMail/5.2.3 (Linux/4.9.0-1-amd64; KDE/5.28.0; x86_64; ; ) |
On Thursday, January 26, 2017 2:07:39 PM CET Nikos Mavrogiannopoulos wrote:
> On Thu, Jan 26, 2017 at 1:26 PM, Tim Ruehsen <address@hidden> wrote:
> > On Thursday, January 26, 2017 12:58:05 PM CET Nikos Mavrogiannopoulos
wrote:
> >> Hi,
> >>
> >> What do you think of the following merge request:
> >> https://gitlab.com/jas/libidn2/merge_requests/4
> >>
> >> It introduces a (very-limited) compatibility API with libidn, allowing
> >> several applications to switch from IDNA2003 to IDNA2008 by changing
> >> idna.h with idn2.h.
> >
> > I just pushed my work on
> >
> > idn2_to_unicode_8z4z
> > idn2_to_unicode_4z4z
> > idn2_to_unicode_44i
> > idn2_to_unicode_8z8z
> > idn2_to_unicode_8zlz
> > idn2_to_unicode_lzlz
> >
> > to branch 'decode' (some commits are to follow)...
>
> Cool. Is the idn2_* intentional? I was thinking of providing
> compatibility in a way that sources do not need to be changed at all
> (i.e., provide an idna.h, and compatibility idna_* functions - which
> could also be wrappers). It would be very nice if we could compile
> programs that use libidn, using libidn2 without any changes (at least
> for the majority of them).
The naming is intentional because
1. What about apps providing idna2003 *and* idna2008 (libidn and libidn2) ?
2. idn2_ is the namespace for libidn2 (mainly because of 1)
We could use a define being set before #include <idn2.h>, e.g. IDN2_LIBIDN_API.
WDYT ?
> > If you agree I would (manually) merge your changes into that branch first.
>
> I certainly do. Note that there few failures in the libidn testsuite,
> which I have put them in ifdef XXX. These are in tst_idna2.c, and
> tst_idna4.c. The tst_idna4.c failure has to do with ascii_to_8z in
> libidn2 allowing multiple dots, while the tst_idn2.c failures are
> beyond my knowledge.
I'll go through all of these.
> > the idna_to_unicode_8z8z() could directly map to idn2_to_unicode_8z8z() -
> > the arguments are the same.
>
> Note that there few small changes from the version you submitted in
> gnutls (one which detects non-ascii chars, and another which allows
> XN-- as prefix).
- Non-ascii detection as a shortcut ? That sounds reasonable.
- Allowing XN-- is fine (because of RFC 5890 2.3.1 saying xn-- is case
independent).
Regards, Tim
signature.asc
Description: This is a digitally signed message part.
- providing a libidn compatibility API, Nikos Mavrogiannopoulos, 2017/01/26
- Re: providing a libidn compatibility API, Tim Ruehsen, 2017/01/26
- Re: providing a libidn compatibility API, Nikos Mavrogiannopoulos, 2017/01/26
- Re: providing a libidn compatibility API, Tim Ruehsen, 2017/01/27
- Re: providing a libidn compatibility API, Nikos Mavrogiannopoulos, 2017/01/28
- Re: providing a libidn compatibility API, Tim Rühsen, 2017/01/28
- Re: providing a libidn compatibility API, Nikos Mavrogiannopoulos, 2017/01/29
- Re: providing a libidn compatibility API, Tim Ruehsen, 2017/01/27
- Re: providing a libidn compatibility API, Tim Ruehsen, 2017/01/27