Vijay, I think the difference is that the Java run-time system includes the ability to "automagically" prefer v6 or v4. Specifically, the JDK provides java.net.preferIPv4Stack and java.net.preferIPv6Addresses. So if the programmer chooses to use FQDNs then the run-time will act according to those preferences. In C/C++ the programmer has to implement such preferences with extra logic. I agree that this is probably badly expressed in the current text.
We have quite a few other changes to make following IESG comments, so there will definitely be a new version. Regards Brian On 2009-11-24 12:21, Vijay K. Gurbani wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-carpenter-renum-needs-work-04 > Reviewer: Vijay K. Gurbani > Review Date: Nov. 23, 2009 > IETF LC End Date: Nov. 19, 2009 > IESG Telechat date: unknown > > Summary: This draft is ready for publication as a Informational; > I reviewed the -03 version and all my comments have been > addressed -- but ... > > I remain in a state of unease about the discussion Brian and I > had about networking APIs and how they pertain to Java vs. C/C++. > Let me first cut-and-paste the relevant section from -04 that > still makes me uneasy: > > 5.1.4. Application layer issues > ... > It should be noted that applications are in effect encouraged to be > aware of and to store IP addresses by the very nature of the socket > API calls gethostbyname() and getaddrinfo(). It is highly > unfortunate that many applications use APIs that require the > application to see and use lower layer objects, such as network-layer > addresses. However, the BSD Sockets API was designed and deployed > before the Domain Name System (DNS) was created, so there were few > good options at the time. This issue is made worse by the fact that > these functions do not return an address lifetime, so that > applications have no way to know when an address is no longer valid. > The extension of the same model to cover IPv6 has complicated this > problem somewhat. If a model was adopted in which only FQDNs were > exposed to applications, and addresses were cached with appropriate > lifetimes within the API, most of these problems would disappear. It > should be noted that at least the first part of this is already > available for some programming languages. A common example is Java, > where only FQDNs need to be handled by application code in normal > circumstances. This is highly beneficial for programmers who are not > networking experts, and insulates applications software from many > aspects of renumbering. It would be helfpul to have similarly > abstract, DNS oriented, Networking APIs widely available for C and > C++. > > There are two issues buried in the above paragraph: > > (1) Networking APIs do not return a ttl for an address. > (2) Networking APIs should only require the caller to supply a FQDN. > > The implication to the reader after going through the above > paragraph appears to be that neither Java nor C/C++ supports > (1), but Java supports (2) and C/C++ do not. > > I agree that neither Java nor C/C++ support (1), as best as I know. > However, I am somewhat uncomfortable at the claim that (2) is > supported better in Java than it is in C/C++. > > I will note that in C/C++, I can supply either a FQDN or a > dotted-decimal/colon-separated raw IP address as the first > parameter to to getaddrinfo() API: > > int getaddrinfo(const char *nodename, const char *servname, > const struct addrinfo *hints, struct addrinfo **res); > > In the same vein, the Java InetSocketAddress() constructor is > overloaded to allow for a raw IP address to be passed in as > well as a FQDN string: > > InetSocketAddress(InetAddress addr, int port) > Creates a socket address from an IP address and a port number. > InetSocketAddress(String hostname, int port) > Creates a socket address from a hostname and a port number. > > Thus, it appears that both C/C++ and Java support the same amount > of abstraction. The only difference is that in C/C++, the > socket is treated as a file descriptor following the Unix > convention of abstracting I/O behind a descriptor of some sort. > In Java, you get back an object -- but this is an artifact of the > specific programming language and the environment. > > If Brian agrees that C/C++ and Java are analogous in both (1) and > (2), then we can agree to word-smithing the paragraph above to > reflect this quickly. If not, then I am probably missing something > germane and I hope Brian fills me in so we can proceed on this > draft expeditiously. > > Sorry, I am not being difficult -- just trying to ensure that > my understanding lines up with Brian's. > > Thanks, > > - vijay _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
