> 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 disagree. A host, at least one on the public Internet (where IP addresses are globally unique as IP was designed to work) has reliable knowledge of its current IP addresses. It does not have reliable knowledge of which DNS names are currently bound to its IP addresses, nor of the intended purposes of those DNS names (are the names intended to be associated with a particular host or with a particular service that is supplied by many hosts?). So expecting, or even allowing, an FTP client or server to say "contact me at this DNS name" seems to me to be providing additional ways for the FTP session to fail, while adding little (if any) value. e.g. - the party providing the DNS name may be doing so erroneously, - the DNS servers providing name-to-address translation might not be in service and reachable, - DNS lookup might not be available to one party or another (e.g. one party is on a ad hoc network and wants to use LLMNR, while the other party is on a connected network and expects DNS to work) - if there is an intermediary involved, use of the DNS name may confuse the intermediary or one or the endpoints. for instance, it is often possible to use FTP between hosts in different addressing realms via use of an intermediary, while DNS names would fail in those situations. I'll also note that RFC 2428 already provides a way (EPSV) to establish FTP transfers in the usual case where the file is being transferred between client and server and no third party is involved, which doesn't need *any* kind of name - neither IP address nor DNS name - as the endpoint addresses are implicit. This should be used in the vast majority of cases. More fundamentally, of course, I have issues with the citing of "applications should use names rather than addresses" as a principle to which there is widespread agreement, and which should drive protocol designs, or even as something which has been demonstrated to be workable. We don't need to revisit that discussion again right now, or in this context, but neither should it be taken as a given. (Nor does this really have anything to do with NAT - the two are only tangentially related.) If we're only looking at the narrow question of FTP, I submit that EPSV is good enough for the vast majority of cases, EPRT with either v4 or v6 addresses is good enough for 3-party transfers (assuming that you can manage the security issues), and any marginal value that would be provided by adding DNS capability is fairly dubious at best and potentially harmful.