Re: sockets APIs extensions for Host Identity Protocol

[der Mouse <[e-mail]>]

> Application software wants to work with strings.  [...]

> If I change my "connectbyname" code again, I will change it once more
> to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever
> junk, preferably to something much simpler than the code today.

Something wrong with getaddrinfo()?  It certainly could use something
HIPish under the hood, if some implementor decided to.

>> A potential benefit of the handles is that it would make the API
>> future-proof againts changes to the HIT size.

getaddrinfo() already is...or at least, it is when used correctly, and
in this respect it's easier to use it correctly than incorrecetly
(which is about all you can expect).  It's a slightly broken API, true,
but the problems with it are not in areas that any putative HIP/HIT
stuff would fix.

>> Similarly, one might argue that the IPv6 transition would have been
>> a lot easier for applications if the concept of endpoint descriptor
>> were already available for the past twenty years;

That concept *has* been available for the past twenty years; it's
called a "socket".  What hasn't been available is a socket
implementation that doesn't expose the underlying addressing details to
the application.  This could be - and arguably should be - fixed
entirely under the socket-layer hood, not by inventing new protocols
and exposing *them* to the application.  I speculate that the major
reason this hasn't been done is tradition - sockets have traditionally
been a fairly direct interface into the kernel, and preserving that
while presenting this kind of socket interface is relatively hard.

/~\ 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