doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc97.txt b/doc/rfc/rfc97.txt
new file mode 100644
index 0000000..79f0a6c
--- /dev/null
+++ b/doc/rfc/rfc97.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+NETWORK WORKING GROUP                                           NIC 5740
+Request for Comments #97                                  John T. Melvin
+                                                       Richard W. Watson
+                                                                 SRI-ARC
+                                                        15 February 1971
+
+
+               A FIRST CUT AT A PROPOSED TELNET PROTOCOL
+
+1    Introduction
+
+       This paper describes a first cut at a proposed Telnet protocol.
+   _Telnet_ is a process which runs at a _user's_ _site_ and allows him
+   to utilize a typewriter-like terminal to gain interactive service
+   from a remote _server_ _site over the ARPA Network.  This paper was
+   motivated by our need to set specifications for a protocol which
+   would allow online access to the Network Information Center (NIC).
+   The Online System running at the Network Information Center we will
+   refer to as NLS(NIC).  On thinking about the problem of setting
+   specifications for access to the NIC, we have tried to generalize our
+   ideas so that they would apply to other systems with characteristics
+   similar to ours.  We realize that there are other terminal hardware-
+   software disciplines which might find it difficult to conform to all
+   the requirements stated here and, therefore, the final Telnet
+   protocol will differ from the one stated in this NWG/RFC.  One
+   conclusion that we may all have to come to is that connection with
+   the network may force us toward a more standard way of handling
+   terminals and their character streams in our monitors and terminal
+   control hardware.  In the meantime, we hope that this paper and
+   others on the same subject that may be in process, coupled with a
+   survey of hardware-software requirements at each site by a NWG
+   subgroup, can result in an initial standard network Telnet protocol
+   being agreed upon quickly, as it is important to get users onto the
+   network as soon as possible so that interactive network usage can
+   indicate further directions for network protocol evolution.  Next we
+   outline some design problems, then propose some conventions to solve
+   these problems for access to systems such as the NLS(NIC) and
+   indicate some problems needing further study.  The proposed
+   conventions for access to the NLS(NIC) are summarized in Appendix A.
+
+2    Some Design Problems
+
+   2A.  Basic Assumption
+
+        The function of the Telnet process is to make a terminal at a
+   user site appear over the network as logically equivalent to a
+   terminal "directly" connected to the server site.  There are a number
+   of implications of this basic function.
+
+
+
+Melvin & Watson                                                 [Page 1]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+      i) The user should be able to cause generation of all codes which
+      a server system terminal can generate.  With respect to the
+      Network Information Center and some other sites it would seem a
+      reasonable requirement to have keying conventions so that the user
+      can generate all 128 ASCII character codes as input to the
+      network.  Other sites with different character codes may require a
+      Telnet process to provide those codes to the network.
+
+      ii) The user should be able to escape back to his local system or
+      escape from the server process to the server system.
+
+      iii) The Telnets  of line-at-a-time systems should be able to work
+      with character-at-a-time systems and line-at-a-time systems and
+      Telnets  of character-at-a-time systems should be able to work
+      with line-at-a-time and character-at-a-time systems.
+
+   2B   Echo Control
+
+        We use the term echo control rather than the terms half duplex
+   or full duplex because the Telnet connection is in reality full
+   duplex with respect to network transmissions.  Three terminal cases
+   need to be considered.
+
+      Case 1 - Character-at-a-time serving site echoed
+
+      Case 2 - Character-at-a-time user site echoed
+
+      Case 3 - Line-at-a-time user site echoed
+
+   Some serving sites may be able to operate with all three cases and
+   some convention is required to set the mode.  Strictly speaking, what
+   characters are echoed for what keys struck is of no concern to the
+   serving site, although one would like to try to minimize differences
+   in typescript as it appears to the user.
+
+   2C   Format Control Characters
+
+        The format control characters of horizontal tab (HT), vertical
+   tab (VT), form feed (FF), line feed (LF), and carriage return (CR),
+   need to be handled in a consistent way for Cases 2 and 3 above.  With
+   Case 1 above, the situation is simplified.
+
+   2D   Network Message Boundaries
+
+        The NCP to NCP protocol was specified with the goal of having
+   the network message boundaries being invisible to the user processes.
+   It would be good if this goal could be maintained, but it may be
+   difficult with some line-at-a-time systems.
+
+
+
+Melvin & Watson                                                 [Page 2]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+   2E   An Implementation Convention
+
+        ConVentions to solve the above problems are most simply
+   established if we assume that the character stream received from a
+   Telnet process by the server site is entered into that point in the
+   server monitor where character input from "direct1y" connected
+   terminals is entered and output from the server process is entered
+   into the monitor point where normal character output is entered.  The
+   server NCP receives its input at the point where normal monitor
+   character output is obtained.  In other words, the server process
+   would obtain its input from the server monitor character buffers and
+   send its output to these buffers rather than obtainIng input directly
+   from NCP buffers or outputting to NCP buffers.
+
+        The Telnet process, on the other hand, would obtain and send
+   character streams directly from or to its local NCP.
+
+        Other situations exist where the user processes at both ends
+   communicate directly with the NCP.  Therefore, we would recommend
+   that both modes of connection (user process-monitor-NCP, or user
+   process-NCP) be available for communication between the NCP and a
+   user process.  These modes would be set under program control by the
+   user process.  The initial network convention during the login
+   procedure and until changed by the server process would be to obtain
+   characters from and send characters to the monitor.  The server NCP
+   communicates with the monitor also.  The scheme is illustrated in
+   Figure 1.
+
+        The motivation for such flexibility may be clearer from the
+   discussion below.
+
+3    Proposed Telnet Conventions
+
+   3A   The server site is to assume initially that echoing is performed
+   by a user site process until explict1y commanded otherwise.  If the
+   user site can send character-at-a-time, then after connection and
+   login have been established, tne user could switch Lo server-site-
+   echo by command to the server site and then command (invisible to the
+   server site) his local Telnet to change its echo mode also.
+
+   3B   The server process is to assume it will receive the same
+   character set which terminals "directly" connected to it can
+   generate.  (We recommend at least 128 character ASCII.)  The user's
+   Telnet may have to recognize two-character sequences to enable
+   generation of both upper and lower-case codes and the control codes.
+   We recommend that the user be able to set either upper or lower case
+   as the default case for single case terminals and be able to specify
+   a case shift character.  The user should also be able to specify a
+
+
+
+Melvin & Watson                                                 [Page 3]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+   character to indicate that the next character struck is to be
+   converted to the appropriate control character code.  This latter
+   convention enables control codes directly generated at the terminal
+   to be recognized by the user's system thus enabling escape to the
+   user system.  Creating a convention allowing all control codes to
+   enter the network and allowing output of the network to feed into the
+   server monitor before entering the server process, gives a simple
+   mechanism for generating an escape to     many existing systems.
+   (The problem is more complicated than this for some systems and we
+   discuss it further below.)
+
+   3C   We recommend that network standards be established for the
+   meaning of local echoes of HT, VT, and FF or a convention to be
+   established for sending the meaning of these characters to the server
+   process.  The NLS(NIC), for example, needs to keep track of the
+   position of the print head and in the absence of such conventions
+   will convert these character codes to spaces and line feeds.  This
+   means that the appearance of the page on output may differ from the
+   appearance on input.  It would be helpful to the user if his page on
+   output could be formatted as it appeared on input.
+
+   3D   LF characters would be handled as if they were generated by
+   hitting the line feed key on a terminal "directly" connected to the
+   server system.
+
+   3E   The carriage return (CR) character can be the source of
+   considerable difficulty.  For example, on input, different systems
+   and the same system at different times, can echo and transmit
+   different codes to the terminal and the user process.  Some monitor
+   systems echo nothing, just a CR, or a CRLF.  Some systems transmit a
+   CR, CRLF, or end of line code (EOL) to the user process.  The user
+   process may control the echo or add to it.  Given the combinations
+   which can exist at each end of the network connection and with
+   respect to each other, confusion can exist unless we assume the
+   definition of 2A and the implementation convention of 2E.  These
+   assumptions imply that when a CR is struck, a CR gets sent over the
+   network.  If the user monitor system or terminal control hardware
+   converts a CR to a CRLF or EOL, then the Telnet program must convert
+   it back to a CR.  When the CR reaches the server monitor it will
+   handle it properly for the server process.
+
+        When echoing is handled by the server system, the proper code or
+   codes will be echoed.  The user Telnet on receiving a CRLF can pad it
+   with the proper nulls to handle carriage movement timing for a
+   particular terminal.
+
+        When echoing is handled by the user system it would be ideal if
+   the user's Telnet or system used the same echo convention as the
+
+
+
+Melvin & Watson                                                 [Page 4]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+   server system would.  This means that either the Telnet must have a
+   table of echo conventions for the various systems to which it can
+   connect, or that it can obtain this information from the server
+   system or process, or vice versa.
+
+        For an initial Telnet protocol this is probably not necessary.
+   The user system can default and echo a CRLF on each CR received.
+   This default should be satisfactory for all the situations we are
+   familiar with and for the NIC.
+
+   3F   For communication from character- and line-at-a-time systems,
+   the Telnet process may need to recognize a character (user
+   assignable) which we call end of stream (EOS).  This character is to
+   have the function defined in the following discussion.  The important
+   point is to distinguish end-of-stream as a network function and end-
+   of-line as a user or server system function.  Consider line-at-a-time
+   systems first.  We have not had much experience with line-at-a-time
+   systems, so what follows will need further study and clarification.
+   As we understand it, line-at-a-time systems recognize a character
+   such as CR or a break signal as the code to wake up the user process
+   and cause transmission to it of the line of text.  From the point of
+   view of NLS(NIC) it is important that the user be able to enter lines
+   of text each terminated by a CR where appropriate and at other times
+   to be able to enter text not terminated with a CR.  (A statement for
+   NLS(NIC) is a string of text of "arbitrary" length and need not have
+   CRs in it; on output the line is folded for the user at his (user
+   definable) page boundary.)
+
+        As an example of what is required, consider the case where the
+   user's system recognizes CR as end-of-line.  In this case the Telnet
+   would be awakened when a CR is received.  We would recommend that in
+   this case the CR code be literally entered into the Telnet output
+   buffer.  If a CR is preceded by an EOS character, then the CR should
+   not be placed in the Telnet output buffer.  Transmission through the
+   network can take place either when an EOS is received or
+   automatically when the Telnet output buffer fills.  Transmission to
+   character-at-a-time systems from line-at-a-time systems could require
+   the awkward striking of three keys to get one character through the
+   network.
+
+        Now consider transmission for a character-at-a-time system to a
+   server line-at-a-time system.  A similar problem to the one to be
+   described also exists between line-at-a-time systems.  Given the
+   definition of an EOS character different from CR, a line can be
+   buffered up until the EOS is received and then sent without the EOS.
+   How is the serving system to know that a line has been sent?  One way
+   would be for the serving NCP to recognize message boundaries.  This
+   convention would violate a design goal.  Another way would be for the
+
+
+
+Melvin & Watson                                                 [Page 5]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+   user Telnet to request its NCI to send an INS command.  The sending
+   of INS type of control commands might introduce race conditions in
+   the network and should be investigated before their use with a Telnet
+   process is established.  Since some of the line-at-a-time systems we
+   know have special hardware that recognizes the end-of-line signal, we
+   need some way to be compatible with this hardware using software
+   control signals.  We leave this problem for further NWG subgroup
+   study.
+
+   3G   We now come back to the problem of interrupting or escaping in
+   the remote server system.  In systems which do not lock out the input
+   keyboard when output is going on, the mechanisms and conventions
+   outlined above would seem adequate unless a special break signal is
+   the escape signal.  This latter case requires more study.  In systems
+   which allow no input while output is occurring, one may have to live
+   with the consequences of such a terminal discipline and be prepared
+   to wait until output stops before an escape code can be sent.  If the
+   keyboard is locked and an escape break signal can be sent to the
+   user's system, it can prevent output from going to the terminal, but
+   must be prepared to continue receiving it from the server site until
+   the user can inform his Telnet process to send an interrupt or escape
+   signal to the server site.  Again this is a problem for further
+   study.
+
+        The Online System of the Network Information Center operates on
+   a character-at-a-time monitor system and the conventions established
+   in this paper are adequate for access to it.  These conventions are
+   summarized in Appendix A.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melvin & Watson                                                 [Page 6]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+APPENDIX A
+
+   NETWORK CONNECTION PROTOCOL TO SRI-NETWORK INFORMATION CENTER
+
+   1    Initial Connection Protocol
+
+       Connection establishment to NIC is identical to that presented in
+   Section II of NWG/RFC 80 NIC (5608,); it is reproduced here:
+
+   Telnet contacts NIC
+
+   NIC <- user site
+
+        RTS <us> <l> <p>
+
+             NIC logger is socket 1
+
+   user site <- NIC
+
+        STR <l> <us> CLS <l> <us>
+
+             if accepted
+
+        CLS <l> <us>
+
+             if rejected
+
+   assuming NIC accepts
+
+   user site <- NIC
+
+        STR <ss+l> <us>
+
+        RTS <ss> <us+l> <q>
+
+             NIC receives text thru local socket ss from remote
+             socket us+l via link q
+
+   assuming user site accepts
+
+        NIC <- user site
+
+             STR <us> <ss+l>
+
+             RTS <us+l> <ss> <r>
+
+                  NIC sends text to remote socket us thru local socket
+                  ss+l via link r
+
+
+
+Melvin & Watson                                                 [Page 7]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+                    .
+                    .
+                    .
+
+        user site <- NIC
+
+             ALL <q> <space>
+
+                    .
+                    .
+                    .
+
+        NIC <- user site
+
+             ALL <r> <space>
+
+   2    Connection Breaking Protocol
+
+        A CLS trade is made between the NCPs for each of the two
+   connections as per Document #1 NIC (5143,).
+
+           We may decide to put a time-out into the NIC connections such
+      that no interaction for some (as yet unspecified) "reasonable"
+      length of time will result in a CLS-out of the connections being
+      initiated by NIC.
+
+   3    Third Level Protocol
+
+        The first 8 bits received by NIC thru socket ss should be the
+   message data type designating that an 8-bit ASCII stream follows, as
+   per NWG/RFC #63, NIC (4963,).
+
+         I.e., the first 8 bits are 00000001
+
+        The first 8 bits received by Telnet thru socket us will also
+   indicate a message data type of l.  Each network message should have
+   an integral multiple of 8 bits.  If a network standard is established
+   different from the suggestion of NWG/RFC #63, NIC (4963,), then we
+   would change this protocol to conform.
+
+         NIC will have NCP-generated interrupts disabled, i.e.,
+
+            INR will be ignored
+
+            INS will not be sent to the remote host
+
+
+
+
+
+
+Melvin & Watson                                                 [Page 8]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+   4    NLS(NIC) Character Conventions of Interest to Telnet
+
+        Echoing can either be under control of NIS(NIC) or under control
+   of the user site.  When we refer to echoing below, we mean under
+   control of NLS(NIC).  When echoing is handled by the user site we
+   would expect the user to set the NLS(NIC) output conventions to
+   conform to the echoing conventions at his site.  NLS(NIC) assumes
+   echoing is handled by the user site unless explicitly commanded
+   otherwise.
+
+      Format affecting control characters
+
+         horizontal tab
+
+                 spaces to next (user definable) stop on both echoing
+            and output.
+
+                 if during literal input, enters file as ASCII '11.
+
+         form feed
+
+                 carriage return and (user definable) appropriate number
+            of line feeds on echo and output.
+
+                 If during literal input, enters file as ASCII '14
+
+         vertical tab
+
+                 carriage return and (user definable) appropriate number
+            of line feeds on echo and output
+
+                 if during literal input, enters file as ASCII '13
+
+         carriage return
+
+                 carriage return followed by line feed on echo and
+            output
+
+                 if during literal input, enters file as EOL (see below)
+
+         line feed
+
+                 line feed on echo and output
+
+                 enters file as ASCII '12 on literal input
+
+         EOL (end of line)
+
+
+
+
+Melvin & Watson                                                 [Page 9]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+                 presently ASCII code '37
+
+                 carriage return followed by line feed on echo and
+            output
+
+                 if during literal input, enters file as ASCII '37
+
+                 If the user's system automatically appends a LF to a CR
+            before sending it to Telnet or converts CR to some EOL code
+            not ASCII '37, we would expect Telnet to send NLS(NIC) just
+            a CR or ASCII '37.  If we receive CRLF, then on output we
+            will send CRLFLF.
+
+   5 NLS(NIC) Interrupt Attention Convention
+
+       A (user definable) ASCII code in the text input stream is used to
+   abort the executing process and return control to the main NLS(NIC)
+   command processor.
+
+         This code is presently DEL (ASCII '177).
+
+           Escape to the NIC monitor:  No escape is required as all
+      operations needed for use of the NIC can be performed within
+      NLS(NIC).
+
+           Character Set:  We strongly recommend that the Telnet process
+      be able to generate by some set of keying conventions all 128
+      ASCII codes.  Use of NLS(NIC) will probably feel most comfortable
+      from a device with upper and lower case graphics, although we can
+      provide service to single case devices.  We can provide a useful
+      service if the full ASCII set cannot be sent, but would like to
+      minimize the special cases we have to handle.  Sites which cannot
+      provide the full ASCII set should contact us.
+
+         +----+                      |
+         |    |        Server        |
+         |    |        Program       |
+         |    |                      |
+         +----+                      |
+          ^ |                        |
+          | v                        |
+         +----+        Terminal      |
+         |    |        control       |
+         |    |        software      |    SERVER
+         |    |        and           |     SITE
+         +----+        possibly      |
+          ^ |          hardware      |
+          | v                        |
+
+
+
+Melvin & Watson                                                [Page 10]
+
+RFC 97                  Proposed Telnet Protocol           February 1971
+
+
+         +----+                      |
+         |    |                      |
+         |    |        NCP           |
+         |    |                      |
+         +----+                      |
+          ^ |                        |
+          | v                        |
+
+          . .
+          . .                                            Figure 1 -
+          . .
+          . .                                        Telnet Connection
+
+          ^ |
+          | v
+         +----+                      |
+         |    |                      |
+         |    |        NCP           |
+         |    |                      |
+         +----+                      |
+          ^ |                        |
+          | v                        |
+         +----+                      |
+         |    |                      |
+         |    |        Telnet        |
+         |    |                      |
+         +----+                      |
+          ^ |                        |    USER
+          | v                        |    SITE
+         +----+        Terminal      |
+         |    |        control       |
+         |    |        hardware-     |
+         |    |        software      |
+         +----+                      |
+          ^ |                        |
+          | v                        |
+         +----+                      |
+         |    |        User          |
+          \   |        terminal      |
+           \--+                      |
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [   into the online RFC archives by Tony Hansen 08/08   ]
+
+
+
+
+
+
+
+Melvin & Watson                                                [Page 11]
+