On Mon, Nov 30, 2020 at 1:37 PM Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:
My primary criticism:
- port 1965 is already assigned
- new system ports are advised against, per RFC7605
I already let them know.
As to whether the rest is useful, I sincerely hope they’ve studied previous protocols they think are too complex. The protocol design space is littered with examples of “I think I can do better by doing simpler”, only to end up reinventing the wheel (the most infamous example being HTTP vs using FTP).
Having (re)implemented FTP for LIBWWW, I can assure you that it was done for very good reason.
FTP is not really an independent protocol. It is actually designed as a feature add on for Telnet. As a result, FTP is vastly less efficient than HTTP because you have two socket creations and teardowns per connection.
FTP requires multiple control plane interactions where HTTP requires only one.
FTP has no provision for transfer of metadata.
FTP doesn't support proxying or caching, both of which were essential in the early Web when bandwidth was severely constrained.
Of course we could have stuck to vinyl. But FTP is more like grandad's 78s. There is absolutely nothing to recommend FTP over HTTP. Rsync is vastly superior for file transfer.
Sometimes the best answer is to simply chuck out the old and start from a clean slate. Software reuse is good but only to a point and only if the software in question is fit for reuse. FTP is not and it is high time we moved beyond it.
The same is becoming true of SMTP. Yes, we can try to continue to prop up a protocol that has been spammed to death. But the simplest way to get to the heart of the matter is to switch to a new protocol that has authentication and end to end encryption built in from the start.
In fact the only good reason to not start from scratch is the difficulty of deployment. HTTP succeeded so there was really no reason not to switch.
There is absolutely no part of the FTP design I am sorry we left out. None.
