[getdns-api] comments on v0.245

[Phil Pennock]

On 2013-01-21 at 18:04 -0800, Paul Hoffman wrote:
> It is identical to the "payload size" field in EDNS definition in RFC
> 2671. I'm not sure how to make it clearer.

I think most application users would not be familiar with the RFCs, so
clarification would just be a matter of clarifying that this is a
statement to the receiver of the maximum payload that can be supported,
unlike _most_ protocols, where it describes the size of what follows
within a frame.

> Where in typical OS configurations would one find a good value for payload size?
> 
> > Further, `getdns_context_create()` honours resolv.conf: what happens in
> > the presence of `options` directives in that for this API?  My BSD
> > system supports my having "options edns0" as a line in that file, and I
> > do so.  tcpdump shows that this gives UDPsize=65535 on the wire.
> 
> The API should honor all OS defaults first, certainly. It sounds like
> you want a context configuration that isn't there now, that allows the
> application to change the payload size. That's doable.

I don't know of a place on typical systems; the problem is you're
defaulting to 512 and on FreeBSD, "options edns0" in /etc/resolv.conf
causes clients to default to 2^16-1.

Short of a horrible "magic comments" hack approach to augment
resolv.conf, you're down to a new file in /etc, I think.

> Probably so. If others like that, I can certainly change them. That's
> the marvel of C macros. :-)

:)

> > Given the API design considerations of use by application developers,
> > shouldn't handling of IDN be done by default instead of an additional
> > manual step?
> 
> What do you mean "by default"? IDNA requires applications to handle
> the A-label to U-label transition either themselves or in an API. I
> don't want to force an application to do it the way the API demands: I
> want to offer both. If you can see a clean way to do that, I'm all
> ears.

If you keep the ulabel/alabel conversion routines and a way to skip IDN
work inside the API, then an application can do something special if it
wants to, or take a convenient extra that's "probably right" for most
applications.  It might be an extension item of "idn_auto_utf8" to let
the app take UTF-8 display form strings; I've not looked at the IDN
specs for a few years and I've forgotten the details of canonicalisation
/ nameprep and don't know if something would need to be in the extension
name for that?

> If SRV-using application developers want this (and there will
> certainly be some of them on the mailing list), I'm happy to add it.

Sounds good, and thanks for being willing to entertain the idea of
something crazy from me.

-Phil