getaddrinfo() works for clients.
It does not work for servers, in particular it does not work for
peer-to-peer services that may be hidden behind layers of NAT44, NAT46
and NAT64. Port forwarding requests have to be a part of the model.
That in turn means that there has to be a security model.
And the well known port approach for discovery really does not work
for Web Services where we already have more services than ports.
The API has to hide all the complexity, not just some of it. And it
has to be compatible with coding in scripting languages like Perl or
Ruby, not just something that can be done from C++ with a Mb plus of
networking stack.
These are not difficult problems. In fact the remaining issues are
difficult because they are easy, not because they are hard. Anyone can
have an opinion on how to label SRV prefixes for services. And many
people do. Net result is that what should have been done ten years ago
is still incomplete.
Ever wondered why Henry Ford only made cars in black? He observed that
the more choices a customer was faced with, the longer it took them to
come to a buying decision. Even more so when multiple people were
making the decision. Decisions that had practical consequences were
easy to solve as either there was a need or was not. Decisions such as
color that had no practical consequence took forever.
One of the reasons X.500 directory deployment was a nightmare was that
the design of the directory tree and DIT had no technical consequence,
only political consequences.
On Tue, Jun 15, 2010 at 1:30 PM, Fred Baker <fred(_at_)cisco(_dot_)com> wrote:
On Jun 15, 2010, at 5:57 AM, Phillip Hallam-Baker wrote:
But in a Betamax/VHS type contest, attempting to differentiate the new
through obfuscation merely raises barriers to transition. In that
circumstance you want to minimize the differences between the two
technologies so that they can be used interchangeably.
So, things like implementing getaddrinfo() to replace gethostbyname() and as
a result making the applications network layer agnostic. The kind of thing
that not only helps with IPv6 deployment, but makes multi-homing work well
for the IPv4-only application as well, makes solutions like pnat irrelevant,
and all that.
http://www.ietf.org/rfc/rfc2553.txt
2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT=89215 bytes)
(Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152)
(Status: INFORMATIONAL)
http://www.ietf.org/rfc/rfc3493.txt
3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S.
Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format:
TXT=82570 bytes) (Obsoletes RFC2553) (Status: INFORMATIONAL)
Supported in Windows, Mac/BSD, Linux, you name it. Been there a long time.
Yes, all we need is application engineers with a network clue. They seem to
be hard to come by.
I have a solution. Let's go through those OS's and rename gethostbyname to
GetHostByName. Put in huge comments everywhere that the character string is
found (man pages, which btw already have this, and in the code itself) "if
you use this, you're an idiot". Make folks use their heads momentarily.
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf