Re: [ftpext] FWD: ftp/959 reboot

Paul Ford-Hutchinson <paulfordh@uk.ibm.com> Mon, 16 August 2010 09:48 UTC

Return-Path: <paulfordh@uk.ibm.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 25F303A6960 for <ftpext@core3.amsl.com>; Mon, 16 Aug 2010 02:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 YTIv9LrNIwWJ for <ftpext@core3.amsl.com>; Mon, 16 Aug 2010 02:48:18 -0700 (PDT)
Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by core3.amsl.com (Postfix) with ESMTP id B66E23A681F for <ftpext@ietf.org>; Mon, 16 Aug 2010 02:48:17 -0700 (PDT)
Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o7G9mr5i008365 for <ftpext@ietf.org>; Mon, 16 Aug 2010 09:48:53 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7G9lacx3354826 for <ftpext@ietf.org>; Mon, 16 Aug 2010 10:47:36 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o7G9laia032511 for <ftpext@ietf.org>; Mon, 16 Aug 2010 10:47:36 +0100
Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o7G9lZZs032466 for <ftpext@ietf.org>; Mon, 16 Aug 2010 10:47:36 +0100
In-Reply-To: <AANLkTinu45hNphk7xxUA63AYMONES4qjOH2+-Hny0HMc@mail.gmail.com>
References: <Pine.LNX.4.64.1008051641520.24282@iskra.ottix.net> <alpine.DEB.2.00.1008052249300.11871@tvnag.unkk.fr> <AANLkTi=1ePodG=2G9Ta-=5Fut6x-bQxvq8eLXsVgaUjh@mail.gmail.com> <alpine.DEB.2.00.1008092256460.10815@tvnag.unkk.fr> <AANLkTikB0J_aL7CTwnC17wH2+FS=QgQB5SCL2Jp9iJBd@mail.gmail.com> <Pine.LNX.4.64.1008101303001.1146@iskra.ottix.net> <AANLkTim1VnSPnhmuMa9RC5Ubjnnn=Q+rK6R2riRAznfj@mail.gmail.com> <Pine.LNX.4.64.1008102153320.1146@iskra.ottix.net> <AANLkTinu45hNphk7xxUA63AYMONES4qjOH2+-Hny0HMc@mail.gmail.com>
To: Anthony Bryan <anthonybryan@gmail.com>
MIME-Version: 1.0
X-KeepSent: 5B02220E:0F9A99E3-80257781:003494C5; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
From: Paul Ford-Hutchinson <paulfordh@uk.ibm.com>
Message-ID: <OF5B02220E.0F9A99E3-ON80257781.003494C5-80257781.0035C9C7@uk.ibm.com>
Date: Mon, 16 Aug 2010 10:48:16 +0100
X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 16/08/2010 10:48:18, Serialize complete at 16/08/2010 10:48:18
Content-Type: multipart/alternative; boundary="=_alternative 0035C62B80257781_="
Cc: ftpext@ietf.org
Subject: Re: [ftpext] FWD: ftp/959 reboot
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: Mon, 16 Aug 2010 09:48:19 -0000

Anthony Bryan wrote on 15/08/2010 20:50:27:

> 
> current implementations are probably mostly fine. the way things are,
> someone working on a new FTP app wouldn't even know 1123 existed.
> 

My experience of creating an FTP server from scratch in 1994 was that:

RFC959 was obviously useful
RFC1123 was just a list of things that I had to implement even if it made 
no sense in my environment (this is a _good_ thing from a standards and 
interoperability point of view)
There were some other RFCs that were also useful, I don't remember exactly 
how though.

To actually get it to work, I had to do an awful lot of dumping of tcp 
traffic between existing clients and servers because the spec (RFC959) is 
nowhere near defined enough to write an implementation.  (for example, the 
relative timing of the opening/closing of the data connection and the 
related FTP control connection commands is critical but undocumented, 
which is why I put them into RFC4217.)

I guess that the point I'm trying to make is:
- to write an implementation, you need to do more than just read the 
obvious RFCs, whilst we can and should help people to find the required 
information, in order for them to get to end of job coding such a beast 
will require either a huge documentation effort on our behalf, or a bit of 
gumption on theirs.

Paul