[ih] What does TELNET stand for?

[the keyboard of geoff goodfellow]

"Telecommunications Network"

EXCERPTing from Spring Joint Computer Conference, 1972:
https://dl.acm.org/doi/pdf/10.1145/1478873.1478908


*Function-oriented protocols for the ARPA Computer Network*by STEPHEN D.
CROCKER, JOHN F. HEAFNER, ROBERT M. METCALFE, JONATHAN B. POSTEL

... USE OF REMOTE INTERACTIVE SYSTEMS

The application which currently dominates ARPANET activity is the remote
use of interactive systems. A Telecommunications Network (TELNET) protocol is
followed by processes cooperating to support this
application.8

A user at a terminal, connected to his local HOST, controls a process in a
remote HOST as if he were a local user of the remote HOST. His local HOST
copies characters between his terminal and TELNET connections over the
ARPANET. We refer to the HOST where the user sits as the using HOST, and to
the remote HOST as the serving HOST. See Figure 4.

At the using HOST, the user must be able to perform the following functions
through his TELNET
user process ("user-TELNET"):

1. Initiate a pair of connections to a serving HOST,
2. Send characters to the serving HOST,
3. Receive characters from the serving HOST,
4. Send a HOST-HOST interrupt signal,
5. Terminate connections.

The user-TELNET needs to be able to distinguish between (1) commands to be
acted on locally and (2)
input intended for the serving HOST. An escape character is reserved to
mark local commands. Conventions
for the ARPANET Terminal IMP (TIP) userTELNET are typical.9

In most using HOSTs, the above functions are provided by a user-TELNET
which is a user-level program.
A minimal user-TELNET need only implement the above functions, but several
additional support functions are often provided (e.g., saving a transcript
of a session in a local file, sending a file in place of user typed input,
reporting whether various HOSTs are or have been up). In the serving HOST
it is desirable that a process controlled over the ARPANET behave as it
would if controlled locally. The cleanest way to achieve this goal is to
generalize the terminal control portion (TCP) of the operating system to
accept ARPANET terminal interaction. It is unpleasant to modify any portion
of a working computer system and modification could be avoided if it were
possible to use a non-supervisor process (e.g., "server-TELNET" or
"LOGGER") to perform the job creation, login, terminal input-output,
interrupt, and logout functions in exactly the same way as a direct console
user. Prior to the development of the ARPANET, no operating system provided
these functions to non-supervisor processes in anywhere near the required
completeness. Some systems have since been modified to support this
generalized job control scheme. See Figures 5 and 6. Efforts to standardize
communications in the TELNET protocol focused on four issues: character
set, echoing, establishing connections, and attention handling. The chosen
character set is 7-bit ASCII in 8-bit fields with the high-order bit off.
Codes with the highorder bit on are reserved for TELNET control functions.
Two such TELNET control function codes are the "long-space" which stands
for the 200 millisecond space generated by the teletype BREAK button, and
the synchronization character (SYNCH) discussed below in conjunction with
the purpose of the TELNET interrupt signal. Much controversy existed
regarding echoing. The basic problem is that some systems expect to echo,
while some terminals always echo locally. A set of conventions and signals
was developed to control which side of a TELNET connection should echo. In
practice, those systems which echo have been modified to include provision
for locally echoing terminals. This is a nontrivial change affecting many
parts of a serving HOST. For example, normally echoing server HOSTs do not
echo passwords so as to help maintain their security. Terminals which echo
locally defeat this strategy, however, and some other protection scheme is
necessary. Covering the password with noise characters is the usual
solution.

The HOST-HOST protocol provides a large number of sockets for each HOST,
but carefully refrains from
specifying which ones are to be used for what. To establish communication
between a user-TELNET and a
server-TELNET some convention is required. The Initial Connection Protocol
(ICP)10 is used:

1. Connection is initiated from a user-TELNET's
receive socket to a serving HOST's socket 1
(a send socket).
2. When the initial connection is established, the
serving HOST sends a generated socket number
and closes the connection. This socket number
identifies an adjacent socket pair at the serving
HOST through which the user-TELNET can
communicate with a server-TELNET.
3. TELNET connections are then initiated between the now specified pairs of
sockets. Two
connections are used to provide bi-directional
communication.

Note that socket 1 at the serving HOST is in use only long enough to send
another socket number with which to make the actual service connections.

One of the functions performed by a terminal control program within an
operating system is the scanning of an input stream for attention
characters intended to stop an errant process and to return control to the
executive. Terminal control programs which buffer input sometimes run out
of space. When this happens to
a local terminal's input stream, a "bell" or a question mark is echoed and
the overflow character discarded, after checking to see if it is the
attention character. See Figure 7. This strategy works well in practice,
but it depends rather strongly on the intelligence of the human user, the
invariant time delay in the input transmission system, and a lack of
buffering between type-in and attention checking. None of these conditions
exists for interactive traffic over the net: The serving HOST cannot
control the speed (except to slow it down) or the buffering within the
using HOST, nor can it even know whether a human user is supplying the
input. It is thus necessary that the terminal control program or
serverTELNET not, in general, discard characters from a network input
stream; instead it must suspend its acceptance of characters via the
HOST-HOST flow control mechanism. Since a HOST may only send messages when
there is room at the destination, the responsibility for dealing with too
much input is thus transferred back to the using HOST. This scheme assures
that no characters accepted by the using HOST are inadvertently lost.
However, if the process in the serving HOST stops accepting input, the
pipeline of buffers between the userTELNET and remote process will fill up
so that attention characters cannot get through to the serving executive.
In the TELNET protocol, the solution to this problem calls for the
user-TELNET to send, on request, a HOST-HOST interrupt signal forcing the
server-TELNET to switch input modes to process network input for attention
characters. The serverTELNET is required to scan for attention characters
in its network input, even if some input must be discarded while doing so.
The effect of the interrupt signal to a server-TELNET from its user is to
cause the buffers between them to be emptied for the priority processing of
attention characters. To flip an attention scanning server-TELNET back into
its normal mode, a special TELNET synchronization character (SYNCH) is
defined. When the serverTELNET encounters this character, it returns to the
strategy of accepting terminal input only as buffer space permits. There is
a possible race condition if the SYNCH character arrives before the
HOST-HOST interrupt signal, but the race is handled by keeping a count of
SYNCHs without matching signals. Note that attention characters are HOST
specific and may be any of 129 characters—128 ASCII plus "long space"—while
SYNCH is a TELNET control character recognized by all server-TELNETs. It
would not do to use the HOST-HOST signal alone in place of the signal-SYNCH
combination in attention processing, because the position of the SYNCH
character in the TELNET input stream is required to determine where
attention processing ends and where normal mode input processing begins.
[...]
https://dl.acm.org/doi/pdf/10.1145/1478873.1478908


On Fri, Aug 22, 2025 at 3:45 PM John Levine via Internet-history <
internet-history at elists.isoc.org> wrote:

> This question came up on another list.
>
> I have seen claims that it's Teletype Network or Telecommunications
> Network, which smells like acronym reverse engineering to me.
>
> Does it stand for anything?  Where did the name come from?
>
> R's,
> John
> --
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe:
> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>
>

-- 
Geoff.Goodfellow at iconia.com
living as The Truth is True