[idn] Re: FTP history

[Dave Crocker <dhc@dcrocker.net>]

ain't history fun...

At 01:37 PM 5/27/2002 -0400, John C Klensin wrote:
>   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;

Consideration of the ability to enter user commands "directly" via TIP 
Telnet was an explicit consideration in specification meetings in those 
days.

That was my only point:  Folks thought that they were providing a UI 
environment.  In fact they were not.

They were providing an environment that permitting human data entry, which 
is a far cry from anything that can be called a UI for anything other than 
programmers, and not really even then.


>  my
>recollection about FTP was that it was _designed_ for transfers
>between hosts with file systems, which the TIP definitely did
>not have.

That statement does not contradict my observation about the design of the 
command and response interface.

In fact, that was the whole point:  The work at that time was an experiment 
in defining protocols that were simultaneously inter-system communication 
interfaces AND user interfaces.


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

and TIP compatibility was not for programmatic interfacing.  it was for 
humans.

That was the simplistic definition of 'user interface' back then.  Now, 
usability work pays more attention to a richer range of cognitive factors.


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

right.  sit on a tip.  direct transfer between two remote machines.  have 
the ability to issue commands over the command channel while the transfer 
is taking place between the two remote servers.


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

I recall it in the 1973 timeframe.  I only went to the last FTP 
specification meeting.  It was in 1973.


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

There were all sorts of machines on the net.  I did not say that all of 
them  processed CRLF directly.  I said that some of them did.  To be more 
precise, some of them could productively take raw data from the net and 
shove it to a destination like a printer or a TTY, with no translation.


>Again, our recollections differ.  Multics used LF only because
>the original version of ASCII defined it as a "new line"

Again, I did not say that all machines handled crlf unchanged.  I said that 
some did.  And I said that that was a factor in the choice of crlf as eol 
character, rather than choosing the much more convenient model of a single 
character.


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

Forgive my confusion.  You were introducing a number of protocol references 
as countering my claim that application protocol work in the early/mid-70's 
was trying to make protocol command environments work both for IPC and for 
UIs.

Since I was not claiming that all Internet protocols were designed with 
this intent, I am unclear how my point is supported or refuted by citing 
protocols that were not designed with this intent, especially when they 
were designed 10 years later.

One should note, however, that SMTP did not retain the two-channel model 
and that typability was part of the factor.

d/

----------
Dave Crocker <mailto:dave@tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850