Re: [ftpext] FWD: ftp/959 reboot

Iljitsch van Beijnum <> Sat, 21 August 2010 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55A763A6849 for <>; Sat, 21 Aug 2010 02:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5z7PYn+KLYA9 for <>; Sat, 21 Aug 2010 02:00:14 -0700 (PDT)
Received: from (unknown [IPv6:2001:1af8:2:5::2]) by (Postfix) with ESMTP id 271873A67A4 for <>; Sat, 21 Aug 2010 02:00:13 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.13.3/8.13.3) with ESMTP id o7L8xoIE067792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Aug 2010 10:59:51 +0200 (CEST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Iljitsch van Beijnum <>
In-Reply-To: <>
Date: Sat, 21 Aug 2010 11:00:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Anthony Bryan <>
X-Mailer: Apple Mail (2.1081)
Subject: Re: [ftpext] FWD: ftp/959 reboot
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Aug 2010 09:00:15 -0000

On 9 aug 2010, at 21:17, Anthony Bryan wrote:

> the idea would be to have an updated, coherent, harmonious document of
> RFCs concerning FTP along
> with implementation and real world info like httpbis.

I don't think simple reorganization and clarification will do it for FTP. There is a ton of stuff in the current specs that is no longer used at all (all the fancy file/record organization stuff), stuff that is technically legal but doesn't make sense (PASV+PORT), stuff that is technically legal but isn't used in practice and using it in practice would cause big problems (PASV with a different address in the 227 than the control channel address, EPSV with an argument), stuff that should work but has issues in practice (EPSV), stuff that should have been retired a decade ago but is still in wide use (PASV+PORT) and so on.

I don't think revisiting the FTP spec without tightening the spec and deprecating some currently legal options makes much sense. Yes, it's annoying to have to read so many documents to create an FTP server or client, but the real problem isn't the number of documents, but that what's in those documents and what FTP servers and clients do in practice is so different from what's in those documents. In that sense an effort like RFC 1771 -> RFC 4271 where the focus was to document what's really out there seems to make sense.