First Cut at a Proposed Telnet Protocol
RFC 97

Document Type RFC - Unknown (February 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 97 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
NETWORK WORKING GROUP                                           NIC 5740
Request for Comments #97                                  John T. Melvin
                                                       Richard W. Watson
                                                        15 February 1971


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
Show full document text