Re: [ftpext] RFC959 update WAS Re: NAT64 client/server document

Iljitsch van Beijnum <iljitsch@muada.com> Thu, 05 August 2010 21:18 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB2F3A6A3F for <ftpext@core3.amsl.com>; Thu, 5 Aug 2010 14:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.437
X-Spam-Level:
X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUFi35kasIrr for <ftpext@core3.amsl.com>; Thu, 5 Aug 2010 14:18:35 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id E95FB3A68D5 for <ftpext@ietf.org>; Thu, 5 Aug 2010 14:18:34 -0700 (PDT)
Received: from iljitsch-iphone.lan (ip5653d69e.direct-adsl.nl [86.83.214.158]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id o75LIF3L084077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Aug 2010 23:18:16 +0200 (CEST) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <AANLkTi=fhqvXwxOctwU=V7choqJPzc_jJx8uyq34NA=A@mail.gmail.com>
Date: Thu, 05 Aug 2010 23:18:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <17396AEB-BB12-4D62-85AD-0A910D71E4BE@muada.com>
References: <40A8C49E-EFF7-482A-B444-81EDFF41449A@muada.com> <Pine.LNX.4.64.1007281024050.15461@iskra.ottix.net> <AANLkTi=fhqvXwxOctwU=V7choqJPzc_jJx8uyq34NA=A@mail.gmail.com>
To: Anthony Bryan <anthonybryan@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: ftpext@ietf.org
Subject: Re: [ftpext] RFC959 update WAS Re: NAT64 client/server document
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 21:18:37 -0000

On 31 jul 2010, at 10:55, Anthony Bryan wrote:

>> In my mind, there are two approaches to updating RFC959:

>> a) As you said, update it and allow for creeping featurism;

>> b) Tightly scope the update to RFC 959 to just being an updated version
>>   of the protocol as it stands today according to RFCs only (not drafts,
>>   not even practices out there on the Internet) and look to fixing it
>>   later...much later.

That seems pointless. The problem with FTP is that the intersection between specifications that are out there and software that is in something that can reasonably called use is quite limited. I think if we want to make a new standards track FTP spec, we should just forget all the existing documents, especially RFC 959, and write up a lean and mean spec that specifies FTP as it is used today. The fact that this ignores an enormous amount of history should be taken as a feature rather than a bug. Anyone interested in that history can always go back all the way to RFC 114 if they want to. But if we want FTP to remain a living, breathing protocol (which is a question worthy of discussion in the first place) we need to remove cruft as well as add new features. We've done the latter for more than a decade, we need to work on the former for a while.

> we now also have RFC
> 5797, the FTP command & extension registry

I'm missing the response code registry, though.

As for the NAT64 stuff that everyone in the room in Maastricht felt must go into a separate document, I'm now convinced that this should be a BCP. If anyone thinks that's not the right way forward, please let me know.