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@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf