defense of the Telnet Go-Ahead(2)

    The reason for doing this is　obvious: many hosts continue to send single characters even in LAAT　systems, resulting in a significant increase in overhead. Equally　obvious is the fact that in this mode the GA mechanism will function　quite well, in fact as well as turning the line around to unlock the　keyboard of a local terminal.

　　This further brings us what is to me one of the main reasons for the　GA mechanisms: the need for a scheme similar to the above for user　TELNET's. The problem is as follows: a user TELNET on a LAAT system　has no required "end-of-message" signal for incoming server-generated　messages, and so is required to read each character as it comes, with　attendant overhead. In addition, the user process is forced to write　each character as it arrives, since it never knows when the server　will stop sending. On systems which support reverse break this　results in little more than erratic terminal behavior, but on systems　which do not support it, it is left up to the user to manually turn　the line around (which he can do reasonably well with "attention").

　　Of course the overhead of handling character-at-a-time input on a　line-at-a-time system is also significant.

　　This is what I see as the most valuable reason for the GA mechanism,　as was noted in NIC#20812: it is not so much a request for input as　an assurance (although not an irrevocable one) that the server is　through sending output. In fact, that is what the name implies to me:　go ahead, it's your turn to type, I'm through for a while. Perhaps　some of the objections would be eased if this aspect were given more　emphasis? As an aside, the problem of spontaneous system messages　that might be generated after a GA is sent is not a major one in　practice, as the user will surely see the message as soon as he　manually turns the line around (enters his next input line). Note of　course that the spontaneous message should also have a GA following,　to serve as "end-of-message" to the receiving NCP. Further, if　the user system supports reverse break, it can deliver the message as　soon as it likes.

　　"IMPLEMENTATION PROBLEMS"

　　Perhaps the above discussion will remove some of the objections from　this section? The GA should be sent when a system has a "reasonable　assurance" that it is not going to generate additional output (eg,　after a system prompt). If this assumption turns out to be false　there is no problem: the additional output is simply sent, also　followed by a GA. The main point here is that known multi-line output　(eg, editor printout, message-of-the-day, SYSTAT) would have only the　single GA on the end.

　　Finally about linking. I agree that on a system like TENEX links　should probably not use GA's, but have you been involved in a　link to a user on a LAAT system? The LAAT user is of course generating　complete lines, which are sent over such a link. This can　be very disconcerting to a character-at-a-time user, who all of a　sudden has dozens of characters printing at full terminal speed　(often against the right margin). And I can hardly imagine linking　from a 2741 on a TIP to a TENEX user: one would never get anything　typed, with all the line turnarounds.

　　In fact, in all the linking that I have done from our (LAAT) system　to TENEX we have very quickly agreed on a manual GA mechanism (eg,　"over"). For straight conversational links I do not feel that it is　unreasonable to have a simple way to ask your local process to send a　GA (although GA is mostly defined in the server-to-user context,　which breaks down somewhat here). One further supportive comment: a　spoken conversation is of course line-at-a-time, with "obvious cues"　(pauses, questions, etc.) serving as GA's. The situation is of course　quite livable, even when spontaneous talk overrides the GA ("Oh,　before you answer that, ..."). This occasionally results in the need to　repeat a line, in an exact analogy to the problem of lines garbled by　a reverse break or printed against the right margin.