RE: shim - transport/app communication

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

> > In addition 3493 permits a
> > means to program with IPv4 and IPv6 in address family 
> indepdent manner.
> 
> You said it: IPv4 and IPv6. What about IPs v7 - 15 ?

If that should happen the new Address Family independent semantics of
3493 will support new families as it will new data structures if we do
require ULIDs for the shim6 work to relay something relative to this
list on this topic.

Note this was one reason 3493 was supported as IEEE POSIX API extension
because of getaddrinfo and getnameinfo updates to do exactly what you
believe important. The actual standard is from the IEEE via the Open
Group the IETF work is simply informational.

> 
> Also, I assume you're talking about IPv4-mapped addresses. I think 
> those are great but unfortunately there are others who disagree and 
> failed to implement them, which makes writing IP version agnostic 
> impossible on some systems and therefore non-portable on all systems.
> 
> But I suggest we agree to disagree, at least on this list.  :-)

That is fine but updates have been done and all implementations do now
support IPv4mapped addresses and that subject has reached consensus on
the IPv6 WG list.  We should not go there here at all.  

Not sure where we don't agree 3493 can be used to support the absolute
value of being agnostic with regards to Address Family, Address Form,
and should we use ULID version 1 and have to update it layer it will
support a different ULID version 2 later. Implementations would do this
by adding libraries for such functions and the kernel support to support
those functions.  If we were to implement Erik Normark's draft this is
how it could be done and be transparent to applications again to make
this mail relative to this IETF list.

/jim
> 
>