GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc595

Network Working Group Wayne Hathaway Request for Comments # 595 AMES-67 NIC # 20617 12 Dec 1973 References: NIC # 20812

          Some Thoughts in Defense of the TELNET Go-Ahead

This note is a reply to Edward Taft's "Second Thoughts on TELNET Go- 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 to 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.

Hathaway [Page 1] RFC 595 In Defense of the TELNET Go-Ahead December 1973

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

Hathaway [Page 2] RFC 595 In Defense of the TELNET Go-Ahead December 1973

 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

Hathaway [Page 3] RFC 595 In Defense of the TELNET Go-Ahead December 1973

 (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.
 The problem of links containing system output intermixed with user
 input is more difficult.  In any implementation it seems the LAAT user
 will have to be aware of what is happening and manually control his
 terminal to some extent, but that is reasonable when dealing with an
 "alien" system.  More definition work is called for in this area, to
 solve the efficiency problem for LAAT hosts.

"A PROPOSAL"

 The proposal appears on the surface to be that "suppress GA" should
 be the NVT default, which would be perfectly acceptable to me (and I
 would suppose to other LAAT users): two additional messages upon
 opening a connection is a small enough price.
 But in fact that is not the proposal at all -- the proposal is really
 to remove the requirement that all server systems implement the GA.
 This I object to very strenuously since, as I feel I have shown, the
 benefit to the LAAT system and user of GA far outweigh its cost to
 other types of server systems.  And of course the expense of going
 into "suppress GA" mode when appropriate is truly negligible.
 The proposal for having those user TELNET's which do not support
 reverse break retain permanent control over terminals is also weak,
 even without GA.  In our current implementation the assumption is that
 for each line entered by the user, the server system will respeed
 with something.  Control of the terminal is thus retained after input
 until some output is received and printed, when the terminal is again
 made available for input.  The "attention" key is defined as a toggle
 switch to control the terminal keyboard: if pressed while the
 keyboard is unlocked (open for input) it will lock it until the next
 available output message and if pressed while keyboard is locked

Hathaway [Page 4] RFC 595 In Defense of the TELNET Go-Ahead December 1973

 it will be unlocked for input.  The user may also enter a true unlocked
 mode, in which the terminal is always returned to him for additional
 input (after printing all queued output).  This is used, for
 example, for input to a text editor which does not issue prompts for
 each line, the mode may be changed at any time by the user, and the
 "attention" key may of course be used to retrieve expected but
 infrequent output.  This combination mode has proven much more effective
 than the proposed "user must press attention for all input" mode.
 Of course the addition of GA will allow the user process to wait for
 a "complete" reply before printing anything, which will eliminate
 much of the use of "attention", as well as improve system efficiency.

A GRIPE OF MY OWN

 I would like to add one complaint of my own at this point.  The
 implementation schedule for the new TELNET called for a date of July 1
 when systems should accept new TELNET without causing errors.
 This date was presumably agreed to by responsible representatives of
 effectively all active network sites.  My system has been using the
 new TELNET since early September (significantly after the allowable
 date) but I have been forced to disable all server-generated GA's
 because (among other problems) TENEX "SNDMSG" does not work when GA's
 are received over the FTP TELNET control connection.  Disabling the
 GA's was of course required in order for me to receive any deliveries
 from the Network Information Center.  This brings up three points.
 First, I sincerely hope that service functions like the NIC intend to
 accept the new TELNET protocol by the January 1 implementation date.
 Second, in response to RFC#593 by Alex McKenzie and Jon Postel, I do
 not feel that attempting to use a second TCP socket for "new TELNET"
 will work, because of the use of TELNET by FTP.  In fact, it does not
 seem too difficult to make a "compatible" TELNET which will accept
 either mode (which sites have had since July 1 to do) and I feel that
 this is the most reasonable implementation method, even if it makes
 the January 1 date impractical.  And third, perhaps sites should be
 more cautious about commitments to implementation schedules in the
 future.
       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Mirsad Todorovac 5/98 ]

Hathaway [Page 5]

/data/webs/external/dokuwiki/data/pages/rfc/rfc595.txt · Last modified: 2000/06/02 18:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki