rfc318.txt

RFC 的详细文档！

   both serving and using sites operate, it is necessary to take a route
   in addition to the normal Telnet data stream to indicate that the
   special control signal is embedded in the data stream.

   Example -- Problem:

      The PDP-10 normally will, when it fills its input buffer, continue
      to accept characters from a terminal examining each to see if it
      is a control character, then act on it if it is or throw it away
      if it is not.

      Since the Telnet server at the serving site is at the mercy of the
      NCP with respect to controlling the bunching, and therefore,
      arrival at the Telnet of bursts of characters, Telnet



Postel                                                         [Page 11]

RFC 318                     Telnet Protocol                   April 1972


      implementations might be expected to choke off flow to the buffers
      until they are ready to accept characters without throwing them
      away.

      Under this condition, the serving process might be outputting to
      the using terminal, the input buffers at the server fill up, (with
      user generated characters) and <etx> get stuck (at the user's
      site) in the data stream that has been choked off.

   A similar problem could occur with Multics or some IBM system as a
   line at a time server.  The user at a using site gets his process at
   the serving site into an output loop and wants to break the process
   without having to release his Telnet connection.  The buffers clog
   the connection, transmission is choked off, and the <etx>, Break, or
   other user control signal gets stuck in the pipeline.

   Example -- Solution:

      The user at the using site knows he is entering a special control
      signal (Break, Attn, <etx>, etc.) and follows it with a SYNCH.
      (The local instructions at using sites for accomplishing this may
      differ from site to site.)

         User to Using Site Telnet

            Send SYNCH.

         Using Site Telnet to Serving Site Telnet:

            DATA MARK in Data Stream.

         Using Site Telnet to Using Site NCP:

            Send an INS.

         Serving Site NCP to Telnet Server:

            Interrupt "INS received".

         Serving Site Telnet:

            Examines the input data stream (looking for special control
            signals) until it sees DATA MARK then resumes normal
            handling.

            Thus, depending on the server's local implementation to
            provide adequate service, a special handling of the data
            stream can be invoked whenever an INS is received in order



Postel                                                         [Page 12]

RFC 318                     Telnet Protocol                   April 1972


            to get to the special character.  When it sees DATA MARK, it
            recognizes it as a synchronization point and knowing that
            the special character has been passed on, strips the DATA
            MARK from the data stream and returns to normal mode.

            If the DATA MARK arrives before the INS, the serving site
            should not process the data stream further until an INS is
            received.

   This approach to handling selected special characters or signals
   relieves the using Telnet processes from having to recognize the
   special serving site characters, as well as from having to know how
   the serving site wants to handle them.  At the same time, the
   procedure requires only a minimum level of user understanding of the
   serving site.  This seems appropriate, since the Telnet ASCII
   conventions are providing a Network Virtual Terminal, not a Network
   Virtual User.

   Notice that the correct order is (1) special character or signal
   (e.g. BREAK or <etx>), then (2) SYNCH.

User Telnet Signals

   The ability of the user to cause the using site Telnet to send any
   combination of ASCII characters in a string, and only that
   combination, is viewed as important to the user utility of the Telnet
   ASCII conventions.  Because of this, some user sites may find it
   necessary to provide special local Telnet signals from the human user
   to the using site Telnet.

      Example:

      A user on a line at a time system (Multics, System 360, GCOS,
      etx.), which require an end of line signal before processing the
      user's input, is working through the Network on a serving site
      that operates a character at a time.  The application is a
      debugging aid that permits the user to type in "location=" to
      which it will respond with n where n represents the current
      contents of that location.  The serving site process does not
      expect to see the "location=" followed by a carriage return line
      feed sequence.  The user at the using site should be able to type
      in the location, follow it with a signal (to the user Telnet) to
      suppress the end of line convention, followed by the end of line
      signal, and expect the "location=" to be transmitted immediately
      without an end of line sequence being transmitted to the server.






Postel                                                         [Page 13]

