Re: FTP history

--On Monday, May 27, 2002 9:58 AM -0700 Dave Crocker
<[email protected]> wrote:

> At 12:43 PM 5/27/2002 -0400, John C Klensin wrote:
>>   While FTP apparently lends itself to "direct UI", it
>> was never intended that way.
> 
> John,
> 
> I have a pretty clear recollection that when FTP first came
> out the folks who wrote the spec honestly expected to be able
> to sit at a TIP, telnet over to an FTP server, and type
> commands that would effect file transfers.

Well, I was part of that working group.  Yes, many things were
designed so that one could do them from TIPs, however painfully.
We could debate about whether it was a primary goal; my
recollection about FTP was that it was _designed_ for transfers
between hosts with file systems, which the TIP definitely did
not have.   One might rationally argue that the notion that
Internet protocols be based on ASCII verbs and command strings,
rather than binary ones, originated in the desire for TIP
compatibility, with the debugging and clarity advantages being
noticed later (I'm not competent to debate that either way).

But, unless I have lost all memory in the ensuing years, the
two-stream model was designed to permit asynchronous operation
(in particular, to permit the STAT and ABOR commands to operate
accurately while data were moving).   The ability to do tricks
with TIPs was, if anything, secondary.

> I even have a vague recollection that this was used to send
> data to a printer attached to the TIP on another port.

Certainly possible, but I would think somewhat later.

>> For example, use of "TYPE ASCII" transfers requires
>> translation between the character set of the sender and
>> network ASCII and translation by the receiver from network
>> ASCII to local character set and formats.
> 
> Not if the receiver can process network ASCII directly, as
> some did.

If by "process directly" you would include processing in their
TTY drivers, certainly so.  But the protocol specified that such
processing had to be possible.  Note that even "translation" of
network ASCII into the 4x7+1 format used on most of the PDP-10
derived machines and into the 4x9 format used on Multics, still
required some processing at the receiving end: as far as I
recall, there were no 28 bit machines on the network.

>>   Even when those hosts use ASCII, the
>> translations must accomodate, e.g., conversion of end of line
>> conventions.
> 
> Not if they supported CRLF directly, as some did.  In fact,
> that was why CRLF was chosen and end of line, rather than a
> single character.  A single character would have made lexical
> analysis notably simpler.

Again, our recollections differ.  Multics used LF only because
the original version of ASCII defined it as a "new line" (first
character position on next line) character.  It was changed to
optional interpretation as an "index" character (same character
position on next line) with the first revision of ASCII, in
order to accomodate some issues with EBCDIC translation as well
as better compatibility with TOPS-10, which used CR internally,
at least in its terminal interfaces (another long story, if I
recall).  CRLF was chosen as end of line in network ASCII
because it was reasonably safe (not-data-destructive) under
either local interpretation.   If I recall, like many other
systems before and since, the TIP accepted commands to specify
what it would send when it received a raw CR or LF.

>> But the protocol is no more designed as a "direct UI" than
>> SMTP
> 
> SMTP came around 10 years later.

Yes, of course.  I didn't mean to suggest otherwise.

> However, the original MAIL command in FTP was explicitly
> intended to permit direct typing over a telnet connection.
> And it was in fact used that way.  (That was why there was a
> distinction between MAIL and MLFL which did the data transfer
> over a separate FTP data connection.)

Indeed.  And that direct use of the command connection permitted
both the use of TIPs and the use of very low-end implementations
for sending mail that could not handle two-stream FTP.   But I
would have thought that would support my point that the protocol
was not designed for general direct use as a UI.

     john