RE: Persistent applications-level identifiers, the DNS, and RFC 2428

--On Wednesday, 01 October, 2003 14:48 -0700 Michel Py 
<michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:
> John,
>
> > John C Klensin wrote:
> > It seems appropriate to ask whether 2428 should be opened
> > and given at least the capability of passing DNS names
> > and maybe some syntax that would permit clean extension
> > to future identifiers.
> It seems to me that this does not buy us much if it is limited
> to FTP. Do you have in mind generalizing the mechanism of
> passing names instead of addresses to other apps, and at which
> layer would the address-to-name mapping occur?
My ambitious in raising these questions are _very_ limited and, 
in particular, I don't see this as a back door to solving the 
non-DNS, topology-independent, persistent identifier problem. 
(It seems to me that needs to be solved through the front door, 
or not at all.).
Remember that FTP is a bit special -- it is the only major 
(widely deployed and used) application protocol we have that 
uses two TCP connections, one for a dialogue about what is to be 
done and one to actually move data.  That means it must have 
mechanisms for one or the other machine to tell the other one 
"set up a data channel to port X on machine Y"
We've also had a few IESG statements from time to time that have 
provide guidance/instructions to applications writers to get the 
explicit addresses out of the apps whenever possible.  As Keith 
notes, there is controversy as to whether that goal is 
realistic, at least given present our tools and identifier 
collection.
But, given those IESG statements, the character of  "set up a 
data channel to port X on machine Y", and some of the edge cases 
for which it has been used, it would seem at least superficially 
sensible to be able to specify Y as a DNS name or other 
identifier or, as was pointed out to me in a private note, to be 
able to specify the X and Y combination with a URI of some sort. 
I've got no particular interest in prohibiting the use of an IP 
address in Y (others can fight that war, I hope somewhere far 
away, if they want to), only some interest in exploring whether 
it is rational to have capability for a name as an additional 
option.  I do, architecturally and aesthetically, have an 
interest in not having to introduce a new pair of FTP command 
verbs each time someone figures out a different way to talk 
about (or identify) a host.  And that interest is why I got 
concerned when I noticed that 2428 had no provision for a name, 
or expansion of the syntax to accept a name, DNS or otherwise.
> If I understood you correctly:
>
> The way it works today is:
> - You pass a name to the app.
> - The app looks up the name and maps an address to it.
> - The app opens a TCP connection to the address.
yes.

> Is what you are proposing:
> - You pass a name to the app.
> - The app opens a TCP connection to the name.
> - The TCP layer manages the mapping.
>
> -or-
>
> - You pass a name to the app.
> - The app opens a connects the session layer by name.
> - The session layer maps an address to the name and opens a TCP
> connection to the address.
Both of those alternatives go down the "Stable, non-DNS, 
identifier" that Keith and others are concerned about.   For the 
purpose of this discussion/ question, I'm not -- I am purely 
worried about how to handle this unusual situation with FTP. 
Coming back to your first scenario, we have
- You pass a name to the app.
- The app looks up the name and maps an address to it.
- The app opens a TCP connection to the address, establishing 
the command channel
- Either the app or the host at the remote end of the connection 
obtains a name or address, somehow.  In the most common case, it 
will be its own target, so it makes sense for it to obtain its 
own address (or the address of the adapter from which the TCP 
connection was opened), but there are some other cases.
- It passes that address or name to the remote host, along with 
a port number.
- If it passes a name, the remote host looks up the name, maps 
an address to it, and opens a TCP connection to it, establishing 
the data channel.
  john