Re: Call for Community Feedback: Retiring IETF FTP Service

[Keith Moore <[e-mail]>]

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.