John,
The extensions in 2428 are in wide use, and they work just fine. I don't see any reason to change them.
Nor do I believe there is consensus that applications should always be passing names in preference to IP addresses. And until there is a system for assigning stable names to hosts that are independent of any administrative domain (since hosts often don't live in a single administrative domain), and quickly and reliably mapping from those names to IP addresses, the idea that applications should pass names in preference to IP address is something that I would classify "fantasy" at best. In particular, DNS is not sufficient to replace IP addresses in this role.
see also http://www.cs.utk.edu/~moore/opinions/ipv6/dns-as-endpoint-id. html
Keith, you are starting down the path I was hoping to avoid, so maybe my specific concern and suggestion wasn't clear. If is is working well as is, then I withdraw even the hint of deprecating the thing. My main objection to 2428 is not that it _permits_ addresses, but that it provides no option other than addresses and nothing on which to hang a DNS name or other identifier if one has one. That, it seems to me, is poor protocol design going forward, since it implies that the next new identifier requires yet another set of command keywords.
I suggest that it is useful, indeed important, to have a way to express and use DNS names --and, potentially, other identifiers-- as an alternative to addresses, if only because they isolate the near-user interface of the applications protocol from having to know which transport is to be used. Unlike a number of other situations in which I would agree with you, neither the "stable name" issue nor the independence of administrative domain one are significant here -- we routinely set up FTP command connections using DNS names, there are likely to be many circumstances in which it would be equally appropriate to set up the data connection that way, and FTP data connections don't persist (significantly) longer than the command connection.
We can debate --and work out-- the applicability statement that explains when one model or the other should be used. But the protocol should, at least, support the alterative of passing a name.
regards,
johnI just had occasion to look again at RFC 2428, "FTP Extensions for IPv6 and NATs", M. Allman, S. Ostermann, C. Metz. September 1998, and to think about in the context of the recent flame-war^H^H^H^H^H^H^H^H^H discussions about use of IP addresses in applications. 2428 provides additional syntax and mechanisms for FTP to deal with IPv6, with some useful properties for NATs (useful if you believe in NATs). It appears to provide only for addresses and does not appear to be extensible except to the addressing formats of new versions of IP.
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. In the unlikely event that there is insufficient interest or energy to do that work, should it be moved to historic or otherwise given a "not recommended" status as potentially harmful and inconsistent with the principle that applications (especially for IPv6) should be passing names and not IP addresses?
Please consider this a fairly narrow question. I don't want to start either the "applications level identifiers" debate or the NAT wars again and they aren't necessary to answering the question. On those topics, please, everyone, your points --pro, con, or otherwise-- have been made and anyone who is going to be convinced has been convinced. More traffic on those subjects in the guise of responding to this question will just convince more people that it is impossible to carry out a technical discussion on the IETF list.