rfc139.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      T. O'Sullivan
Request for Comments: 139                                       Raytheon
NIC: 6717                                                     7 May 1971


                     Discussion of TELNET Protocol


   The attached discussion is an extension of RFC 137, NIC #6717, and is
   presented to provide useful background to designers and implementers
   to help them interpret the proposed Protocol and evaluate it in
   preparation for further discussion at the Atlantic City meetings.

   While the views in the discussion represent those of various TELNET
   committee members, they should not be interpreted as being the agreed
   view of committee.  They are the author's understanding of some of
   the arguments and background to the PROTOCOL proposed in the TELNET
   PROTOCOL recommendations.

   *  See Footnotes to attached discussion for changes to RFC 137.

Discussion of TELNET PROTOCOL

   The use of a standard, network-wide, intermediate representation of
   terminal code between sites eliminates the need for using and serving
   sites to keep information about the characteristics of each other's
   terminals and terminal handling conventions, but only if the user,
   the using site, and the serving site assume certain responsibilities.

      1. The serving site must specify how the intermediate code will be
         mapped by it into the terminal codes that are expected at that
         site.

      2. The user must be familiar with that mapping.

      3. The using site must provide some means for the user to enter
         all of the intermediate codes, and as a convenience, special
         control signals, as well as specify for the user how the
         signals from the serving site will be presented at the user
         terminal.

   Other schemes were considered but rejected.  For example, a proposal
   that the using site be responsible to transmit to and from the code
   expected by the serving site was rejected since it required that the
   using site keep tables of all serving site codes and provide mapping
   for each case.  The information would require constant maintenance as
   new hosts were added to the network.




O'Sullivan                                                      [Page 1]

RFC 139              Discussion of TELNET Protocol            7 May 1971


   Since it is not known how the current or future sites will specify
   the mapping between the network-wide standard code (7 bit ASCII in an
   8 bit field) and the codes expected from their own terminals, it
   seems necessary to permit the user to cause every one of the 128
   ASCII codes, plus (for full user power) selected control signals
   (either of a TELNET control nature, or of a special terminal nature
   such as break or attention).

   There was strong feeling about the importance of the user/system
   interface at the using site, but equally strong feeling that this
   problem is one of local implementation and should reflect the using
   site installation philosophy rather than the subject to network-wide
   standards.  Some topics of consideration in this area are:

      1. How to represent special graphics, not available at the using
         site, at the user's terminal.

      2. Treatment of upper/lower case problem on TTY 33 and 35.

         a. Representing lower-case output.

         b. Providing users with shift and shift lock signals.

      3. Incorporating editing capability in TELNET.

      4. Extending user options in Network mode not available to local
         users,
         e.g., hold output

               kill print

      5. Permit users to specify how keyboard input is to be translated,
         e.g., let a character from the terminal cause a specified
         string to be sent by the user's TELNET.

   In early discussions, there was pressure to get a simple statement of
   protocol out early to permit early use of selected systems.  The
   counter pressure to provide a richer set of protocol in the first
   release was also present.  Work started in the direction of the
   latter, but the complexities introduced were not necessary for early
   use of the network.  The proposed solution to the TELNET protocol
   problem seems to provide a mechanism for a minimum implementation (to
   be discussed later) while providing a basis for developing richer
   sets of protocol for present and future use in terminal applications,
   process-process communications, and use by other conventions to pass
   data or control information.





O'Sullivan                                                      [Page 2]

RFC 139              Discussion of TELNET Protocol            7 May 1971


   The understanding that ASCII be used as a network-wide code has been
   established for some time.  Its use in TELNET provided a problem with
   respect to the limitation of a maximum character set of 128.  Some
   systems provide for more than this number in their operation, and
   therefor, as serving sites cannot map on a one for one basis.

   Each such serving site could probably provide a reasonably useful
   character set, including all system control signals, by mapping 128
   of its codes and just not provide a network user access to the other
   codes.  However, any character left out might later be used in a
   major application at that site as a special control signal.  This
   could result in denying network users the facility offered by that
   application.  Serving sites are, therefor, encouraged to provide a
   full mapping between the ASCII code and the code used on the serving
   system.

   The ASCII code for ESC (known to some as ALT MODE) has been selected
   as an escape [1].  For each serving site character not mapped on a
   one for one basis, the serving site can specify an escape character
   or string of escape characters (preferably a printable graphic) to
   represent it.  Thus, the user could enter the full set of serving
   site code from any network terminal operating through the Network
   Virtual Terminal (NVT) ASCII convention.  The serving site, in
   generating output directed at the user's terminal, would be expected
   to map out such a character and transmit the appropriate ESC
   character or string of ESC characters.

      Example: A serving site, whose normal code is EBCDIC, has
      specified that cent ([5]) has not been mapped on a one for one
      basis and that to transmit the character, users must enter ESC
      followed by C.  At a using site, the TELNET implementers have
      decided to try to print out all ESC characters using \ to indicate
      ESC.  On receipt of the representation for cent, the user would
      see \C on his print-out.

   The representation of the end of a physical line at a terminal is
   implemented differently on network HOSTS.  For example, some use a
   return (or new line) key, the terminal hardware both returns the
   carriage or printer to start of line and feeds the paper to the next
   line.  In other implementations, the user hits carriage return and
   the hardware returns carriage while the software returns to the
   terminal a line feed.  The network-wide representation will be
   carriage return followed by line feed.  It represents the physical
   formatting that is being attempted, and is to be interpreted and
   appropriately translated by both using site and serving site.






