RE: sockets APIs extensions for Host Identity Protocol

["Henderson, Thomas R" <[e-mail]>]

 

> -----Original Message-----
> From: Chris Newman [mailto:[e-mail]] 
> Sent: Monday, May 07, 2007 2:32 PM
> To: Miika Komu; [e-mail]
> Cc: Henderson, Thomas R
> Subject: Re: sockets APIs extensions for Host Identity Protocol
> 
> Speaking as a technical participant, not as an area director...
> 
> Application software wants to work with strings.  When I want 
> to make a network 
> connection, I have a string which says what I want to connect 
> to.  It might be 
> a DNS name, an IPv4 address literal, and IPv6 address 
> literal, the field after 
> the "//" in a URL or whatever the string format for a HIP 
> endpoint is going to 
> be.  As an application developer I don't want to care what 
> that string means. 
> I might want a way to turn that string into an opaque object 
> (or objects) and 
> back (with a timeout) and then use that opaque object in 
> something equivalent 
> to connect and/or bind.
> 
> I also want a way to enumerate the string representations of 
> the local 
> interfaces on a server so that I can offer the administrator 
> a choice of which 
> interface(s) the listen ports bind to.  I don't want to care 
> whether those are 
> IPv4, IPv6 or HIP or something else.
> 
> The only reason I might care what the string or opaque object 
> refers to is for 
> debugging/logging/diagnostic purposes.
> 
> 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.

Chris, 
Is the IETF in the business of defining this new API?  Or is the IETF
scope limited to sockets, and the APIs that you seek are defined by
library and OS developers?

As a HIP WG participant, I see that there has been a history of RFCs for
sockets API extensions (2292, 2960, 4584, etc.).  We could do a similar
one for HIP, but Miika has proposed that we go for a more future-proof
API and build in some abstraction.  It seems to me that there is support
for defining such an API and it has already been done successfully for
Java.

(note also that there has been discussion on the RAM list this week on
this topic).

Tom