Computer NetworksTelnet

Telnet: The Foundation of Remote Terminal Access

LevelIntermediate

Duration55 mins

TopicTelnet

3 / 5

The Network Virtual Terminal: Universal Abstraction for Remote Access

The Babel Problem of Computing

In the early days of networking, a fundamental problem threatened the dream of universal connectivity. Different computer manufacturers produced terminals with vastly different characteristics. An IBM 3270 terminal operated entirely differently from a DEC VT100, which behaved nothing like a Teletype ASR-33. Each had unique character codes, control sequences, line endings, and capabilities.

How could a user at a Honeywell terminal in Cambridge connect to an IBM mainframe in California? The terminal's native language was incomprehensible to the distant computer. This was the Babel problem of early computing—a cacophony of incompatible terminal dialects that threatened to fragment the emerging internetwork.

The solution was brilliant in its simplicity: create an imaginary, standardized terminal that exists only within the network. Every real terminal translates its native operations to and from this standard. This fictional device is the Network Virtual Terminal (NVT)—and its concept underpins not just Telnet, but our fundamental approach to protocol abstraction.

What You Will Master

By the end of this page, you will fully understand the NVT abstraction, its character set and control codes, how real terminals map to the NVT standard, the role of translation at each endpoint, and why this concept remains influential in modern protocol design.

The Problem of Terminal Diversity

Before understanding the NVT solution, we must appreciate the severity of the problem it solved. In the 1960s and 1970s, terminal diversity wasn't a minor inconvenience—it was a fundamental barrier to interoperability.

Character Set Fragmentation:

Not all computers used ASCII. IBM mainframes used EBCDIC (Extended Binary Coded Decimal Interchange Code), which assigned entirely different numeric values to characters. The letter 'A' was 65 in ASCII but 193 in EBCDIC. A user typing 'A' on an ASCII terminal, if sent raw to an EBCDIC system, would be interpreted as something entirely different.

Line Ending Chaos:

How do you indicate "end of line"?

Unix systems: LF (Line Feed, ASCII 10)
Windows/DOS systems: CR LF (Carriage Return + Line Feed, ASCII 13 + 10)
Classic Mac: CR only
Some mainframes: Record-length prefixes with no explicit line endings

A Unix system's text sent raw to a mainframe would appear as one continuous line; mainframe text on Unix might double-space or not advance at all.

Control Sequence Variation:

Different terminals used different escape sequences for cursor control, screen clearing, and formatting:

