RE: shim - transport/app communication

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

You have valid concern for implementation.  I won't comment further till
I see a formal new shim mail list BOF not the current ones.  It also can
have ramifications that are significant to network subsystem
implementation protocol maps, structures, and address families but lets
see next draft to this list.  None of this should be exposed on the wire
to the network and how it is transfered and discovered is very
important.

/jim 

> -----Original Message-----
> From: Pasi Sarolahti [mailto:pasi.sarolahti@nokia.com] 
> Sent: Wednesday, March 16, 2005 6:44 AM
> To: ext Jeroen Massar
> Cc: Kurtis Lindqvist; shim6@psg.com; Leif Johansson; Iljitsch 
> van Beijnum; Bound, Jim
> Subject: RE: shim - transport/app communication
> 
> On Wed, 2005-03-16 at 12:31, ext Jeroen Massar wrote:
> 
> > Actually, the only thing an application should depend on 
> here is that it
> > supports IPv6 addresses, though I have to note that shim6 should be
> > named 'shim', as this trick can also work for IPv4 and then 
> they would
> > not even need IPv6 for that matter.
> 
> Agree.
> 
> >  But the minimal requirement we could
> > set is "use a getaddrinfo() loop to cycle through all the 
> addresses",
> > the ULID magic can be put in the getaddrinfo() function 
> which returns
> > ULID's instead of the routing IP's.
> 
> I was not so concerned about the techniques of conversions between
> strings and address structures, but the semantic issues that 
> might arise
> when the address the application sees might not anymore be the same as
> the address actually used in communication. I was wondering what would
> happen, for example, when these addresses are being advertised out in
> the network as a part of some application protocol.
> 
> Another example, I guess that bind() with IP address should 
> still select
> the interface used for the socket, right? In principle, if assuming
> ULIDs, the parameter address would represent the host, not the
> interface. So some of the socket API functions would seem a bit
> ambiguous to me.
> 
> Maybe I'm misunderstanding something, and these are not really valid
> concerns. I hope I am :-)
> 
> - Pasi
> 
>