rfc595.txt

RFC 相关的技术文档

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]