So to be strictly accurate here, applications deal in names, some of which are
DNS names and some of which are IP address litterals. But an 'end user'
application only deals in names.
Now an administration tool or a security tool might well deal in 'addresses'
directly, just as such tools might deal in raw message identifiers, cert paths
and other arcanae that the user should never need to interpret.
Actually from an API point of view I would like to see those properly rendered
safe as well.
The practical upshot of this is that if you have an XML protocol you should
have an element of the form
IPv4Address: Array of Octet 
IPv6Address: Array of Octet 
Another area where there is likely to be a concrete output here is in
determining what the difference is between a URL and a URN and between a
service name and a URL.
I would like to get that pinned down because we currently have a big confusion
errupting in Web Services land as a result of people being confused on these
points. A Web Service Endpoint may not be the most appropriate form to use as a
Web Service descriptor.
From: Melinda Shore [mailto:melinda(_dot_)shore(_at_)gmail(_dot_)com]
Sent: Tue 12/16/2008 11:59 AM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; Keith Moore; tae(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [tae] The Great Naming Debate (was Re: The internet architecture)
Hallam-Baker, Phillip wrote:
10.1.2.3 is simply a string litteral that may be used in place of a
DNS name. In neither case should the application require knowledge of
the IP address itself. In fact you don't want that as at some point in
the distant future, 10.1.2.3 is actually going to map to an IPv6
address, not an IPv4 address.
While I take your point in general, I do think it should
be pointed out that DNS names are resolved prior to
connection establishment through a directory lookup,
while addresses are routed.
Ietf mailing list