RFC 318                     Telnet Protocol                   April 1972


      Example:

      In another case, a using site has decided that it is convenient to
      accumulate four characters at a time and transmit them to the
      serving site, unless an end of line signal is observed, in which
      case the end of line sequence is sent preceded by whatever number
      of characters have been accumulated (presumably three or less).
      In the same debugging application, the address is such that the
      end does not correspond with the four character buffer
      demarcation.  The user should have the ability to enter a code for
      "transmit immediately" in place of the end of line signal in order
      to preserve neat formatting, and expect the address to be sent to
      the serving site.

   Telnet Signals have been discussed and those introduced to date are
   probably sufficient for an implementation of Telnet ASCII convention.

Terminology

   ASCII          - The USASCII character set as defined in NIC # 7104.
                    In Telnet Protocol, where eight bit codes are used
                    the lower half of the code set is defined to be
                    ASCII.

   echoing        - The display of a character entered is called echoing.
                    There are two modes in which this happens.  If
                    the device used to enter characters displays the
                    character before (or as) it transmits the character
                    to the computer the echoing mode is called "local
                    echo."  If, on the other hand, the device transmits
                    the entered character to the computer without
                    displaying it and the computer then transmits a
                    character to the device for the echo display, this
                    echoing mode is called "remote echo."

   character mode - In this mode of operation Telnet transmits each
                    character as soon as possible.  Generally speaking,
                    character mode is used when all of the using terminal,
                    using system, and serving system are operating
                    in a remote echo mode.  The echos to the user
                    entered characters are transmitted from the serving
                    system (i.e., over the network).

   line mode      - In this mode of operation Telnet transmits groups
                    of characters which constitute lines.  Generally
                    speaking, this mode is used when one or more of
                    the using terminal, using system, or serving




Postel                                                         [Page 14]

RFC 318                     Telnet Protocol                   April 1972


                    system is operating in a local echo mode.  The
                    echos to the user entered characters are not
                    transmitted over the network).

   full duplex    - This term indicates a transmission procedure using
                    a four wire connection, which permits simultaneous
                    transmission in both directions.

   half duplex    - This term indicates a transmission procedure using
                    a two wire connection, which requires that data be
                    transmitted in only one direction at at time.

   Note that half duplex devices usually are also local echo but that
   full duplex devices may be either local echo or remote echo.

IV.  PROPOSED CHANGES TO TELNET PROTOCOL

   The changes suggested here are not my ideas, thus the presentation may
   be faulty.  I welcome RFC or other communication suggesting other
   changes or better arguments for and against these changes.

Echoing

   It is proposed to delete from Telnet the control signals ECHO, NOECHO,
   and HIDE YOUR INPUT.  For Server systems which do not provide echoing,
   these commands are useless.  For server systems which do provide
   echoing experience has shown that the control is most effectively
   provided by server system commands.

Data Types

   It is proposed to delete all mention of data types from Telnet.
   Either the character stream is ASCII or its not a Telnet
   communication.  If it is really necessary to change the data type, a
   command in ASCII could be sent in the data stream.

Minimum Implementation

   It is proposed that the minimum implementation require the user Telnet
   to allow the user to send and the server Telnet to correctly process
   all the Telnet control signals.










Postel                                                         [Page 15]

RFC 318                     Telnet Protocol                   April 1972


   The  work on Telnet Protocol has involved many people.  This document
   is taken from RFC's #139 and #158 by Tom O'Sullivan.  Others who
   have served on committees are:

                    Bob Bressler           MIT-DMCG

                    Will Crowther          BBN

                    Bob Long               SDC

                    Alex McKenzie          BBN

                    John Melvin            SRI-ARC

                    Bob Metcalfe           MIT-DMCG

                    Ed Meyer               MIT-Multics

                    Tol O'Sullivan         Raytheon

                    Mike Padlipsky         Mit-Multics

                    Jon Postel             UCLA-NMC

                    Bob Sundberg           Harvard

                    Joel Winett            LL

                    Steve Wolfe            UCLA-CCN







        [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Kelly Tardif, Viaginie 10/99]













Postel                                                         [Page 16]