VT100: ESC [ 2 J clears screen
ANSI: Same sequence (VT100-compatible)
Wyse 60: ESC + clears screen
ADM-3A: ESC = clears screen
IBM 3270: No escape sequences; attribute-based

Software written for one terminal produced garbage on another.

Terminal Characteristic Variations Circa 1970s
Characteristic	Variation Examples	Interoperability Impact
Character Encoding	ASCII, EBCDIC, Baudot, ISO variants	Characters transmit as wrong symbols
Line Endings	CR, LF, CRLF, record-based	Lines run together or double-space
Screen Dimensions	40×24, 80×24, 80×25, 132×43	Display overflow or truncation
Control Sequences	VT100, ANSI, Wyse, ADM, proprietary	Screen commands display as garbage
Character Width	7-bit, 8-bit, 5-bit (Baudot)	High-bit characters lost or corrupt
Local Echo	Full-duplex, half-duplex	Characters double or vanish
Flow Control	XON/XOFF, DTR, none	Data overruns or connection hangs

The N² Problem

Without standardization, supporting N terminal types requires N² translation mappings—each terminal type to every other. With 20 terminal types, that's 400 mappings to maintain. The NVT reduces this to 2N mappings (each terminal to/from NVT), dramatically simplifying the ecosystem.

The Network Virtual Terminal Concept

The Network Virtual Terminal (NVT) is a hypothetical, standardized device that serves as the common language for all Telnet communication. Every endpoint—client and server—translates between its local terminal conventions and the NVT standard. Data crossing the network exists exclusively in NVT format.

The NVT Definition:

The NVT is defined as a very simple, lowest-common-denominator terminal with specific, standardized characteristics:

Character Set:

Uses the US-ASCII character set (7-bit)
Characters 0-127 have defined meanings
Only printable ASCII (32-126) initially assumed displayable

Line Ending:

End of line is CR LF (Carriage Return followed by Line Feed)
This is mandatory regardless of local conventions

Display Model:

Hardcopy (printing) terminal model, not screen-based
No cursor positioning, screen clearing, or attributes
New output appears below previous output

Basic Control Characters:

NUL (0): No operation, may be used for timing
BEL (7): Audible or visible alert
BS (8): Backspace—move print position left one column
HT (9): Horizontal tab—move to next tab stop
LF (10): Line feed—move to next line (same column)
VT (11): Vertical tab—implementation defined
FF (12): Form feed—move to next page
CR (13): Carriage return—move to column one of current line

Echo Policy:

By default, NVT does NOT echo locally
Server is expected to echo received characters back
This can be renegotiated via Telnet options

Converting Mermaid diagram...

The Elegance of Abstraction:

The genius of NVT lies in its role as a canonical intermediate representation. Consider what happens when a VT100 user connects to an IBM mainframe:

User types on VT100 (ASCII, LF line ending)
Client translates: ASCII → ASCII (no change for most chars), LF → CR LF
Data crosses network in NVT format
Server receives NVT format
Server translates: ASCII → EBCDIC, CR LF → however the mainframe expects
Mainframe processes input

Reverse path for output:

Mainframe generates EBCDIC output with its line endings
Server translates: EBCDIC → ASCII, local → CR LF
Data crosses network in NVT format
Client receives NVT format
Client translates: CR LF → LF for VT100 display, applies VT100 capabilities
User sees properly formatted output

The Translation Burden

NVT pushes complexity to the endpoints. The network itself carries a simple, well-defined format. This principle—complexity at edges, simplicity in the core—became foundational to Internet architecture. It's better known as the 'end-to-end principle.'

NVT Character Set and Encoding

The NVT character set is base US-ASCII, augmented with Telnet's special control functions. Understanding this character set is essential for correctly implementing NVT translation.

The ASCII Foundation:

NVT uses 7-bit US-ASCII, encompassing:

0-31: Control characters (most NVT-defined below)
32-126: Printable characters (space through tilde)
127: DEL (Delete, historically used to mark punched tape errors)

The 8th bit (high bit) is initially not used; transmission should set it to zero. The Binary Transmission option (Telnet option 0) allows 8-bit data when negotiated.

NVT Control Character Semantics:

NVT Control Character Definitions
Decimal	Hex	Abbrev	NVT Meaning
0	00	NUL	No operation; may be sent for timing or padding
7	07	BEL	Produce an audible or visual alert
8	08	BS	Move print position one column left (if not at left edge)
9	09	HT	Move to next horizontal tab stop
10	0A	LF	Move to next line, keeping same column position
11	0B	VT	Move to next vertical tab stop (implementation dependent)
12	0C	FF	Move to top of next page
13	0D	CR	Move print position to column one of current line
127	7F	DEL	Delete; no defined NVT action, may be ignored

The CR LF Convention:

The NVT line ending deserves special attention. In NVT, to produce a new line (what you get when pressing Enter), you must transmit:

CR (13): Return print position to column one
LF (10): Advance to the next line

This sequence mimics the operation of physical teletypewriters: the carriage (printing head) returns to the left margin (CR), then the paper advances one line (LF).

Bare CR and Bare LF:

What if you want to send CR without a line feed (to overprint a line) or LF without a carriage return (to move down without returning)? The NVT specification requires:

To send bare CR: Transmit CR NUL (CR followed by NUL byte)
To send bare LF: Allowed as-is (LF alone means move down, same column)

In practice, the CR NUL convention is rarely used; most implementations treat bare CR as CR LF.

Handling Bare CR:

A robust receiver encountering CR should:

If followed by LF: Process as newline
If followed by NUL: Interpret as bare CR (carriage return only)
If followed by anything else: Interpret as CR (some implementations treat as CR LF)

NVT Line Ending Translation Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Scenario 1: Unix client (LF) to NVT
// User types "Hello" and presses Enter
// Local: H e l l o LF
// NVT:   H e l l o CR LF
// Bytes: 48 65 6C 6C 6F 0D 0A
 
// Scenario 2: NVT to Windows server (CR LF)
// Received: H e l l o CR LF
// No translation needed: H e l l o CR LF
// Windows expects CR LF, matches NVT
 
// Scenario 3: NVT to Unix server (LF)
// Received: H e l l o CR LF
// Server strips CR: H e l l o LF
// Unix stores LF only
 
// Scenario 4: Overprint line (rare)
// To overprint "AAA" with "BBB":
// LF moves down, type AAA, CR (no LF) returns to start
// Then type BBB on same line
// NVT encoding: A A A CR NUL B B B
// Bytes: 41 41 41 0D 00 42 42 42

Legacy Lives On

The CR LF convention in NVT influenced many later protocols. HTTP uses CR LF for line endings in headers. SMTP uses CR LF for message delimiters. The convention traced back to physical teleprinters now lives on in the Internet's most important protocols.

NVT Default Operational Modes

Beyond character encoding, the NVT defines default operational behaviors. These defaults ensure predictable behavior before any option negotiation occurs, allowing basic communication even between the most primitive implementations.

Default Echo Behavior:

By default, the NVT operates in a "network echo" mode:

The client sends characters to the server without local echo
The server echoes characters back to the client
The client displays echoed characters from the server

This ensures the user sees exactly what the remote system received, which is particularly important when the remote system is interpreting special characters or when line editing occurs on the server.

However, this default creates latency issues—every keystroke makes a network round trip before appearing on screen. The ECHO option (Telnet option 1) and SUPPRESS-GO-AHEAD option (Telnet option 3) allow negotiating more efficient modes.

Default Transmission Mode:

The NVT default is line-at-a-time transmission in a half-duplex style:

User types a line locally (with local line editing if available)
Upon pressing Enter, the entire line transmits to the server
Server processes and responds
Server sends GO AHEAD (GA) signal indicating "your turn"
Client resumes sending

This mode reduces network traffic and allows local line editing but feels sluggish for interactive applications. The SUPPRESS-GO-AHEAD option enables full-duplex, character-at-a-time operation.

Default Capabilities:

The baseline NVT is deliberately minimal:

No cursor positioning
No screen clearing
No character attributes (bold, color)
No graphics or extended characters
No local editing beyond basic backspace

NVT Default Mode

•Line-at-a-time transmission
•Half-duplex (Go Ahead signaling)
•Remote echo (server echoes)
•7-bit ASCII only
•Hardcopy terminal model
•No screen control
•CR LF line endings

After Common Options

•Character-at-a-time transmission
•Full-duplex (SGA negotiated)
•Server echo (more efficient)
•8-bit binary possible
•Terminal type exchanged
•Window size known (NAWS)
•Environment variables passed

Why Such Primitive Defaults?

The NVT defaults are deliberately primitive to ensure universal compatibility. Any system capable of basic ASCII I/O can participate in a Telnet session at the NVT level. From this baseline, sophisticated systems negotiate additional capabilities while still being able to communicate with primitive endpoints.

Translation at Endpoints

The practical implementation of NVT requires translation layers at both client and server endpoints. These translators convert between local terminal conventions and the standardized NVT format.

Client-Side Translation:

The Telnet client must:

Input Translation (User → Network):

Convert local line endings to CR LF
Map special keys to appropriate Telnet commands (Ctrl+C → IAC IP)
Handle local character encoding to ASCII conversion
Escape any literal 255 bytes as IAC IAC

Output Translation (Network → Display):

Convert CR LF to local line ending for display
Interpret NVT control characters (BEL, BS, etc.)
If terminal type negotiated, interpret escape sequences
Handle remote echo visibility

Server-Side Translation:

The Telnet server (or terminal server) must:

Input Translation (Network → Application):

Convert NVT CR LF to local line ending convention
Translate IAC commands to appropriate signals (IP → SIGINT)
Pass data to pseudo-terminal for shell consumption
Handle character encoding if not ASCII

Output Translation (Application → Network):

Convert local line endings to CR LF
Ensure output is valid NVT (primarily ASCII)
Escape any 255 bytes as IAC IAC
Handle flow control and buffering

NVT Translation (Pseudocode)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Client-side input translation (user types to network)
function translateToNVT(localInput):
    nvtOutput = []
    
    for char in localInput:
        if char == LOCAL_NEWLINE:
            nvtOutput.append(CR)
            nvtOutput.append(LF)
        else if char == 255:
            nvtOutput.append(IAC)
            nvtOutput.append(IAC)
        else if char == CTRL_C:
            nvtOutput.append(IAC)
            nvtOutput.append(IP)
        else if isLocalEncoding(char):
            nvtOutput.append(toASCII(char))
        else:
            nvtOutput.append(char)
    
    return nvtOutput
 
// Server-side output translation (application to network)
function translateFromLocal(applicationOutput):
    nvtOutput = []
    
    for char in applicationOutput:
        if char == LOCAL_NEWLINE:
            nvtOutput.append(CR)
            nvtOutput.append(LF)
        else if char == 255:
            nvtOutput.append(IAC)
            nvtOutput.append(IAC)
        else if needsEncoding(char):
            nvtOutput.append(toASCII(char))
        else:
            nvtOutput.append(char)
    
    return nvtOutput
 
// Client-side output translation (network to display)
function translateFromNVT(nvtInput):
    displayOutput = []
    skipLF = false
    
    for i, char in enumerate(nvtInput):
        if char == CR:
            if nextChar(nvtInput, i) == LF:
                displayOutput.append(LOCAL_NEWLINE)
                skipLF = true
            else:
                // Bare CR - carriage return only
                displayOutput.append(CR_ONLY)
        else if char == LF:
            if skipLF:
                skipLF = false
            else:
                displayOutput.append(LOCAL_NEWLINE)
        else if char == BEL:
            ring_bell()
        else if char == BS:
            move_cursor_left()
        else:
            displayOutput.append(toLocalEncoding(char))
    
    return displayOutput

Edge Cases Abound

Real NVT translation has many edge cases: what if input contains non-ASCII chars without Binary mode? What if CR is the last character before connection close? Robust implementations handle these gracefully, often by being lenient in what they accept while strict in what they send.

Beyond Basic NVT: Extended Capabilities

The baseline NVT is intentionally minimal, but real terminals offer rich capabilities. Telnet's option mechanism allows endpoints to transcend NVT limitations when both support enhanced features.

Terminal Type Exchange:

Perhaps the most important enhancement is terminal type negotiation (Telnet option 24). When enabled:

Server requests terminal type via subnegotiation
Client responds with its terminal type (e.g., "VT100", "XTERM")
Server looks up terminal capabilities in a database (terminfo/termcap)
Server can now send terminal-specific escape sequences

This transforms the connection from basic NVT to a full-featured terminal session. The output can include cursor positioning, colors, screen clearing—anything the declared terminal supports.

Binary Mode:

Telnet option 0 (Binary Transmission) removes the NVT assumption of 7-bit ASCII:

Full 8-bit bytes can be transmitted
Character set can be anything (UTF-8, ISO-8859-x, etc.)
Still must escape 255 as IAC IAC

Window Size (NAWS):

Telnet option 31 allows dynamic window size communication:

Client sends current dimensions (width × height in characters)
Server resizes pseudo-terminal to match
Applications adjust their display accordingly
Updates sent when user resizes window

Linemode:

Telnet option 34 (Linemode) provides sophisticated local editing:

Line editing (insert, delete, history) happens locally
Only complete lines sent to server
Reduces network traffic dramatically
Complex negotiation of which characters trigger transmission

NVT Extensions via Telnet Options
Capability	Option	How It Extends NVT
Full terminal emulation	Terminal Type (24)	Enables terminal-specific escape sequences
8-bit data	Binary (0)	Allows non-ASCII characters
Dynamic sizing	NAWS (31)	Terminal dimensions known to server
Local editing	Linemode (34)	Rich local line editing
Character mode	SGA (3) + Echo (1)	Character-at-a-time interactive mode
Environment passing	Environment (36)	Pass env vars to remote shell
Encryption	Encryption (38)	Encrypted data transmission (rare)

The terminfo/termcap System:

After terminal type exchange, the server needs to know what escape sequences the terminal understands. Unix systems use the terminfo (or older termcap) database:

Contains entries for hundreds of terminal types
Each entry lists capabilities: cursor movement, screen clear, colors
Applications query terminfo to get escape sequences
Programs like ncurses provide portable terminal I/O

For example, when vim needs to clear the screen on a VT100, it queries terminfo for the "clear" capability of VT100, receives "\033[2J", and sends that sequence.

TERM Environment Variable

After terminal type negotiation, the server typically sets the TERM environment variable to the negotiated type. Applications then use TERM to query terminfo for the correct escape sequences. If your terminal seems broken (wrong colors, garbled display), the TERM variable is often the culprit.

NVT's Design Legacy

The Network Virtual Terminal concept extends far beyond Telnet itself. Its design patterns—canonical intermediate representations, complexity at endpoints, negotiated extension—became templates for protocol design across the Internet.

Pattern 1: Canonical Representation

The idea of converting diverse local formats to a standard network format appears everywhere:

MIME email: Various character sets encoded to quoted-printable or base64
HTTP: Character encoding declared in headers, content follows
JSON/XML: Unicode-based interchange formats for structured data
Video streaming: Source formats transcode to standard codecs

Each follows NVT's insight: define a common language, translate at edges.

Pattern 2: Negotiated Capabilities

Telnet's WILL/WONT/DO/DONT mechanism influenced:

SSL/TLS: Cipher suite negotiation
HTTP: Accept headers for content negotiation
SIP: Media capability negotiation for VoIP
SMTP: EHLO extension advertisement

The principle of discovering common ground without prior coordination proves universally valuable.

Pattern 3: Graceful Degradation

NVT's minimal baseline ensures basic functionality even without advanced features:

HTTP: Works without cookies, JavaScript, even CSS
Email: Plaintext fallback when MIME fails
Video: Lower resolutions when bandwidth limited

Designing for baseline capability with optional enhancement creates robust, widely deployable systems.

Protocols Influenced by NVT Design

•SSH — Uses similar pseudo-terminal architecture, terminal type exchange, window size handling
•SMTP — Extended with EHLO capability advertisement, CR LF line endings from NVT
•HTTP — Uses CR LF line endings, stateless baseline with extension headers
•FTP — NVT-ASCII mode for text transfers, option negotiation for features
•IRC — Text-based protocol with NVT conventions for line endings
•Serial console protocols — Continue the terminal abstraction for physical devices

A Pattern Language for Protocols

NVT's design patterns form part of an implicit 'pattern language' for Internet protocols. Understanding these patterns helps you comprehend new protocols faster—you recognize familiar structures in unfamiliar contexts because the underlying design philosophy is consistent.

Summary: The Network Virtual Terminal

We've thoroughly explored the Network Virtual Terminal—the elegant abstraction that solved the heterogeneity problem and enabled universal remote terminal access. Let's consolidate our understanding:

Key Takeaways

•NVT solved the terminal heterogeneity problem — Creating a common language for diverse terminal types to intercommunicate
•NVT uses 7-bit ASCII with specific control characters — BEL, BS, HT, LF, VT, FF, CR have defined meanings
•CR LF is the mandatory line ending — Regardless of local conventions, all lines end with CR (13) followed by LF (10)
•Translation occurs at endpoints — Complexity pushed to edges, network carries standardized format
•Default operation is minimal — Line-at-a-time, half-duplex, remote echo—ensuring universal baseline
•Options extend beyond NVT baseline — Terminal type, binary mode, window size enable rich sessions
•NVT patterns influenced protocol design — Canonical representation, negotiation, graceful degradation appear throughout Internet protocols

What's Next:

Now that we understand the NVT abstraction that makes Telnet work across diverse systems, we'll examine Telnet's security issues—the fundamental flaws that made this pioneering protocol unsuitable for secure environments and led to the development of SSH.

Page Complete

You now deeply understand the Network Virtual Terminal concept, its character set, operational defaults, endpoint translation requirements, and lasting influence on protocol design. This abstraction layer is the key to Telnet's universal interoperability.

3 / 5

Loading learning content...

Computer NetworksTelnet

Telnet: The Foundation of Remote Terminal Access

LevelIntermediate

Duration55 mins

TopicTelnet

3 / 5

The Network Virtual Terminal: Universal Abstraction for Remote Access

The Babel Problem of Computing

What You Will Master

The Problem of Terminal Diversity

Character Set Fragmentation:

Line Ending Chaos:

How do you indicate "end of line"?

Unix systems: LF (Line Feed, ASCII 10)
Windows/DOS systems: CR LF (Carriage Return + Line Feed, ASCII 13 + 10)
Classic Mac: CR only
Some mainframes: Record-length prefixes with no explicit line endings

A Unix system's text sent raw to a mainframe would appear as one continuous line; mainframe text on Unix might double-space or not advance at all.

Control Sequence Variation:

Different terminals used different escape sequences for cursor control, screen clearing, and formatting:

VT100: ESC [ 2 J clears screen
ANSI: Same sequence (VT100-compatible)
Wyse 60: ESC + clears screen
ADM-3A: ESC = clears screen
IBM 3270: No escape sequences; attribute-based

Software written for one terminal produced garbage on another.

Terminal Characteristic Variations Circa 1970s
Characteristic	Variation Examples	Interoperability Impact
Character Encoding	ASCII, EBCDIC, Baudot, ISO variants	Characters transmit as wrong symbols
Line Endings	CR, LF, CRLF, record-based	Lines run together or double-space
Screen Dimensions	40×24, 80×24, 80×25, 132×43	Display overflow or truncation
Control Sequences	VT100, ANSI, Wyse, ADM, proprietary	Screen commands display as garbage
Character Width	7-bit, 8-bit, 5-bit (Baudot)	High-bit characters lost or corrupt
Local Echo	Full-duplex, half-duplex	Characters double or vanish
Flow Control	XON/XOFF, DTR, none	Data overruns or connection hangs

The N² Problem

The Network Virtual Terminal Concept

The NVT Definition:

The NVT is defined as a very simple, lowest-common-denominator terminal with specific, standardized characteristics:

Character Set:

Uses the US-ASCII character set (7-bit)
Characters 0-127 have defined meanings
Only printable ASCII (32-126) initially assumed displayable

Line Ending:

End of line is CR LF (Carriage Return followed by Line Feed)
This is mandatory regardless of local conventions

Display Model:

Hardcopy (printing) terminal model, not screen-based
No cursor positioning, screen clearing, or attributes
New output appears below previous output

Basic Control Characters:

NUL (0): No operation, may be used for timing
BEL (7): Audible or visible alert
BS (8): Backspace—move print position left one column
HT (9): Horizontal tab—move to next tab stop
LF (10): Line feed—move to next line (same column)
VT (11): Vertical tab—implementation defined
FF (12): Form feed—move to next page
CR (13): Carriage return—move to column one of current line

Echo Policy:

By default, NVT does NOT echo locally
Server is expected to echo received characters back
This can be renegotiated via Telnet options

Converting Mermaid diagram...

The Elegance of Abstraction:

The genius of NVT lies in its role as a canonical intermediate representation. Consider what happens when a VT100 user connects to an IBM mainframe:

User types on VT100 (ASCII, LF line ending)
Client translates: ASCII → ASCII (no change for most chars), LF → CR LF
Data crosses network in NVT format
Server receives NVT format
Server translates: ASCII → EBCDIC, CR LF → however the mainframe expects
Mainframe processes input

Reverse path for output:

Mainframe generates EBCDIC output with its line endings
Server translates: EBCDIC → ASCII, local → CR LF
Data crosses network in NVT format
Client receives NVT format
Client translates: CR LF → LF for VT100 display, applies VT100 capabilities
User sees properly formatted output

The Translation Burden

NVT Character Set and Encoding

The NVT character set is base US-ASCII, augmented with Telnet's special control functions. Understanding this character set is essential for correctly implementing NVT translation.

The ASCII Foundation:

NVT uses 7-bit US-ASCII, encompassing:

0-31: Control characters (most NVT-defined below)
32-126: Printable characters (space through tilde)
127: DEL (Delete, historically used to mark punched tape errors)

The 8th bit (high bit) is initially not used; transmission should set it to zero. The Binary Transmission option (Telnet option 0) allows 8-bit data when negotiated.

NVT Control Character Semantics:

NVT Control Character Definitions
Decimal	Hex	Abbrev	NVT Meaning
0	00	NUL	No operation; may be sent for timing or padding
7	07	BEL	Produce an audible or visual alert
8	08	BS	Move print position one column left (if not at left edge)
9	09	HT	Move to next horizontal tab stop
10	0A	LF	Move to next line, keeping same column position
11	0B	VT	Move to next vertical tab stop (implementation dependent)
12	0C	FF	Move to top of next page
13	0D	CR	Move print position to column one of current line
127	7F	DEL	Delete; no defined NVT action, may be ignored

The CR LF Convention:

The NVT line ending deserves special attention. In NVT, to produce a new line (what you get when pressing Enter), you must transmit:

CR (13): Return print position to column one
LF (10): Advance to the next line

This sequence mimics the operation of physical teletypewriters: the carriage (printing head) returns to the left margin (CR), then the paper advances one line (LF).

Bare CR and Bare LF:

What if you want to send CR without a line feed (to overprint a line) or LF without a carriage return (to move down without returning)? The NVT specification requires:

To send bare CR: Transmit CR NUL (CR followed by NUL byte)
To send bare LF: Allowed as-is (LF alone means move down, same column)

In practice, the CR NUL convention is rarely used; most implementations treat bare CR as CR LF.

Handling Bare CR:

A robust receiver encountering CR should:

If followed by LF: Process as newline
If followed by NUL: Interpret as bare CR (carriage return only)
If followed by anything else: Interpret as CR (some implementations treat as CR LF)

NVT Line Ending Translation Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Scenario 1: Unix client (LF) to NVT
// User types "Hello" and presses Enter
// Local: H e l l o LF
// NVT:   H e l l o CR LF
// Bytes: 48 65 6C 6C 6F 0D 0A
 
// Scenario 2: NVT to Windows server (CR LF)
// Received: H e l l o CR LF
// No translation needed: H e l l o CR LF
// Windows expects CR LF, matches NVT
 
// Scenario 3: NVT to Unix server (LF)
// Received: H e l l o CR LF
// Server strips CR: H e l l o LF
// Unix stores LF only
 
// Scenario 4: Overprint line (rare)
// To overprint "AAA" with "BBB":
// LF moves down, type AAA, CR (no LF) returns to start
// Then type BBB on same line
// NVT encoding: A A A CR NUL B B B
// Bytes: 41 41 41 0D 00 42 42 42

Legacy Lives On

NVT Default Operational Modes

Default Echo Behavior:

By default, the NVT operates in a "network echo" mode:

The client sends characters to the server without local echo
The server echoes characters back to the client
The client displays echoed characters from the server

Default Transmission Mode:

The NVT default is line-at-a-time transmission in a half-duplex style:

User types a line locally (with local line editing if available)
Upon pressing Enter, the entire line transmits to the server
Server processes and responds
Server sends GO AHEAD (GA) signal indicating "your turn"
Client resumes sending

This mode reduces network traffic and allows local line editing but feels sluggish for interactive applications. The SUPPRESS-GO-AHEAD option enables full-duplex, character-at-a-time operation.

Default Capabilities:

The baseline NVT is deliberately minimal:

No cursor positioning
No screen clearing
No character attributes (bold, color)
No graphics or extended characters
No local editing beyond basic backspace

NVT Default Mode

•Line-at-a-time transmission
•Half-duplex (Go Ahead signaling)
•Remote echo (server echoes)
•7-bit ASCII only
•Hardcopy terminal model
•No screen control
•CR LF line endings

After Common Options

•Character-at-a-time transmission
•Full-duplex (SGA negotiated)
•Server echo (more efficient)
•8-bit binary possible
•Terminal type exchanged
•Window size known (NAWS)
•Environment variables passed

Why Such Primitive Defaults?

Translation at Endpoints

The practical implementation of NVT requires translation layers at both client and server endpoints. These translators convert between local terminal conventions and the standardized NVT format.

Client-Side Translation:

The Telnet client must:

Input Translation (User → Network):

Convert local line endings to CR LF
Map special keys to appropriate Telnet commands (Ctrl+C → IAC IP)
Handle local character encoding to ASCII conversion
Escape any literal 255 bytes as IAC IAC

Output Translation (Network → Display):

Convert CR LF to local line ending for display
Interpret NVT control characters (BEL, BS, etc.)
If terminal type negotiated, interpret escape sequences
Handle remote echo visibility

Server-Side Translation:

The Telnet server (or terminal server) must:

Input Translation (Network → Application):

Convert NVT CR LF to local line ending convention
Translate IAC commands to appropriate signals (IP → SIGINT)
Pass data to pseudo-terminal for shell consumption
Handle character encoding if not ASCII

Output Translation (Application → Network):

Convert local line endings to CR LF
Ensure output is valid NVT (primarily ASCII)
Escape any 255 bytes as IAC IAC
Handle flow control and buffering

NVT Translation (Pseudocode)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// Client-side input translation (user types to network)
function translateToNVT(localInput):
    nvtOutput = []
    
    for char in localInput:
        if char == LOCAL_NEWLINE:
            nvtOutput.append(CR)
            nvtOutput.append(LF)
        else if char == 255:
            nvtOutput.append(IAC)
            nvtOutput.append(IAC)
        else if char == CTRL_C:
            nvtOutput.append(IAC)
            nvtOutput.append(IP)
        else if isLocalEncoding(char):
            nvtOutput.append(toASCII(char))
        else:
            nvtOutput.append(char)
    
    return nvtOutput
 
// Server-side output translation (application to network)
function translateFromLocal(applicationOutput):
    nvtOutput = []
    
    for char in applicationOutput:
        if char == LOCAL_NEWLINE:
            nvtOutput.append(CR)
            nvtOutput.append(LF)
        else if char == 255:
            nvtOutput.append(IAC)
            nvtOutput.append(IAC)
        else if needsEncoding(char):
            nvtOutput.append(toASCII(char))
        else:
            nvtOutput.append(char)
    
    return nvtOutput
 
// Client-side output translation (network to display)
function translateFromNVT(nvtInput):
    displayOutput = []
    skipLF = false
    
    for i, char in enumerate(nvtInput):
        if char == CR:
            if nextChar(nvtInput, i) == LF:
                displayOutput.append(LOCAL_NEWLINE)
                skipLF = true
            else:
                // Bare CR - carriage return only
                displayOutput.append(CR_ONLY)
        else if char == LF:
            if skipLF:
                skipLF = false
            else:
                displayOutput.append(LOCAL_NEWLINE)
        else if char == BEL:
            ring_bell()
        else if char == BS:
            move_cursor_left()
        else:
            displayOutput.append(toLocalEncoding(char))
    
    return displayOutput

Edge Cases Abound

Beyond Basic NVT: Extended Capabilities

The baseline NVT is intentionally minimal, but real terminals offer rich capabilities. Telnet's option mechanism allows endpoints to transcend NVT limitations when both support enhanced features.

Terminal Type Exchange:

Perhaps the most important enhancement is terminal type negotiation (Telnet option 24). When enabled:

Server requests terminal type via subnegotiation
Client responds with its terminal type (e.g., "VT100", "XTERM")
Server looks up terminal capabilities in a database (terminfo/termcap)
Server can now send terminal-specific escape sequences

This transforms the connection from basic NVT to a full-featured terminal session. The output can include cursor positioning, colors, screen clearing—anything the declared terminal supports.

Binary Mode:

Telnet option 0 (Binary Transmission) removes the NVT assumption of 7-bit ASCII:

Full 8-bit bytes can be transmitted
Character set can be anything (UTF-8, ISO-8859-x, etc.)
Still must escape 255 as IAC IAC

Window Size (NAWS):

Telnet option 31 allows dynamic window size communication:

Client sends current dimensions (width × height in characters)
Server resizes pseudo-terminal to match
Applications adjust their display accordingly
Updates sent when user resizes window

Linemode:

Telnet option 34 (Linemode) provides sophisticated local editing:

Line editing (insert, delete, history) happens locally
Only complete lines sent to server
Reduces network traffic dramatically
Complex negotiation of which characters trigger transmission

NVT Extensions via Telnet Options
Capability	Option	How It Extends NVT
Full terminal emulation	Terminal Type (24)	Enables terminal-specific escape sequences
8-bit data	Binary (0)	Allows non-ASCII characters
Dynamic sizing	NAWS (31)	Terminal dimensions known to server
Local editing	Linemode (34)	Rich local line editing
Character mode	SGA (3) + Echo (1)	Character-at-a-time interactive mode
Environment passing	Environment (36)	Pass env vars to remote shell
Encryption	Encryption (38)	Encrypted data transmission (rare)

The terminfo/termcap System:

After terminal type exchange, the server needs to know what escape sequences the terminal understands. Unix systems use the terminfo (or older termcap) database:

Contains entries for hundreds of terminal types
Each entry lists capabilities: cursor movement, screen clear, colors
Applications query terminfo to get escape sequences
Programs like ncurses provide portable terminal I/O

For example, when vim needs to clear the screen on a VT100, it queries terminfo for the "clear" capability of VT100, receives "\033[2J", and sends that sequence.

TERM Environment Variable

NVT's Design Legacy

Pattern 1: Canonical Representation

The idea of converting diverse local formats to a standard network format appears everywhere:

MIME email: Various character sets encoded to quoted-printable or base64
HTTP: Character encoding declared in headers, content follows
JSON/XML: Unicode-based interchange formats for structured data
Video streaming: Source formats transcode to standard codecs

Each follows NVT's insight: define a common language, translate at edges.

Pattern 2: Negotiated Capabilities

Telnet's WILL/WONT/DO/DONT mechanism influenced:

SSL/TLS: Cipher suite negotiation
HTTP: Accept headers for content negotiation
SIP: Media capability negotiation for VoIP
SMTP: EHLO extension advertisement

The principle of discovering common ground without prior coordination proves universally valuable.

Pattern 3: Graceful Degradation

NVT's minimal baseline ensures basic functionality even without advanced features:

HTTP: Works without cookies, JavaScript, even CSS
Email: Plaintext fallback when MIME fails
Video: Lower resolutions when bandwidth limited

Designing for baseline capability with optional enhancement creates robust, widely deployable systems.

Protocols Influenced by NVT Design

•SSH — Uses similar pseudo-terminal architecture, terminal type exchange, window size handling
•SMTP — Extended with EHLO capability advertisement, CR LF line endings from NVT
•HTTP — Uses CR LF line endings, stateless baseline with extension headers
•FTP — NVT-ASCII mode for text transfers, option negotiation for features
•IRC — Text-based protocol with NVT conventions for line endings
•Serial console protocols — Continue the terminal abstraction for physical devices

A Pattern Language for Protocols

Summary: The Network Virtual Terminal

Key Takeaways

•NVT solved the terminal heterogeneity problem — Creating a common language for diverse terminal types to intercommunicate
•NVT uses 7-bit ASCII with specific control characters — BEL, BS, HT, LF, VT, FF, CR have defined meanings
•CR LF is the mandatory line ending — Regardless of local conventions, all lines end with CR (13) followed by LF (10)
•Translation occurs at endpoints — Complexity pushed to edges, network carries standardized format
•Default operation is minimal — Line-at-a-time, half-duplex, remote echo—ensuring universal baseline
•Options extend beyond NVT baseline — Terminal type, binary mode, window size enable rich sessions
•NVT patterns influenced protocol design — Canonical representation, negotiation, graceful degradation appear throughout Internet protocols

What's Next:

Page Complete

3 / 5