Re: Tombstone README for FTP service

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 29 April 2022 08:32 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C394FC15E6F3 for <ietf@ietfa.amsl.com>; Fri, 29 Apr 2022 01:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.754
X-Spam-Level:
X-Spam-Status: No, score=-3.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.857, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf5nJjCmS-Pi for <ietf@ietfa.amsl.com>; Fri, 29 Apr 2022 01:32:31 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 9F47CC15948A for <ietf@ietf.org>; Fri, 29 Apr 2022 01:32:28 -0700 (PDT)
Received: (qmail 30058 invoked from network); 29 Apr 2022 08:27:54 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 29 Apr 2022 08:27:54 -0000
Message-ID: <9fda9d71-fa4b-0348-8579-868749d88b11@necom830.hpcl.titech.ac.jp>
Date: Fri, 29 Apr 2022 17:32:23 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Subject: Re: Tombstone README for FTP service
Content-Language: en-US
To: ietf@ietf.org
References: <BN2P110MB1107650B16F3338FF4765314DCFD9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <173db55f-3fdc-e6e6-e230-e235cc9ce673@network-heretics.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <173db55f-3fdc-e6e6-e230-e235cc9ce673@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/N_VvSFFYOy_lz7fewWOq9vh_tqQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2022 08:32:35 -0000

Keith Moore wrote:

> It should say that the IETF shamefully abandoned its own protocol, 
> despite it being valuable and providing features that don't exist > in any of the supposed protocols IETF replaced it with.

The essential advantage of ftp over other protocols is that
it support an end system type of "controller", in addition to
"sender" and "receiver", as is documented in rfc765 that:

       data connection
          A simplex connection over which data is transferred, in a
          specified mode and type. The data transferred may be a part of
          a file, an entire file or a number of files.  The path may be
          between a server-DTP and a user-DTP, or between two
          server-DTPs.

which is similar to what we were and still are doing to copy
video contents between two recorders by an IR remote controller.

In general, "transfer" protocol needs three kinds of ends and
both PASV and PORT commands are essentially necessary for ftp.

Other protocols are silently assuming controller=sender or
controller=receiver, which may not be a problem for http but,
with an example above, it can be said that rtsp, for example,
is poorly designed.

					Masataka Ohta