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:[EMAIL PROTECTED]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
