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 > I 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. >