> My goal is precisely to avoid ending up with either two > standards or eight verbs. Explanation of the latter: > > IPv4 IPv6 & self-referent DNS StableID > address address > > RFC 959 2428 ??? ??? > Verb PORT,PASV EPRT,EPSV ?DPRT,DPSV? ?IPRT,IPSV? > > That seems to me excessive, if we can avoid it. If a case could actually be made for using DNS names in FTP (and IMHO the case against is far heavier than the case in favor) it would be a simple matter to define new "address types" for EPSV and EPRT. I don't see why new commands would be necessary. > In the, admittedly rare, situations in which the transfer is > really third-party, and not even bound tightly to one of the > other two, passing the domain name of the third host (one that > is not at either end of the command connection) would seem more > consistent with general architectural principles. Which principles are those? That it's better to use an ambiguous reference to a host than a unambiguous one? That it's better to add extra complexity and failure modes to a system than to use a simple and reliable mechanism? That it's better to encourage fragmenting the DNS to reflect disjoint addressing realms than it is to encourage a sane address space? > That seems to > me to be especially true because, for those cases, the command > connection host(s) are likely to get the pointer to that host in > DNS name or URI form, not as an address. In a world of NATs and > split-horizon DNS setups (not that I like either), it seems far > preferable to have the DNS name resolved from the host that is > going to use the results to open a connection. It might seem that way, but experience indicates that DNS names are _less_ reliable than IP addresses in referrals. Because even with all of the harm done by RFC 1918 addersses, DNS is far more screwed up in practice than IP. Partly this is because DNS depends on even things to be accessible, configured, and working properly in order to function than IP does; and part of this is because there are more games played with DNS than with IP. And while use of RFC 1918 addresses at least provides a clue that the address is not usable outside of the local realm, there's no way to know whether a DNS name is globally usable or not. And given the potential for a DNS name to produce different RRs at different locations of the net (yes there are people doing this), it's not clear at all that having the DNS name resolved from the host that is going to use the address is the "right" meaning. I would argue that the lookup that is the closest to where the DNS name is _specified_ is more likely to be the right one. (Though I'd argue even more strongly that producing different RRs at different locations is simply broken.) At any rate, until someone defines a good way to make 3rd party FTP transfers secure, any arguments about why DNS names are needed for 3rd party transfers seem moot. Keith