doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc139.txt b/doc/rfc/rfc139.txt
new file mode 100644
index 0000000..a37e4c4
--- /dev/null
+++ b/doc/rfc/rfc139.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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...
+
+      Terminal
+
+         Turn printer off, feed transparently to special device, look
+         for LEAVE signal
+
+      ------------>
+
+         8 bit binary bytes...LEAVE signal...single DLE
+         X'A0'
+
+      <-----------
+
+         X'88'X'88
+
+      ------------>
+
+      Message
+
+       |
+       |
+       V
+         8 bit binary data...LEAVE signal MESSAGE
+
+
+
+
+O'Sullivan                                                      [Page 6]
+
+RFC 139              Discussion of TELNET Protocol            7 May 1971
+
+
+      _Terminal_
+
+      During this sequence of exchanges - at the terminal, feed binary
+      data to special device until LEAVE signal is sensed, strip off
+      LEAVE signal, turn on printer and block data path to special
+      device, print MESSAGE at terminal.
+
+   There is a special control signal on some terminals that has no
+   corresponding bit pattern in ASCII, but is transmitted by a special
+   electrical signal.  This control signal is ATTN on a 2741 and BREAK
+   on a teletype.  The ASCII DATA TYPE in TELNET will use the code X'81'
+   to represent BREAK.  (There is a corresponding control signal for use
+   from serving sites to using sites for reverse break, and it is
+   assigned the code X'82').
+
+   Some systems treat the break as an extra code available for use in
+   conjunction with the data stream.  For example, one system uses break
+   as a special editing code meaning "delete the current line to this
+   point".  In these cases, the code may simply be inserted in the data
+   stream with no special additional action by the user.
+
+   Other systems use BREAK or ATTN in a special interrupt fashion, to
+   mean stop processing the application and give me the supervisor, or
+   cancel the present job, etc.  (Other systems use normal characters
+   for this purpose, such as "Control C".)  In these cases, because of
+   differences in the ways both serving and using sites operate, it is
+   necessary to take a route in addition to the normal TELNET data
+   stream to signal that the special control signal is imbedded in the
+   data stream.
+
+      _Examples-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 therefor,
+      arrival at the TELNET of bursts of characters, TELNET
+      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 fill up, and a control C get stuck
+   in the data stream that has been choked off.
+
+
+
+
+O'Sullivan                                                      [Page 7]
+
+RFC 139              Discussion of TELNET Protocol            7 May 1971
+
+
+   A similar problem could occur with the Multics or some IBM system as
+   a server.  The user at a using site gets into an output loop at the
+   serving site and wants to break the process without having to release
+   his TELNET connection.  The buffers clog the connection, transmission
+   is choked off, and the control C 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, control C, etc.) and follows it with an X'80'.
+   (The local instructions at using sites for accomplishing this may
+   differ from site to site.)
+
+      Using Site TELNET to Serving Site
+
+         Insert X'80' in Data Stream
+
+      Using Site TELNET to Using Site NCP
+
+         Send an INS
+
+      Sending Site NCP to TELNET Server
+
+         Look out, here she come
+
+      Serving Site TELNET
+
+         Does its special thing until it sees X'80' 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 to get the special
+   character.  When it sees X'80', it recognizes it as a SYNC character
+   and knowing that the special character has been passed on, strips the
+   X'80' from the data stream and returns to normal mode.
+
+   If the X'80' arrives before the INS, a counting scheme can keep the
+   activity appropriate to the serving site conditions.
+
+   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
+
+
+
+
+
+
+O'Sullivan                                                      [Page 8]
+
+RFC 139              Discussion of TELNET Protocol            7 May 1971
+
+
+   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.
+
+   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 control signalling from the
+   user to the using site.
+
+      _Examples_
+
+      A user on a line at a time system (Multics, System 360, GECOS,
+      etc.)  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 a memory 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 suppress the end of a line convention,
+      followed by a new line or return, and expect the location number =
+      to be transmitted immediately without an end of line sequence.
+
+      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 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 Carriage Return in order to preserve
+      neat formatting, and expect the address to be sent to the serving
+      site.
+
+      TELNET controls have been discussed and those introduced to date
+      are probably sufficient for an early implementation of TELNET
+      ASCII convention.  There will be a need to establish a mechanism
+      for the controlled assignment (on request by Network Sites), and
+      announcement of DATA TYPE and CONTROL codes.
+
+      It should be noted that some controls are network-wide TELNET
+      controls, while others are specific to the ASCII Data Type.  It
+      should be further recognized that some local control messages do
+      not require a corresponding network-wide code.
+
+
+
+O'Sullivan                                                      [Page 9]
+
+RFC 139              Discussion of TELNET Protocol            7 May 1971
+
+
+      While it is recognized that even a minimum implementation of
+      TELNET for a using site is expected to permit the user to send any
+      selected ASCII string (and only that string) to the serving site,
+      it is not necessary for a serving site to implement a full mapping
+      from ASCII to local code, nor is it necessary for either the using
+      or serving sites to implement all control codes.
+
+      _Example - Using Site_
+
+      A minimum implementation of the TELNET protocol for the using site
+      would permit ignoring (and stripping) any control signals from the
+      serving site since they would all either require agreement or
+      acknowledgement (e.g., DATA TYPE, ECHO CONTROL, etc.) or can be
+      ignored with no particularly harmful results (e.g., reverse
+      break).
+
+      _Example - Serving Site_
+
+      A minimum implementation of the TELNET protocol for the serving
+      site could provide one for one mapping for the most important 128
+      serving system controls and graphic signals, and ignore all
+      control signals.
+
+   It would be helpful if a minimally implemented receiving site, when
+   it recognizes an incoming control signal for which appropriate
+   reaction is not available, could respond with X'87' (The following
+   not implemented at this site) and follow it with the code just
+   received.
+
+   Whenever an ASCII TELNET connection is lost, it should be assumed
+   that the process at the other end of the connection has been quit,
+   aborted, failed, etc.  In this way, a minimum using site installation
+   can fail to implement the break and break synchronization, and have
+   the user rely on the using site local procedure for leaving a running
+   local process and returning to the supervisor to break a connection
+   to a remote serving site.
+
+      _Example_
+
+      User recognizes that he is caught in an output loop and wishes to
+      stop his user process at the serving site.  The serving site
+      requires a break, but the using site minimum implementation has
+      not made it available.  Even if it had, the INS was not
+      implemented and could not be used to unblock the input pipe.
+      Locally, the using site convention for leaving a process and
+      getting to supervisory level is to hit the attention key on the
+      2741 terminal.  The user does this and is passed to the supervisor
+      where he signals to release the TELNET connection.  The serving
+
+
+
+O'Sullivan                                                     [Page 10]
+
+RFC 139              Discussion of TELNET Protocol            7 May 1971
+
+
+      site, seeing that an ASCII TELNET connection has been lost,
+      assumes that the user is ended either normally or abnormally.
+      Serving site cancels the user's process.  The user tries again by
+      re-establishing the connection, logging in again, re-initiating
+      the process, etc.
+
+   Other conventions under TELNET may make quite different assumptions
+   about lost connections, and some may go as far as dynamic
+   establishing and releasing of connections.
+
+   The proposed TELNET ASCII implementation leaves much uncovered, but
+   seems to permit early simple implementation with varying levels of
+   capability, along with the capacity to expand in several ways to meet
+   others needs.
+
+   There is an important open question.  Should a PROTOCOL such as
+   TELNET provide the basis for extending a system to perform functions
+   that go beyond the normal capacity of the local system.  For example,
+   a local system may not provide functions such as Hold Output, Kill
+   Print, etc., but it could extend it for network purposes through
+   TELNET.  If so, to what extent should such extensions be thought of
+   as Network-wide standards as opposed to purely local implementations.
+
+Endnotes
+
+   [1] Please drop the (s) at the end of "character" in paragraph 3,
+   page 3, RFC 137, NIC #6714.
+
+   [2] Also make note that the starting assumption in the initial
+   exchange between using site and serving site will be that the using
+   site will (if necessary) provide echo and the serving site will not.
+
+   [3] Note: Please change RFC #137, NIC #6714, page 4 - Code X'85' to
+   read Reserved.
+
+   [4] Please note on page 4 of RFC 137 that the receipt of an X'88'
+   should be responded with by the receiver sending a double signal,
+   i.e., X'88'X'88' if the new DATA TYPE can be handled.
+
+   [5] Cent sign
+
+          [This RFC was put into machine readable form for entry]
+           [into the online RFC archives by Lorrie Shiota, 1/02]
+
+
+
+
+
+
+
+
+O'Sullivan                                                     [Page 11]
+