RFC 318

Telnet Protocol 💖

🎀 Part 1 of 3! The Telnet control signals come next.

Okay bestie, let's get into RFC 318 🦋 It's called Telnet Protocol and it was written by Jon Postel at UCLA-NMC on April 3, 1972. It was filed as NIC 9348. It builds on RFC 139, RFC 158, and NIC 7104. The header doesn't list anything it obsoletes or updates, and it doesn't include a category or status line 🤷‍♀️

---

Okay so, at the October 1971 Network Working Group Meeting, Jon promised to promptly write a document that clearly and succinctly specified and explained the Official Telnet Protocol 😭 And honestly? This doc fails on every single part of that promise. It wasn't prompt. It's not clear. It's not succinct. Like, there is NO Official Telnet Protocol 💀

What you're getting instead is Jon's understanding of the ad hoc Telnet protocol 🧚 Some people have serious questions about it (valid), and the proposed changes are in Section IV (we'll get there, I promise 🫶)

If you have comments, send them to Jon through the Network Information Center (Ident = JBP), by phone at (213) 825-2368, or by mail. The mailing address is:

Jon Postel
SPADE Group
3804 Boelter Hall
UCLA
Los Angeles, California 90024

I. DEFINITION OF THE NETWORK VIRTUAL TERMINAL ✨

Let's start with the Network Virtual Terminal (NVT) 💅 It's a bi-directional character device. Characters are represented by 8 bit codes, and the NVT has no timing characteristics at all. Codes 0 through 127 are the USASCII codes. (Reminder: all code values here are in decimal, so no sneaky hex 🙈) Codes 128 through 255 are reserved for special control signals.

The NVT is described as having a printer and a keyboard. The printer responds to incoming data, and the keyboard produces outgoing data. Simple, iconic 🌸

The Printer

The NVT printer has an unspecified carriage width. Common values are 40, 72, 80, 120, 128, and 132 🍓 The printer can show all 95 USASCII graphics (codes 32 through 126). Out of the 33 USASCII control codes (0 through 31 and 127), only 8 have a specific meaning to the NVT printer:

NAME                  CODE    MEANING

NULL (NUL)            0       A no operation.

BELL (BEL)            7       Produces an audible or visible signal.

Back Space (BS)       8       Backspaces the printer one character
                              position.

Horizontal Tab (HT)   9       Moves the printer to next horizontal
                              tab stop.

Line Feed (LF)        10      Moves the printer to next line (keeping
                              the same horizontal position).

Vertical Tab (VT)     11      Moves the printer to the next vertical
                              tab stop.

Form Feed (FF)        12      Moves the printer to the top of the
                              next page.

Carriage Return (CR)  13      Moves the printer to the left margin
                              of the current line.

The remaining USASCII codes (1 through 6, 14 through 31, and 127) don't make the NVT printer do anything. Zero action, zero drama 💤

The Keyboard

The NVT keyboard has keys, key combinations, or key sequences that can generate all 128 USASCII codes ⌨️ Even though some codes do nothing on the printer, the keyboard can still send them. That's the vibe: it can say things the printer just ignores 💅

The End of the Line Convention

A line of text ends with the character sequence Carriage Return Line Feed (CR, LF) 🌈 This convention applies to both the sending side (Keyboard) and the receiving side (Printer) of the virtual mechanisms. Both sides shall use it, no exceptions, no cap 🔥

Break and Reverse Break

Telnet control signals include a BREAK signal, which simulates the break, attention, or interrupt button you'll find on most terminals 🦋 BREAK has no effect on the NVT itself. When BREAK goes from server to user, it's sometimes called "reverse break." Same deal: a reverse break also has no effect on the NVT. Bestie, it's giving "I'm here but I'm not touching your printer" 😭

II. DEFINITION OF TELNET PROTOCOL 👑

Now the real tea. The purpose of the Telnet Protocol is to give terminal devices at one site a standard way to talk to processes at another site 🧚 It's basically the universal translator for remote terminals.

The Telnet Protocol is built from three major substructures:

1. The Initial Connection Protocol (ICP) 🤝
2. The Network Virtual Terminal (NVT) 🖨️ (the one we just covered, obsessed 😍)
3. The Telnet control signals, described in the rest of the document 🎀

Telnet user and server processes follow the ICP to set up connections 💖 The term "Logger" refers to the set of processes on the serving system that respond to the ICP and handle the first steps, like getting a name and a password. The ICP itself is defined, and so are the initial socket number and byte size parameters, in "Current Network Protocols" (NIC #7104) 📚

The data sent between user and server programs (and back again) is treated as a character stream with embedded control signals. Think of it as one long stream of text with secret signal messages tucked inside 🫶

Last reminder, because it matters: all code values are given in decimal 🔢

III. DISCUSSION OF TELNET PROTOCOL ✨

okay so the big idea here is a standard, network-wide, middle-ground way to represent terminal code between sites 🌐 so nobody has to keep notes on what everyone else's terminal is like 💅 this can totally work, but only if three parties each do their part:

1. the serving site has to spell out how that middle-ground code gets mapped into the terminal codes it expects 🧚
2. the user has to be familiar with that mapping 🎀
3. the using site has to give the user a way to enter all of the middle-ground codes, plus special Telnet signals as a bonus ✨, and also explain how the signals coming back from the serving site will show up on the user's terminal 🫶

we looked at other options too, but we said no to them 🙅‍♀️ one was having the using site translate to and from whatever code the serving site wants. that would mean the using site keeps tables of every single serving site code and makes a mapping for each one 😭 and those tables would need constant updating every time a new host joined the network. so no thanks 💀

Character Set

so since nobody knows yet how current or future sites will map the network-wide standard code (7 bit ASCII in an 8 bit field) to the codes their own terminals use 🤷‍♀️, we need to let the user send every one of the 128 ASCII codes 🔥 and, for full user power 👑, selected signals too (either Telnet control stuff or special terminal stuff like break or attention) ✨

there was a LOT of feeling about the user/system interface at the using site 💜 but also a lot of feeling that this is a local implementation problem, and it should follow each using site's own installation philosophy instead of network-wide rules 🌸 a few topics to think about here:

1. how to show special graphics at the user's terminal when the using site doesn't have them 🦋
2. the upper/lower case problem on upper case only devices 🍓 a. showing lower-case output 💅 b. giving users shift and shiftlock signals 🌈
3. adding editing capability to Telnet ✏️
4. giving network users options that local users don't get, e.g., hold output or kill print 🙈
5. letting users say how keyboard input gets translated, e.g., a character from the terminal makes the user's Telnet send a specified string 🪄

the proposed Telnet Protocol solution seems to give us a minimum implementation 🦋 and also a base for building richer sets of protocol, for now and later, for terminal apps, process-process communication, and other conventions that want to pass data or control info through it 💖

ASCII as the network-wide code has been the plan for a while now 🧡 but using it in Telnet caused a problem, because the max character set is 128, and some systems have more codes than that in their operation 😵‍💫 so as serving sites, they can't map one-for-one 🙃

each serving site could probably give a pretty useful character set, including all the system control signals, by mapping 128 of its codes and just not giving network users access to the rest 🤏 BUT any character left out might later get used in a major application on that site as a special control signal 😬 and then network users would lose access to that app's features 💔 so serving sites are encouraged to give a full mapping between ASCII and the code they use on their system 🫶 this might mean the server specifies two character ASCII sequences that map to single characters in the server's character set 🔁

also, some ASCII codes don't do anything on the NVT printer 🖨️ those codes still have to go over the network when the serving process outputs them or when the user enters them 🚀

End of Line Convention

different network hosts handle the end of a physical line differently 🧵 some use a return (or new line) key, where the terminal hardware sends the carriage back to the start of the line AND feeds the paper to the next line 📜 other setups have the user hit carriage return, where the hardware returns the carriage and the software sends the terminal a line feed 🛠️ the network-wide version is carriage return followed by line feed 🎀 it represents the physical formatting being attempted, and both the using site and the serving site are supposed to interpret it and translate it appropriately 💅

EXAMPLE, the iconic Multics story 👑

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 Model 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 the NCP for transmission.  Correspondingly, when the
Multics Telnet finds the carriage return line feed sequence in the
data stream coming from the serving site, the two characters are
replaced with the appropriate New Line code which is sent to the
terminal.

okay so Telnet says the end of a line is marked by the ASCII character pair CR LR 🤔 (yes, that's what it says 😭) several real devices out there only have a single new line (NL) function 📠 several computer systems use the CR and LF functions in some programs for meanings that go way beyond formatting 🤯 and several computer systems let CR and LF be used separately, like when a line gets overprinted 🖋️

here's the messy part: for Telnet programs that have to map the NVT onto a device with only an NL function, how do you handle the CR LF? one solution is to look at the character after the CR 👀 if it's an LF, do the NL function, and if it's anything else, backspace to the beginning of the line ⬅️ another problem is a computer system that locally uses period, ".", for the new line function, and that uses CR and LF for semantically important operations in some programs 🙃 so suppose the user Telnet sends CR LF. does that mean "new line" or the "CR operation" followed by the "LF operation "? 😳 the fix is to require Telnet programs to send any CR that isn't meant to be part of a CR LF pair as a CR NUL pair 🧼 then the receiving program can always hold a CR and check the next character to see if a new line function was intended 🫶 this solution is strongly recommended 💖

one more question came up: "Is it permitted to send the Telnet signal NOP (code 130) between a CR and a LF when these are intended to signify new line?" and the answer is "yes, the NOP signal may occur anywhere in the data stream." 🧚✨

Echoing

so the decision that the assumed echo condition is for the using site to provide any echo its terminals need came from the struggles some installations have with turning off their echo, or with terminals that print locally as you type ⌨️ serving sites could say "have the user turn echo off" 🙄 but that seems like an unnecessary burden on the user 😤 also, some serving sites might choose not to offer any echo service at all, and in that case the no echo assumption gives a network-wide condition, while other assumptions would give a mixed starting condition 🌀

the "ECHO" and "NO ECHO" signals seem to cover both the need for dynamic echo control AND a minimum implementation of Telnet Protocol 💜 when the user requests ECHO or NO ECHO, the server either switches to the requested mode (and maybe sends back the signal for the new mode) 🔄 or stays in the current mode and sends back the signal for the current mode 🪞 the server never spontaneously sends an ECHO or NO ECHO signal 🙅‍♀️ the one exception: a NOECHO may be used to cancel a HIDE YOUR INPUT 🫢

Hide Your Input

the HIDE YOUR INPUT signal is a little tricky because it's unclear how much should be hidden 🙈 the server site usually knows how long the secret is, but the user Telnet generally doesn't 😬 also, if the user site can't suppress local echoing, implementation gets really hard 😭 one idea is for the using site to overprint a full line with a mask, and then the user types their secret on top of the mask 🎭 if the secret is longer than one line, the mask should be repeated 🔁

you can skip HIDE YOUR INPUT altogether by having the serving site send a mask (one that it knows is just long enough) for the user to type the secret on 🧠✨

EXAMPLE:

   1.  Default assumption is user site is echoing

   2.  Server-to User:  Password Please CR LF

   3.  Server-to-User:  XXXXCRIIIIICRMMMMCR NUL

   4.  User-to-Server:  "password" CR LF

   5.  Server-to-User:  Ready CR LF

Breaks and Attentions 💖

okay so some terminals have a special control signal that doesn't have a bit pattern in ASCII at all 😭 it gets sent as a special electrical signal instead. On a 2741 it's called Attn, and on a Teletype it's called Break. Telnet represents it with the control signal BREAK. There's a matching one for going from serving sites to using sites, called reverse break 🦋. And ngl, the NVT is a bi-directional character device, so there's no need to "turn the line around" ✨.

Some systems treat Break as an extra code they use alongside the data stream. One system uses it as an editing code that means "delete the current line to this point" 🎀. For those, the code can just get inserted into the data stream, and the user doesn't have to do anything special.

Other systems use Break or Attn as an interrupt, like "stop processing the application and give me the supervisor" or "cancel the present job" 💅. (Systems that inspect input one character at a time use normal characters for this, like <etx>.) Since serving and using sites operate differently, you need a route outside the normal Telnet data stream to say that the special control signal is embedded in the data stream 🧚.

Example -- Problem:

The PDP-10 normally keeps accepting characters when its input buffer is full. It checks each one to see if it's a control character, acts on it if it is, and throws it away if it isn't 💀.

Since the Telnet server at the serving site is at the mercy of the NCP for controlling the bunching, and therefore for when bursts of characters reach Telnet, Telnet implementations might be expected to choke off flow to the buffers until they're ready to accept characters without throwing them away 🫶.

Under this condition, the serving process might be outputting to the using terminal while the input buffers at the server fill up with user-generated characters. Then <etx> gets stuck at the user's site in the data stream that has been choked off 😭.

A similar problem could occur with Multics or some IBM system as a line at a time server. The user at a using site gets his process at the serving site into an output loop and wants to break the process without having to release his Telnet connection. The buffers clog the connection, transmission is choked off, and the <etx>, Break, or other user control signal gets stuck in the pipeline 🙈.

Example -- Solution:

The user at the using site knows they're entering a special control signal (Break, Attn, <etx>, etc.) and follows it with a SYNCH. (The local instructions at using sites for doing this may differ from site to site 🍓.)

   User to Using Site Telnet

      Send SYNCH.

   Using Site Telnet to Serving Site Telnet:

      DATA MARK in Data Stream.

   Using Site Telnet to Using Site NCP:

      Send an INS.

   Serving Site NCP to Telnet Server:

      Interrupt "INS received".

   Serving Site Telnet:

      Examines the input data stream (looking for special control
      signals) until it sees DATA MARK 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 to the special character.  When it sees DATA MARK, it
      recognizes it as a synchronization point and knowing that
      the special character has been passed on, strips the DATA
      MARK from the data stream and returns to normal mode.

      If the DATA MARK arrives before the INS, the serving site
      should not process the data stream further until an INS is
      received.

This approach to handling selected special characters or signals means the using Telnet processes don't have to recognize the special serving site characters, or know how the serving site wants to handle them 🌈. It also only asks the user to understand the serving site a little, which seems right, since the Telnet ASCII conventions are providing a Network Virtual Terminal, not a Network Virtual User 💜.

Notice that the correct order is (1) special character or signal (e.g. BREAK or <etx>), then (2) SYNCH ✨.

---

User Telnet Signals 🎀

The user being able to make the using site Telnet send any combination of ASCII characters in a string, and only that combination, is seen as really important to the user utility of the Telnet ASCII conventions 👑. Because of this, some user sites may need special local Telnet signals from the human user to the using site Telnet.

Example:

A user is on a line at a time system (Multics, System 360, GCOS, etc.) that needs an end of line signal before it processes input. They're working through the Network on a serving site that operates a character at a time. The application is a debugging aid that lets the user type in location=, and it responds with n, where n is the current contents of that location 🧚. The serving site process doesn't expect to see location= followed by a carriage return line feed sequence. So the user at the using site should be able to type in the location, follow it with a signal (to the user Telnet) that suppresses the end of line convention, then follow that with the end of line signal. They can expect location= to be sent immediately, without an end of line sequence going to the server 😭.

Example:

In another case, a using site has decided it's convenient to collect four characters at a time and send them to the serving site, unless an end of line signal shows up. In that case, the end of line sequence is sent after whatever number of characters have been collected (presumably three or less) 🦋. In the same debugging application, the address doesn't line up with the four character buffer boundary. The user should be able to enter a code for "transmit immediately" in place of the end of line signal, so the formatting stays neat and the address gets sent to the serving site 🍓.

Telnet Signals have been discussed, and the ones introduced so far are probably enough for an implementation of the Telnet ASCII convention 💅.

---

Terminology 📚

• ASCII - The USASCII character set as defined in NIC # 7104. In Telnet Protocol, where eight bit codes are used, the lower half of the code set is defined to be ASCII.
• echoing - The display of a character entered is called echoing. There are two modes in which this happens. If the device used to enter characters displays the character before (or as) it transmits the character to the computer, the echoing mode is called "local echo." If, on the other hand, the device transmits the entered character to the computer without displaying it, and the computer then transmits a character to the device for the echo display, this echoing mode is called "remote echo" 🌸.
• character mode - In this mode of operation, Telnet transmits each character as soon as possible. Generally speaking, character mode is used when all of the using terminal, using system, and serving system are operating in a remote echo mode. The echos to the user entered characters are transmitted from the serving system (i.e., over the network) 💖.
• line mode - In this mode of operation, Telnet transmits groups of characters which constitute lines. Generally speaking, this mode is used when one or more of the using terminal, using system, or serving system is operating in a local echo mode. The echos to the user entered characters are not transmitted over the network) 🫶.
• full duplex - This term indicates a transmission procedure using a four wire connection, which permits simultaneous transmission in both directions 🔥.
• half duplex - This term indicates a transmission procedure using a two wire connection, which requires that data be transmitted in only one direction at at time 🙈.

Note that half duplex devices usually are also local echo, but full duplex devices may be either local echo or remote echo ✨.

---

IV. PROPOSED CHANGES TO TELNET PROTOCOL ✨

The changes suggested here aren't my ideas, so the presentation may be faulty 🙈. I welcome RFC or other communication suggesting other changes, or better arguments for and against these changes 💜.

Echoing

It's proposed to delete the control signals ECHO, NOECHO, and HIDE YOUR INPUT from Telnet 💀. For server systems which don't provide echoing, these commands are useless. For server systems which do provide echoing, experience has shown that the control is most effectively provided by server system commands 🎀.

Data Types

It's proposed to delete all mention of data types from Telnet. Either the character stream is ASCII or it's not a Telnet communication 👑. If it's really necessary to change the data type, a command in ASCII could be sent in the data stream 🧚.

Minimum Implementation

It's proposed that the minimum implementation require the user Telnet to allow the user to send, and the server Telnet to correctly process, all the Telnet control signals 🌈.

---

The work on Telnet Protocol has involved many people 🫶. This document is taken from RFC's #139 and #158 by Tom O'Sullivan. Others who have served on committees are:

                 Bob Bressler           MIT-DMCG

                 Will Crowther          BBN

                 Bob Long               SDC

                 Alex McKenzie          BBN

                 John Melvin            SRI-ARC

                 Bob Metcalfe           MIT-DMCG

                 Ed Meyer               MIT-Multics

                 Tol O'Sullivan         Raytheon

                 Mike Padlipsky         Mit-Multics

                 Jon Postel             UCLA-NMC

                 Bob Sundberg           Harvard

                 Joel Winett            LL

                 Steve Wolfe            UCLA-CCN


     [This RFC was put into machine readable form for entry]
  [into the online RFC archives by Kelly Tardif, Viaginie 10/99]