On 7/13/24 04:16, Simon Josefsson wrote:
IMO, it depends on which use cases you're trying to support.. I might argue that the ability to do remote "backups" (faithfully transfer files over the network regardless of file format) is more important now than it ever was. And the 3rd party mediated transfer is still quite useful if you can make it secure. Now a "file transfer protocol" can be useful without those features, but FTP has often also been used as a "file access protocol", though IMO a poor one because it doesn't support all of the features needed for this.Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> writes:On 7/12/24 04:29, Simon Josefsson wrote:What does FTP offer that SSH-based Secure FTP doesn't?In brief (and from memory): - the ability to faithfully transfer files of almost any format (not just byte streams) between machines with similar file systems - some ability to convert between different character encodings while transferring - some ability to transfer files between different formats (source file format is different than destination file format) - the ability of a 3rd machine to mediate a transfer directly between two other machines (widely used in broadcast TV where the files being transferred are huge, and the machines are usually on the same LAN)Those were marvellous inventions at the time, but I doubt these are appropriate design decisions for a file transfer protocol today.
I think we've learned that data formats and conversions is a sufficiently hard problem that it is better to separate that from the file transfer protocol itself.
I don't see how you've established that. What we've learned (IMO) is to gravitate toward data formats that are portable, and toward operating systems that natively support those data formats.
It seems to me that the changes required to make sftp more suitable for this use case, are actually easier than the changes required to make a typical HTTP server suitable for this use case.- "anonymous FTP" if so enabled by the server (in theory could be done with SSH, but FTP servers generally do support this, and I'm not aware that SSH servers do.)My preference would be to defer the anonymous use-case to http(s) rather than continuing with life support for FTP, or to try and make Secure FTP solve this use-case better.
It also doesn't mean that we can't fix FTP - though to be fair, there have been multiple efforts to do this that have not taken hold.My perception is that most people have migrated away from ftp to http for the majority of use-cases (anonymous downloads), and to sftp for authenticated/encrypted use-cases. Rsync is also common, but not documented by the IETF at all.My impression is similar to yours. But there are still "corner cases" in which FTP provides useful functionality that sftp does not. For example, there are still machines with file systems that support a wide variety of file types.Fortunately FTP will continue to live on forever for the use-case it is needed. That shouldn't necessarily mean we can't change the protocol status of it to HISTORIC.
But the reason to move something to HISTORIC is not because
people think it's old, but because there's now a far superior and
widely deployed alternative. For FTP that hasn't happened yet.
Keith
