[ftpext] FWD: ftp/959 reboot

["William F. Maton" <[e-mail]>]

All,
 	I'm forwarding an email from Gregory Lundberg who is the author of 
a couple of expired drafts from the old WG and the former maintainer of 
wu-ftpd.  I have his permission to send the relevant extract of an offline 
conversation he and I have been having about FTP in general.  He might 
join us for further observations and discussions when he is able to, but 
in the meantime I can summarize responses to him offline.

Thanks,

wfms

---------- Forwarded message ----------
Date: Wed, 28 Jul 2010 08:44:36 -0500
Subject: Re: [wuftpd-dev] Sample help output from ftpd

My opinion on the restart of the FTPEXT WG is that it's time (well past it, 
actually) to do a reboot on the FTP specification.  Anyone today who attempts 
to determine what the protocol *is* has to look at far to many RFCs, some 
offering contradictory specifications.  This is unacceptable for one of the 
core protocols of the Internet.

Over the years, some have said the FTP is a dying protocol.  Mainly this comes 
from the HTTP camp.  The problem is very few people step back and look at 
first-principles.  Another problem is what I call "nominal realism", which is a 
bit of a misuse of the term.  What I mean is they see the word "file" in "file 
transfer protocol" and presume the FTP is only meant to transfer files in the 
traditional meaning as a sequential dataset on computer mass storage.

To understand the FTP's place in the scheme of things we first need to ask 
ourselves: what are the various ways we can use IP, TPC and UPD for the 
transmission of large streams of information.  A very efficient scheme is to 
use a TCP channel for the control of data transmissions and separate channels 
for each transmisison.  This is the scheme implemented by the FTP. Another 
scheme is to use a single channel for both control and data as in the HTTP.  A 
little analysis shows that the scheme used by HTTP works best when a large 
number of relatively short transmissions are involved.  But when the size (or 
duration) of the transmission increases, the FTP quickly becomes more 
efficient.

A re-boot of the FTP specification should include some discussion of this. It 
servers both as a rationale as to why the protocol is still important, and as a 
guide for implementors.

Some years ago, the Apache Group was quite interested in taking a look at what 
it would take to merge wuFTPD into the Apache code base.  This turned out to 
not be possible because the Apache code base assumed a single channel for both 
control and data and could not be bent far enough to support the two-channel 
approach of the FTP.  This, however, was a software limitation. There is no 
particular reason a daemon could not be designed which supports both the FTP 
and the HTTP.  Care should be taken when specifying the operation of the FTP so 
as to not specify or encourage the use of a particular implementation method. 
If we look at the current FTP specification we see some discussion which does 
promote a particular design.

Another thing I'd suggest looking at is avoiding any semantic meaning for the 
data channel.  The term "file" is often used.  But the data channel is just a 
data channel.  Once established, the FTP really does not care what is sent, 
which direction it goes, or if data is travelling both wats at the same time. 
The job of the FTP is to reliably and securely establish the data channel 
between two resources; nothing more.  Recent additions to the protocol have 
provded addition information about the resources.  This recognized that there 
is more to a resource than simply it's name and establishing a reliable 
communication can depend upon that information.

One of the great features of the FTP is the actual *EASE* with which the 
protocol can be realized.  It is virtually impossible to have a meaningful HTTP 
session using Telnet.  While this is little used, part of the power of the FTP 
is it remains possible.

The great failing of the FTP also stems from its strength.  The use of a second 
connumication channel opens the door to abuse or misdirection of that channel. 
When I was last active I was in the process of designing a means where the 
controlling client and server could exchange information about the actual 
channel and ensure it was not intercepted or misdirected.  I imagine all work 
in that direction ceased.  If we re-visit the protocol, however, this should be 
one of the goals.

OK .. enough for now ..

ttyl
-- Greg