- Everything that HTTP continues to reinvent that was in FTP before there was an HTTP.
That’s not an answer, of course, but okay. I guess you meant the list below.
- Yes; it opens a connection per exchange and let’s IP multiplexing do its job. As far back as the mid-90s I noted that HTTP was headed towards reinventing that muxing at the app layer and it now does.
That creates a problem of layered multiplexing and how the two interact, esp. for DSCP tagging, among other things.
The TCP and TLS handshake costs are seen as prohibitive. I guess not for FTP which isn’t used in e-commerce much. Might be interesting to code up an FTP script that fetched Amazon’s homepage via TLS. But hey, let’s throw out TCP fastopen
and TLS earlydata, too.
- Don’t reinvent multiplexing, for one. Have a common data encoding or support translation. Separate the control channel from the data channel. Support transfer restart. Support parallel transfers without
HOL blocking. Support transfers with record boundaries.
Multiplexing, see above. Common data encoding seems to be mime-types and Accept headers. Restart and record boundaries seem to be covered by byte ranges. Control channel is a neat idea, I guess that’s QUIC’s stream zero. Or BEEP’s channel
zero. I liked BEEP, too bad the Internet didn’t.
