QUIC and HTTP3 are great technologies, but they are never likely to become the only protocol a service supports.
For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first.
UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it.
In the places it works, it provides some benefits. But we're unlikely to see it take over as the sole protocol any time soon.
Not everywhere. FTP-over-TLS is secure, standardised (RFC4217 as updated by RFC8996), and in some environments is still preferred to SFTP, particularly mainframe and minicomputer environments. FTP, due to its age, has a lot of "legacy" features which mean it can work better with non-POSIX filesystems used on mainframe and minicomputer systems than SFTP can. In principle you could add extensions to SFTP to improve its support for non-POSIX filesystems, but why bother when FTP already has very well-established support for that?
Another area in which FTP is still preferred is transfer of very large (multi-terabyte) scientific datasets. GridFTP has defined FTP extensions which permit these transfers, including encryption and striping of files across multiple connections and servers (so multiple servers can cooperate to simultaneously transfer different portions of an extremely large file). SFTP has no advantage for this application, and why bother redefining those extensions over SFTP when they work perfectly well over FTP? The main competitor to GridFTP is not SFTP, but rather proprietary solutions such as IBM Aspera. GridFTP actually supports SSH as a transport, but even then the file transfer protocol is based on FTP not the binary SFTP protocol.
Similar comments apply to TELNET. TELNET-over-TLS is secure, and still preferred in some IBM environments, because there are established protocols for passing 3270 and 5250 block mode terminal data streams over TELNET. Again, no reason in principle why you couldn't define similar protocol extensions for SSH, but why bother when TELNET works perfectly well for this application? And if you really want to use SSH instead of TLS as a transport/security layer, nothing stops you from tunnelling TELNET over SSH.
Thanks for all the knowledge. What is your interest in these protocols, out of curiosity?
Deprecated doesn't mean 'wiped off all computers everywhere'. By that definition, name something that is truly 'deprecated'? An interesting trivia question. I think we have to exclude rare tech like prototypes.
> Thanks for all the knowledge. What is your interest in these protocols, out of curiosity?
Curiosity, yeah, pretty much. One day I decided to read the TELNET and FTP RFCs and became fascinated with all the historical cruft in them. I've also long been enjoyed studying IBM mainframe and midrange systems, they are their own somewhat alien world – most of that study has been limited to reading manuals, although I have mucked around with MVS 3.8J under Hercules (which unfortunately doesn't really have TCP/IP networking, or when it does it is some hacked-on thing with little in common with how TCP/IP actually works on MVS whether today or historically).
> Deprecated doesn't mean 'wiped off all computers everywhere'. By that definition, name something that is truly 'deprecated'? An interesting trivia question. I think we have to exclude rare tech like prototypes.
There are many systems which we know nobody still uses for production use, only for hobbyist / retrocomputing uses. A famous example would be Multics, at its peak it had over 50 production sites, the last production site was shut down in 2000, it took over 10 years between the last production site being shut down and an emulator becoming available so anyone could run it.
By contrast, people still use FTP and TELNET every day in production. Neither is inherently insecure, because both can be used over TLS. The majority of open source FTP/TELNET clients/servers never added TLS support, but commercial/proprietary implementations targeted at IBM mainframe sites do.
For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first.
UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it.
In the places it works, it provides some benefits. But we're unlikely to see it take over as the sole protocol any time soon.