DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type:content-transfer-encoding;
 b=B6NGvG66eADoAWw+n+E9QgfgTtmFdg7GgMQ9ojuRQrFdDQboKjJTZ1y3pMEtDThF/B
 v+a0H2l0KkT2ep3LuSWWxdLdtIz3zXdFwV941CgMpAnQLKUgFtts/5TNpZjVtrHUvWC0
 CbBj0Ej76/1XYsfHd360kuOEuO9sr1quLe/5U=
MIME-Version: 1.0
In-Reply-To: <2D8ED1C7-F62F-4859-A016-FE8AABEAEBF4@muada.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>
 <2D8ED1C7-F62F-4859-A016-FE8AABEAEBF4@muada.com>
Date: Sat, 21 Aug 2010 17:44:38 -0400
Message-ID: <AANLkTimcp7ENfDtL09HtoSRd2b2psx0mrQ2USYPzAbXK@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ftpext@ietf.org
Subject: Re: [ftpext] FWD: ftp/959 reboot
Precedence: list

On Sat, Aug 21, 2010 at 5:00 AM, Iljitsch van Beijnum
<iljitsch@muada.com> wrote:
> 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 b=
ut 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 w=
ide use (PASV+PORT) and so on.
>
> I don't think revisiting the FTP spec without tightening the spec and dep=
recating 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 th=
e real problem isn't the number of documents, but that what's in those docu=
ments 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 427=
1 where the focus was to document what's really out there seems to make sen=
se.

yep that's what I'm proposing, but there doesn't seem to be enough
interested people.

I posted the httpbis charter here earlier, but I think it's worth reading
http://datatracker.ietf.org/wg/httpbis/charter/

--=20
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
=A0 )) Easier, More Reliable, Self Healing Downloads