defense of the Telnet Go-Ahead(1)

　　Ahead" (NIC #20812). Specifically, I will attempt to show the following about the three main directions of his objections:

　　1. It is the idea of line-at-a-time systems which are esthetically　unappealing, not the GA mechanism. This may be a valid point, but　given the large number of such systems on the net, it would seem a　rather academic one.

　　2. The specified GA mechanism will in fact work very well between　(reasonably implemented) line-at-a-time systems, and should provide　significant help elsewhere.

　　3. While the GA mechanism may not be correct in all cases, it can　provide significant advantages fro the line-at-a-time systems and　users.

　　My comments will be arranged under the original headings from the　subject RFC(NIC #20812).

　　"TECHNOLOGY"

　　The definitions of "half-duplex" and "reverse break" are　satisfactory. Two points should be made regarding "reverse break",　however. First: having reverse break on the terminal is of course not　sufficient; the operating system must support it. As "support" is　equivalent to "require" in this context, it is not too surprising　that some systems do not in fact do this. That is, there are systems　which will not type through an unlocked keyboard until the user　manually turns the line around, and the operational problems with　such systems are much less than might be assumed. Second, at least on　IBM 2741's and equivalent, the line turnaround takes a significant　amount of time, during which user-typed characters may be missed or　garbled. In fact, a fairly standard mode of operation with systems　that use reverse break (including TIP's) is to automatically enter　a "line delete" character and start over every time the reverse break　is used while typing, which can hardly be called esthetic. One　solution to this problem would be for the system t not use reverse　break once the user has begun typing (as suggested near the end of　NIC #20812), but most systems (including TIP's) do not do this.

　　Some discussion is also warranted at this point about line-at-a-time　systems (hereafter abbreviated as LAAT systems). One prime reason for　LAAT operation is to avoid the overhead of interrupting the CPU(and　possibly the user process) for every character typed. Instead,　characters are buffered (in a controller, a front-end computer, etc)　until some "end-of-line" signal is received; they are then passed to　the system in a group. This means that the system is totally unaware　that any typing has occurred until the "end-of-line" signal is sent;　a partially completed line will literally never be recognized.

　　"ESTHETIC OBJECTIONS TO GA"

　　From the above, I feel that one can see that it is the operating mode　of a system rather than the type of features of its terminals which　determines whether GA is useful or not. For example, IBM front-ends　handle Teletypes in LAAT mode, while the TIP attempts to run 2741's　as full-duplex devices (with something less than "a very good job at　turning the line around," from my experience).

　　At any rate, the half-duplex/full-duplex debate can go on forever --the problem here is to try to smooth the way for users on local LAAT　systems connected to foreign systems of varying characteristics.

　　"WHY GA WON'T WORK"

　　As mentioned, in LAAT systems no terminal input is recognized until　the specified "end-of-line" character is entered, preceding characters　having been buffered in a front-end etc. This can of course be　carried over into server TELNET: incoming network messages can be　buffered at a very low level in the NCP awaiting a TELNET end-of-line　signal. User processes wanting input would remain blocked until the　end-of-line is received, rather than being handed each character as　it is read. In fact, this is the implementation in all of the LAAT　systems with which I am familiar.