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
ServiceName: String
And NOT
ServiceName:
Choice
DNSName: String
IPv4Address: Array of Octet [4]
IPv6Address: Array of Octet [16]
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.shore@xxxxxxxxx]
Sent: Tue 12/16/2008 11:59 AM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; Keith Moore; tae@xxxxxxxx; ietf@xxxxxxxx
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.
Melinda
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf