Re: sockets APIs extensions for Host Identity Protocol

[Chris Newman <[e-mail]>]

Very simple APIs that solve the 90-95% case are extremely helpful.  Just 
because we also need APIs for the 5-10% case doesn't mean everyone should be 
forced to use the more complex APIs all the time.

One of the reasons HTTP is used (abused) so much is because the deployed APIs 
are very simple, indeed much simpler than sockets.  I've met programmers who 
will gladly toss stuff over HTTP but consider TCP far too complex to consider 
using.  This is very destructive to the actual complexity and security of the 
system.  But that simply doesn't matter to the vast majority of programmers 
when it saves days/weeks of programming time to use the higher level API.

It's also true that many of the deployed HTTP APIs limit control over HTTP 
headers and methods in such a way that it's impossible to use those APIs and 
follow all the advice in BCP 56.  We've seen similar problems with DNS RR 
labels and DNS APIs.

So API designs need to pay attention to both problems and good APIs often have 
both "simple" and "powerful" entry points.  For example, sockets has read/write 
and recvmsg/sendmsg.  As a programmer, I'd really hate to be forced to use the 
latter for all network I/O.

This is an area where good protocol design and good API design differs.  The 
primary goal of good protocol design is interoperability so infrequently used 
features are bad.  The primary goals of (IETF) API design are ease-of-use to 
aid deployment and transparency to avoid data losing -- those requirements 
often force a good design to have infrequently used features.

                - Chris

Keith Moore wrote on 5/8/07 23:22 -0400:

>
>> 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.  If
>> such an API isn't produced, I will be very reluctant to change that
>> code no matter how cool HIP might or might not be.
>
> If you can figure out how to write that kind of code in a way that works
> well for a wide variety of applications, with different requirements for
> bandwidth, stability, mobility, etc. all of which affect address
> selection, interface selection, etc., and do all of that efficiently and
> in the absence of routing information from the network, you should
> probably get a prize of some sort.
>
> Granted that programmers want a simple interface, but the more complex
> the network gets, the more apps will be expected to do jobs that were
> supposed to be done at layer 3.
>
> Keith
>
>