Keith Moore <[EMAIL PROTECTED]> writes: > > Otherwise people might start thinking that > > getaddrinfo() would/should be the point of augmentation when they want > > to implement SRV, MX and other name-to-address lookup API, leading to a > > whole mess > > People already *are* thinking that, and have been for many years. IMHO > one of the biggest botches of getaddrinfo() is the srvname parameter, > partially because it tempts people to have getaddrinfo() do SRV lookups (and > there's nothing in the specification that says not to do that)
As far as I can see, the only good reason to have the service argument in getaddrinfo is to make it possible for getaddrinfo to perform SRV lookups. It can ask for SRV-records, and sort the returned addresses according to some combination of SRV priority, weight and other destination address selection rules. If no SRV was found, it can ask for A and/or AAAA records, and use getservbyname to find the port number. Sounds like an easy and reasonable way to deploy SRV. Compare to the non-SRV usage scenario: I use getaddrinfo, to make my code nice and protocol independent, and I want to use some fix port number. Then I'll want getaddrinfo to write the number into the returned sockaddr structures, in the nice protocol neutral way of getaddrinfo. But to do that, I have to convert my fix number into a *string*, and let getaddrinfo convert it back to a number. To me, that mode of operation makes a lot less sense than having getaddrinfo perform SRV lookups... Regards, /Niels -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
