RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

Your completely missing the point of 3493 and some of the most brilliant
and serious network programmers in the IETF worked on this API for
years.  Your statements or assumptions are invalid completely.  3493 is
an update to BSD style sockets API with the enhancements of a more
friendly API interface getaddrinfo and getnameinfo.  In fact extensions
for those APIs for multihoming are very possible and there is no need to
invent another API but just extensions.  In addition 3493 permits a
means to program with IPv4 and IPv6 in address family indepdent manner.

> or so we'll find ourselves in the same situation. (And I'm 
> not a career 
> programmer, so maybe this isn't so much an issue for those 
> who are, but 
> I find the current API almost unusably complex and arcane.)

By your own admission above your statemeents on this topic, state your
not qualified to make a Subject Matter Expert (SME) opinion, so I
suggest you do not.  All of us that worked extensively on 3493 and those
acknowledged and from the IPv6 were SMEs on this topic.  

/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
> Sent: Sunday, March 27, 2005 7:55 AM
> To: Bound, Jim
> Cc: shim6
> Subject: Re: shim - transport/app communication
> 
> On 26-mrt-05, at 16:50, Bound, Jim wrote:
> 
> > Your chances of another API other than 3493 and getting multihomed
> > solution deployed in the real world of implementors and products is 
> > very
> > slim.  I also do not believe this is necessary.  The ULID concept
> > requires much more details and grilling technically.
> 
> I agree. If we had a clean API, the multihoming issue would have been 
> much easier to solve. But we don't, so we have to do it the hard way. 
> We still need to work on an architecturally clean API at some point, 
> both because it's the right thing to do and because 20 years from now 
> or so we'll find ourselves in the same situation. (And I'm 
> not a career 
> programmer, so maybe this isn't so much an issue for those 
> who are, but 
> I find the current API almost unusably complex and arcane.)
> 
>