On Thu, Mar 08, 2007 at 10:41:02AM -0800,
Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf