On 11/16/20 11:48 AM, Adam Roach wrote:
In the analysis, I think there are two costs to consider and one benefit. The benefit of leaving it online, of course, is that some small group of users still find utility in FTP.
IMO that misstates the benefit. A stable service can have a large (and long-term) benefit even if only a few clients at a time use it.
Once upon a time, before RFCs were officially available in PDF, I put up an "RFCs in PDF" service that downloaded RFCs via FTP and automatically translated them to PDF. That service basically allowed Windows users to print RFCs with the page breaks in the right places. Many people thanked me, the RFC editor asked for my code and eventually provided RFCs in PDF offically. Having a simple, stable API that I could use to watch for new RFCs, and download and process them, made it easy to implement that service.
One of the big problems with moving to HTTP is that HTTP is seen as implementing a user interface, and user interfaces inevitably evolve. The demands of providing that user interface tend to outweigh any other demands.
I don't have a great love of FTP except that I see tremendous value in an interface that has been able to be stable for decades. To me this is a Good Thing, a sign that FTP got some important things right even though there's clearly a lot about FTP that is also baroque. IETF should strive to make all of its protocols be useful for as long as FTP has been.
Unfortunately, HTTP shows no sign of ever getting there. It's a lot more baroque than FTP ever was, and it's not stable. It's great that HTTP is being improved, because it's so heavily used. But it's not providing a stable interface, one that works over time.
IMO, FTP should be viewed as a separate service, also a valuable one, rather than an alternative to HTTP. The two have evolved differently to serve different purposes; neither one is suitable to replace the other.
Keith
