Re: RFC: IDN support in getaddrinfo().

[Ulrich Drepper <drepper at redhat dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Josefsson wrote:

> Right.  Still, the specifications are not likely to change at this
> point, and if they do it wouldn't be over night, but rather take
> years.  The are published RFCs on Proposed Standard level, and is
> currently being revised for Draft Standard level (only editorial
> changes).

I'm not so worried about the specification, but the implementation.


> Having the libidn
> API available via libc have some benefits though, because there are
> many programs that will need stringprep functionality in the future
> (e.g., iSCSI, XMPP instant messaging, Kerberos, SASL).

This is something I absolutely don't want.  We've been burned badly by
the inability of RFC authors to come up with stable interfaces in the
past.  The libidn functionality would be hidden from the world and be
only available through getaddrinfo (and getnameinfo, I guess).

Yes, other program might need it, too.  But until the appropriate
interfaces are standardized by a respectable standards body they'll have
to live in a separate library.  If it turns out, later, that the
interface is stable we can make the interfaces in the separate library
simple forwarders to the glibc functions.


> I have been thinking about a dlopen() approach, to reduce the code
> size in libc.  E.g., the application requests IDN, then libc try to
> dlopen("idn").  The libc IDN code patch would only amount to, say,
> less than 100 lines.  Any thoughts on this?  Is it feasible at all?

It is feasible but probably not needed.

What I suggest to do is to move the data structures in a separate file.
 This file can then be mmaped in case getaddrinfo is called with the
appropriate option.  This adds some overhead to users/programs using
this functionality but that's life.  Adding 100k+ the glibc's size for
every user is not acceptable.

The code part seems reasonably small to not make big problems.  I would
insist on stripping down the code to the absolute minimum, though.


> but some utility functions to convert between UTF-8
> and UCS-4 are used internally, so make it ~10 API functions.  (Perhaps
> those functions already exist elsewhere in libc though?)

We obviously have code internally to map from and to UTF-8.  These would
have to be used.  They are a bit lower-level than iconv.


> Libidn currently support non-IDN related stringprep profiles as well,
> but they re-use the IDN-related stringprep tables.  They add only
> about ~20 lines of initialization in a static const table (100-200
> bytes?  Dunno.)

Should go.  Any bit of code which is removed cannot be misused.


If you send the code where the data is loaded from a file (just use read
for now) and the iconv uses are marked, I'll change those parts to use
the glibc-internal interfaces which are not so easy to find.

You have assigned the code to the FSF already, I assume?  Are there any
collaborators?  Is the license LGPL?

- -- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/xHo72ijCOnn/RHQRAmMEAKDCU7ee6HlRaZYPsUMMijD5H5gWmgCfXkTX
x54sDEp3ylxRKKRYeYWFE7U=
=NCpz
-----END PGP SIGNATURE-----