On Thu, Mar 08, 2007 at 10:41:02AM -0800, Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> wrote a message of 115 lines which said: > OK lets try code, at the moment to start up a TCP socket you have > code of the form: In C. In every other language I know, it is at a much higher level. (Even in C, programmers often use something like libcurl or neon, which frees them of these awful details. My personal rant, in french only, is at http://www.bortzmeyer.org/network-high-level-programming.html.) > The application should not be dealling with any of this. The IP > address should never be exposed to the application in any form. Same > goes for the protocol. Do you really mean "the application" (and, in that case, we are already there) or "the userland" (and this is a more complicated problem). And do you mean "the application should not HAVE TO know these details" (and we agree and it is already possible) or "the application MUST NOT be able to know these details, they should be kept in the kernel" (which would be a much stronger statement). > I don't think that the application should know anything about the > details of the IP level, not the port and certainly not the address. If I understand the idea you have been developed in this thread, it seems close from a Locator / Identifier split with DNS names as the Identifier. Am I wrong? Do note that the "original" paper about endpoints (Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture) mentioned that: 10.4 Domain Name System (DNS) Names An obvious, ready-made, namespace for endpoint are DNS names. These have the advantage of being an existing system, with an allocation system all worked out. Among other advantages of DNS names, since they are variable length, and composed of a variable number of levels, there is no danger of running out of them, and new ones can be allocated locally by appending some locally unique identifier to the DNS name of the entity creating the new endpoint name. They would probably not be suitable for inclusion in each packet, of course, at least not directly; this would limit their ability to be used as demultiplexors. However, an additional ESEL field in the packets would provide this capability; the full DNS-type endpoint name would still be used both at the time the connection is set up, and in the end-end checksum pseudo-header. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf