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.sh...@gmail.com]
Sent: Tue 12/16/2008 11:59 AM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; Keith Moore; t...@ietf.org; ietf@ietf.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.

Melinda



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to