O'Sullivan                                                      [Page 3]

RFC 139              Discussion of TELNET Protocol            7 May 1971


      Example:  A Multics user is working, through the network, on some
      serving site HOST.  In the course of the session, the user has
      numerous occasions to hit New Line on his Mod 37 TTY.  Each time
      the Multics system is awakened by a New Line interrupt, the line
      of buffered characters is passed to TELNET where it is scanned for
      special characters.  If none is found, carriage return followed by
      line feed is inserted where New Line was entered, and the line is
      turned over to the NCP for transmission.  When the TELNET finds
      the carriage return line feed sequence in the data stream coming
      from the serving site, the two characters are replaced with New
      Line code and sent to the terminal.

   The decision to have the assumed condition for echo be that the using
   site will provide any echo necessary for its terminals was taken
   because of the difficulties faced by some installations that cannot
   turn off their echo or that have terminals that print locally as a
   result of key strokes.  Serving sites could take the position "let
   the user turn my echo off", but this seems an unnecessary burden on
   the user.  In addition, some serving sites may choose not to supply
   any echo service, in which case the no echo assumption will supply a
   network-wide condition, while other assumptions would give a mixed
   starting connection. [2]

   The convention of using "I ECHO", "YOU ECHO" seems to fill both the
   requirements for dynamic echo control and for a minimum
   implementation of TELNET Protocol. [3]  An agreed-upon exchange to
   pass echo control (i.e., two sites exchange the I ECHO/YOU ECHO
   codes) results in passing the control from one site to the other.

      Example:  A serving site is exchanging control information with
      the USER in an area where the serving system asks for pass word
      and wants to suppress the printing of the pass word at the using
      site's user terminal. (In this case, the using site has the
      ability to control the print capability at the user's terminal.)
      Using site has been echoing to the user's terminal.

         Serving Site to Using Site (--->)

            I ECHO

         Using Site to Serving Site (<---)

            YOU ECHO

         --->Pass word:

         <--- (User enters password at terminal)




O'Sullivan                                                      [Page 4]

RFC 139              Discussion of TELNET Protocol            7 May 1971


         ---> (No echo sent)

         ---> YOU ECHO

         <--- I ECHO

      After the exchange, the original normal condition is re-
      established.  If the using site did not have dynamic echo control
      installed in its TELNET implementation, the serving site would
      have signaled I ECHO several times, received no response, and
      assumed that the using site could not comply proceeding to call
      for the pass word without the normal protection of inhibiting
      print.

   TELNET control signals are of two types: one that results in
   transmission of signals down the network to a receiving site; the
   other intended for the user/process site only.  The latter type will
   be discussed later.  So far, we have discussed the former type,
   specifically dealing with echo control.

   The use of ESC should not be considered a TELNET-wide standard, but a
   convention limited to the 7 bit ASCII mode of transmission.  Other
   conventions, to be incorporated later, may include binary
   transmission, EBCDIC, etc.  Presumably, each will have its own
   convention for an escape character to extend its code set.

   Since it is expected that conventions other than ASCII will be
   implemented under TELNET, a code to indicate a DATA TYPE representing
   each set of conventions will be employed.  The control code X'AO' has
   been selected to represent the ASCII convention in TELNET.  Since a
   number of applications may wish to transmit transparently (i.e., 8
   bit binary data), X'Al' is being reserved for that purpose.  The
   TELNET control code X'A2' is reserved for an expected set of EBCDIC
   conventions.  The DATA TYPE is expected as the first byte of data
   over a TELNET connection.  Minimum implementations will be aided by
   providing a default.  That is, if the first byte over a connection
   has the high order bit set as zero, then the transmission has begun
   in ASCII mode.

   Each set of conventions, i.e., each DATA TYPE will be expected to
   have a convention for that DATA TYPE to signal that it is returning
   to control mode.  This return may be for the purpose of making use of
   an existing control codes or to change data type.  X'88' is used [4].

      Example:  At the using site, a terminal has a special device on it
      (e.g., plotter, laboratory instrument, control box, etc.) that is
      controlled by binary code in 8 bit bytes.  The terminal uses a
      special "enter" code that routes signals to the device and cuts



O'Sullivan                                                      [Page 5]

RFC 139              Discussion of TELNET Protocol            7 May 1971


      off printing at the terminal until a special "leave" signal is
      received from the driving process.  The driving process in this
      case is at a remote serving site.  It is assumed in this example
      that a DLE convention is used for transparent transmission, a
      single DLE signal representing return to control.  Normal
      transmission has been in ASCII.

      Driving Process (at Serving Site) to Using Site) ---->

         X'88'X'A1'

      Using Site to Serving Site <----

         X'88'X'88'

      ----------->

         ENTER code...8 bit binary bytes...

      Using Site TELNET to Terminal |
                                    |
                                    V

         Enter code...8 bit binary bytes...