Re: [ftpext] FWD: ftp/959 reboot

[Daniel Stenberg <[e-mail]>]

On Thu, 5 Aug 2010, William F. Maton wrote (quoting Gregory Lundberg):

> 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.

I can only agree that the situation is muddy and far from good.

> 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.

I read this opinion from time to time, and I'm very curious: what facts or 
what particular details of TCP are you backing up this statement on (realizing 
this statement was quoted from a secondary author)? Why would a single HTTP 
stream be any worse than a single FTP stream? Given a large enough file, the 
tiny tiny difference that the HTTP headers add vanish, and the FTP transfer 
typically suffers from MANY more initial RTT delays etc.

So yes, I would be very interested in such a rationale. In the past I've 
confronted others who have said similar things, but I've not yet heard anyone 
provide a believable explanation.

> 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.

Really? As a client implementor I've never really seen that. Perhaps I'm just 
too indoctrinated by it by now. Any particular wordings or phrases that stand 
out and explain what you mean?

> 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.

I agree. I supposed we could look for inspirations for this in the httpbis 
work.

> 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.

I find that statement rather funny and something I wouldn't agree with. A 
HTTP-minded person would say it exactly the same way but replace HTTP and FTP 
in that sentense. The fact that HTTP is a single connection still wins I'd 
say, and makes TELNET possible while telnetting a FTP transfer with telnet 
requires two telnet invokes, or with PORT something like nc or what not.

> 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.

My experience with the data connection: it was possibly a good idea back in 
the early days. It is now a bad idea due to NATs, stateful firewalls, FTP over 
TLS and possibly other stuff.

* NATs close idling connections, and there's no way to really portably keep
   traffic going on the control channel while a really long and slow data
   transfer is in process so implementations have to deal with the control
   channel being killed by the NAT before the data is done.

* Firewalls need to understand FTP in order to support it fully without
   opening up ranges for it "just in case".

* When FTP traffic is sent encrypted, said firewalls don't see the FTP traffic
   and thus cannot act stateful so the data connection cannot get setup.

-- 

  / daniel.haxx.se