[getdns-api] Remove IDNA functions from getdns?

[Paul Hoffman]

On 3 Sep 2015, at 8:22, Willem Toorop wrote:

> Op 03-09-15 om 16:32 schreef Andrew Sullivan:
>> On Thu, Sep 03, 2015 at 03:21:43PM +0200, Willem Toorop wrote:
>>>
>>> Currently the API defines two functions for IDNA 2008:
>>> getdns_convert_ulabel_to_alabel() and 
>>> getdns_convert_alabel_to_ulabel()
>>>
>>> In our implementation, those are (more or less) direct mappings to 
>>> the
>>> underlying idna_to_ascii_8z() and idna_to_unicode_8z8z() functions 
>>> from
>>> the GNU IDN library.  Applications that need to do IDNA conversions,
>>> might just as well use those functions from libidn directly instead 
>>> of
>>> using the getdns facades.  Because of those two functions our 
>>> library
>>> has a dependency on libidn, but does not add any extra value on top 
>>> of
>>> that library.
>>
>> The purpose of getdns, though, was to give applications a one-stop
>> shop to do all these DNSy things, and IDNA is part of that.  After
>> all, in some sense every other thing in getdns can be achieved by
>> lower-level functions as well.
>
> I don't know, getdns has some pretty unique features :)  But even if 
> all
> could be offered by other lower-level libraries, those other
> functionalities are all closely integrated in a coherent body.  Not 
> with
> IDNA support, which is just offered through those two - completely 
> loose
> from everything else - functions.
>
> Perhaps it would be better to offer IDNA in a more getdns way?  For
> example through an extension, which will process query names ulabel to
> alabel and return processed dname's converted from alabels to ulabels 
> in
> the response dict?

I'm with Andrew on this one. getdns is supposed to be a modern DNS API 
for applications, and IDNA is certainly part of the modern DNS.

The current functions are certainly more understandable to a typical 
programmer than an extension. The dependency on libidn would still be 
there, of course.

--Paul Hoffman