Re: sockets APIs extensions for Host Identity Protocol

[der Mouse <[e-mail]>]

>> What do you see as wrong with [getaddrinfo()]?
> the nice thing about it is that it does two things for you.  one is
> that it completely initializes sockaddr structures for you.   the
> other is that (at least in recent versions?) it can take either a DNS
> name or an address literal and do the right thing with it.

The major thing *I* use it for is to insulate the application from
knowledge of what address families are available.  If correctly written
(getaddrinfo() can be used wrong, as most things can), an application
can be totally new-AF-ready.  If I write an SMTP client with
getaddrinfo() and then, a year later, someone defines SMTP-over-DECnet
(or SMTP-over-IPv7, or whatever), my code will start trying DECnet
without any changes whatsoever to the application.  (If, of course,
it's running on a DECnet-aware - or IPv7-aware - system.)

> - it's actually more difficult to set the parameters for
>    getaddrinfo() to get it to do what you want, than it is to
>    initialize the fields in a sockaddr_in*

Yes, if all you want is AF_INET - or AF_INET6 - it is.  But this is
*not* true if "what you want" is for the app code to be AF-agnostic, as
I sketched above.  I'm not even sure it's true if you want AF_INET
*and* AF_INET6; I find it about evenly balanced whether getaddrinfo()
or doing both INET* AFs is messier, more difficult, whatever.

> - getaddrinfo encourages use of string constants to specify ports,
>    rather than numeric constants, which is wrong -

No, this is very right.  The notion that "ports" are small integers is
a *horribly* IP-centric notion.  DECnet, for example, uses short
strings (8-char? 12-char? I don't know the limit) which do *not* have
to map into numbers - I think X over DECnet, for example, uses "port"
strings like "X$0" and "X$1".

>    it adds an extra layer of indirection that can (and does) fail,
>    and it tempts people to try to use that layer of indirection to do
>    things that violate protocol specifications (like do a SRV lookup
>    for protocols that aren't specified to use SRV)

We must be talking about different getaddrinfo()s.  The one I'm used to
doesn't do anything with SRV records, ever, as far as I can see (I
checked both the manpage and the code).

> - it has no way to be used asynchronously other than to put each call
>    to getaddrinfo in a separate thread,

Neither does gethostbyname().  And, without a lot of callback or AIO
scaffolding - or threading - it *can't*.

> - it's not specified to use DNS.

It's not really specified clearly at all, it appears.  Again, a valid
criticism, but a fixable one.

But it can't really be specified to use DNS, since it is not restricted
to address families that the DNS supports, and it also has to work on
systems not connected to the Internet (/etc/hosts and its ilk).  If I
had to set up a private DNS root just to use host names on an isolated
subnet, I'd call that cripplingly broken.

>    so if a protocol is specified to use DNS in some particular way,
>    and the implementation of the protocol uses getaddrinfo(), the
>    implementation may fail to strictly follow the protocol spec.

This is not a problem with getaddrinfo(); this is a problem with
implementors using inappropriate calls.  getaddrinfo() is not
appropriate for implementing protocols defined must-use-DNS, because of
the above issues.  (I'd actually argue that such specs are broken,
because they mean the protocol is unreasonably difficult to use
according to spec except on the public Internet.)

> - the handling of v4 vs v6 vs mapped v4 addresses is confusing.

No more than v4 vs v6 vs mapped v4 are to begin with.

The rest of your points - including the pieces I cut from the oens I
did address specifically - seem to fall into two categories: "no clear
agreed-upon spec" and "buggy implementations are common".  While these
are fair answers to my question, neither one seems to me like a reason
to ditch the interface entirely when considering standardizing
something for (say) HIP/HIT use.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B