RE: Regarding "Call for Community Feedback: Retiring IETF FTP Service"

[Roman Danyliw <[e-mail]>]

Hi Keith!

> -----Original Message-----
> From: ietf <[e-mail]> On Behalf Of Keith Moore
> Sent: Wednesday, November 25, 2020 6:50 PM
> To: [e-mail]
> Subject: Re: Regarding "Call for Community Feedback: Retiring IETF FTP
> Service"
> 
> On 11/25/20 3:25 PM, Hannes Tschofenig wrote:
> 
> > I am curious why you need these features.
> 
> You mean, you really don't understand why these features are useful and can
> save significant time for many IETF participants?

Thanks for the details.  The comments I'm making below are in the spirit of clarifying that the workflows (as I understand them) could likely be enabled through non-FTP services albeit with different trade-offs.  I am not attempting to convince you to change your personal workflow.

> - An ftp server can be treated as a remote file system by many platforms.  That
> means, for example, if you're editing an I-D and you want to refer to some
> other document, you can open that document in your favorite text editor
> without the editor needing specific support for FTP.  If your editor has windows
> (such editors have existed since at least the late 1970s), you can see the I-D you
> are editing and the document you're referring to side-by-side with no wasted
> screen space. This is a LOT more effective than trying to deal with your editor in
> one window and a web browser in another, partly because web browsers and
> web pages both tend to make very poor utilization of screen space, but also
> because multiple windows within your editor have the same UI, whereas the
> web browser and your editor probably have different UIs.   

Multi-editor windows doesn't seem tied to mounting a remote filesystem via FTP at all.  Likewise, I'm not sure why a web-browser needs to be used at all.

A remote filesystems seems to be about the convenience of accessing the files.

> The same feature
> makes it possible to _easily_ print some set of documents ("lpr draft-
> *workinggroupname*.pdf), or copy some set of documents, or search through
> ("grep") some set of documents ("which internet-draft contains the text...") or
> ("which internet-drafts reference RFCXXXX?")

Up front -- there is no way to currently mount a remote filesystem from IETF services with anytime but FTP.

I will point out that the equivalent if this workflow (command line manipulation of directories of files) can be done by rsyncing the repo (whereby making an explicit cache) and all CLI sequences should work.  Several GB of explicit storage will be required though (so perhaps this is a constraint).  It also might be that case (all depends on the file driver's caching strategy) that if multiple commands which inspect a large number of drafts are used, it may be faster and use less bandwidth (e.g., grep multiple times across all I-Ds).

As said previously, every top-level directory currently in FTP has an rsync point.  See https://mailarchive.ietf.org/arch/msg/ietf/b8BfvrcpLmvvjkhJ1MW8DUEzmQ8/.  

> [I personally find printing is the best way to review documents because then I
> can easily annotate them with ancient writing utensils, which is far better than
> trying to do so using any keyboard-based tool I've ever seen.   And I refuse to
> feel bad about that :) ]
> 
> - Some FTP clients have filename completion.   So if you're looking for a
> particular file, you don't have to search through all of the text on a web
> page.   Sure the web browser has a Search feature, but it doesn't distinguish file
> names from other text, and there's no assurance that the files you're looking
> for are all grouped together.   Filename completion can be implemented fairly
> efficiently in FTP, because if you type "a" the client can do "LIST a*", then when
> you type "b" after "a"
> the client can do "LIST ab*", etc.
>
> - Most FTP clients support multiple file transfer via wildcards (e.g.
> draft-*-workinggroupname-*) .   Many support an effective "batch"
> transfer UI: Select the files you want and press "start" or some such, and all of
> the files you selected are quickly transferred for you. This has been an effective
> interface for file transfer ever since at least the Xerox Alto, and has been
> duplicated by many clients since then because it works well.  Web browsers
> generally require you to start each transfer separately, maybe specify a
> destination for each separately, and often, to manage them separately (they
> may queue up multiple transfers or do multiple concurrent transfers but you
> still have to go back and check to see that they were successfully downloaded
> because failures are common for some reason.  The browser is really optimized
> around letting you read things rather than letting you transfer files, especially
> multiple files, robustly.).

As above -- use of rsync + OS shell may provide similar functionality (with different assumptions, local storage and periodic refresh).
 
> - Similarly, many editors have built-in or plug-in support for FTP.   A lot of
> Windows users like Notepad++ which has a plugin for this.  GNU Emacs for
> Unix/Linux has an "ftp" command (M-x ftp) that basically lets you talk to the
> local ftp client on your machine, but it also ships with "remote file" support so
> you can directly open (for example) /ftp:[e-mail]:ftp/internet-
> drafts/draft-moore-exclusionary-language-00.txt

Plugins into favorite editors doesn't strike me as a unique feature.

I'm not a user of GNU Emacs, but I suspect you could load arbitrary URLs into your buffer by:

C-u C-M-! curl -s https://www.ietf.org/archive/id/draft-moore-exclusionary-language-00.txt'

Courtesy of https://lists.gnu.org/archive/html/help-gnu-emacs/2007-03/msg00335.html

I also found this Notepad++ plugin that would nicely interact with an rsync cache (https://github.com/funap/npp-explorer-plugin) 

> .   Filename completion is supported here so at any point  you can type ? to list
> potential completions or TAB to complete the filename as far as it can be given
> the alternatives available. MUCH faster than searching in a web browser.
> 
> - Using FTP, I can search for an internet-draft or RFC from my phone; I can
> browse the documents by name or date order or size; I can edit the document
> on my phone or import text into notes or email; I can send the document to a
> printer from my phone.    Yes, the phone has a built-in web browser but many
> web sites are far from ideal for a handheld device.   By contrast the FTP client is
> written specifically to be used on such a device, so it doesn't waste screen
> space AND it's more functional for some purposes than the web browser.

I'm not so sure about FTP being unique here.  My personal experience is that the mobile app and OS feature set is very robust.  I have sent RFCs to print from my phone/tablet +and imported text into an email too without using FTP.

Regards,
Roman