First Cut at a Proposed Telnet Protocol
RFC - Unknown
(February 1971; No errata)
||RFC Editor Note
RFC 97 (Unknown)
||Send notices to
NETWORK WORKING GROUP NIC 5740
Request for Comments #97 John T. Melvin
Richard W. Watson
15 February 1971
A FIRST CUT AT A PROPOSED TELNET PROTOCOL
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