Two FTP issues

John C Klensin <john-ietf@jck.com> Mon, 30 November 2020 22:07 UTC

Return-Path: <john-ietf@jck.com>
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 E96983A1234 for <ietf@ietfa.amsl.com>; Mon, 30 Nov 2020 14:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IVq1s0Zfvkh for <ietf@ietfa.amsl.com>; Mon, 30 Nov 2020 14:07:51 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77143A1222 for <ietf@ietf.org>; Mon, 30 Nov 2020 14:07:48 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1kjrKl-000C5f-FZ for ietf@ietf.org; Mon, 30 Nov 2020 17:07:47 -0500
Date: Mon, 30 Nov 2020 17:07:41 -0500
From: John C Klensin <john-ietf@jck.com>
To: ietf@ietf.org
Subject: Two FTP issues
Message-ID: <AA1E0A8464BC45FB4FA44684@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BlFOYmkrJpSFgJawDKt2U2lm1hk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Nov 2020 22:08:00 -0000

Hi.
Inspired (if that is the right term) by the recent discussions
about FTP, I went back and reread the spec (RFC 959) today and
made two rediscoveries of problems/issues.  Before I explain
them (and try to keep this short), I will pose the key question:
does anyone here have responsibility (or the inclination to fuss
with) FTP client and/or server software and, if so, would you be
inclined to make changes to fix bugs or near-bugs?

Anyone offended by the very idea of updates or clarifications to
FTP should please skip to the last paragraph.

Issues:

TYPE ASCII assumes that whatever text files exist on the sending
system can be converted to NVT ASCII.  Back in 1985 and earlier,
that could require some effort and maybe some small compromises,
but it wasn't conceptually difficult.  Today, with a great deal
of Unicode on the network, there are no possible conversions, at
least unless "NVT ASCII" is redefined to include assorted escape
sequences (clearly not the intent and, from a user standpoint,
almost certainly bad news, but see below).  So:

(1) Do we need a specific error code for "you specified 'TYPE
ASCII' but the file you want to transfer cannot be converted".
In principle, the same code would apply to TYPE EBCDIC, but I
haven't seen much of that the wild lately.  If the answer is
"no", what would we expect implementations to do under those
circumstances?

(2) In the interest of an increasingly internationalized
Internet, is it time to look again at a Unicode type, perhaps
using the long-expired draft-klensin-ftpext-typeu as a starting
point?  I haven't looked at it in seven or eight years, so don't
have an opinion as to whether it would be useful.

(3) I hope the answer to the question of Unicode in NVT ASCII is
not "escape sequence" but, if it is, do we need a specification,
however short, about which of the many possible escape sequences
is to be used and/or identified?

Request: I think the topic of whether anyone who thinks about
using FTP, much less updating it, needs to be dragged kicking
and screaming into the 21st century and/or suffers from some
mental, emotional, or moral problem has been covered thoroughly
in the last several weeks.  Please do not try to repeat it,
especially if the purpose of doing so is to prevent a discussion
among those who are interested.

thanks,
   john