On 11/16/20 5:15 PM, 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.
Only read in a vacuum. If you read further, I argue for the stable interfaces you want.
Ok, so why not use an existing interface that has proven to be
stable through decades of use, instead of one that _might_ be
stable in the future?
I believe that your objections (here and elsewhere) mentioning "user interface" conflate HTTP (transport) with HTML (markup), and mixing user interface into the RFCs isn't a foregone conclusion: the requirement you have of not mixing display in with documents is why I suggest that raw versions be made available.
Sorry if I wasn't clear, but that was not my concern. My concern
is that the web interface taken as a whole (including not only the
RFCs themselves but also any browsers, HTML, JS, CSS, fonts, etc.
that are used to make up the entire user interface) are all
optimized for one kind of user experience, and NOT for use as an
API to be used by programs. So if someone later decides to
rearrange or otherwise alter the RFCs, or reconfigure servers, or
whatever, in order to improve user experience, that will be seen
as the Right Thing to do regardless of any concerns that people
might have about the API changing.
I would argue that that's really the argument in favor of
deprecating FTP that we are seeing now - that the stable API for
accessing RFCs is irrelevant, because it's only the user
experience via the web that matters. And I do have a big problem
with that.
It has been claimed that the use of FTP constrains file system
layout, but it's mostly the API that constrains the file system
layout.
And I even argue for making the filesystem mountable like you requested, even if I consider that use case to be a bit baroque.
With FTP, I can mount the RFCs as a file system this very minute
(as I just did) and treat those RFCs as local files (say by
grepping through them, as I just did). With FTP it's unambiguous
as to how to do this and the code to do this has existed for many
platforms for many years. With WebDAV, this is also possible, but
at the cost of ALL current users having to retool. And I have no
idea how widely WebDAV is supported - though I did verify that a
FUSE interface to it exists for Linux.
(I don't personally consider remote file system access to be
baroque at all; to me it seems relatively straightforward and much
easier to use in some ways than a web service. For instance, I
can very easily download, or print, multiple RFCs in one command,
without having to click on each link separately, specify its
download directory and file name, etc. This works because FTP
always was quite clearly a protocol for accessing files on disk. )
I'm sympathetic to the position that all change can be disruptive, and I understand that you know how FTP works and are comfortable with it. At the same time, I'm not yet seeing any requirements that you've put forth that can't be met pretty trivially with HTTP, other than an inferred bedrock requirement of "this must not change at all."
I believe change to long-valuable services needs to be justified,
and not made merely out of a desire to be in fashion.
I never have stated a position that all change can be disruptive. I suspect that's true as a generalization, but I'm certainly not arguing that nothing should ever change. I'm talking specifically about a single service here.
But there really should be a good reason to make such a change.
I have run FTP servers before; they're not much trouble. (another
advantage of using a stable protocol). Taken both client and
server overhead into account, I see less overhead associated with
continued use of FTP, than with WebDAV. It's possible that
there's even more opex on the server side using WebDAV, as the
arguments that have been cited as detriments to continuing FTP
might also apply to WebDAV support.
One thing that might make me change my mind might be if WebDAV
were considerably more efficient or more functional. That is
possible. HTTP/webdav should require less TCP setup overhead, and
does offer the potential for seek/read capability using byte
ranges.
Another thing that might make me reconsider is if IETF wished to
host its servers in some sort of dysfunctional cloud environment
(probably using NAT within the cloud) that didn't support FTP's
use of ports. But I think PASV should still work and it's pretty
much the default these days anyway.
I get it. It's annoying when a technology we like falls by the wayside.
FTP hasn't fallen by the wayside.
I suspect what's happened instead is this: There are people who
think that the way they use computers is the way everyone
should use computers. And if so, I think they should reexamine
their assumptions.
YMMV, of course, but I encourage you to reflect a bit more on how much of your reaction is pushback on any change at all versus actually losing the ability to do what you want to do.
I think you're reading between the lines far more than is
intended or warranted.
Keith
p.s. we could have set up the server in far less time than it has
taken to write these messages.
