Connected: An Internet Encyclopedia
RFC 1123 - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1123
Up: 3. REMOTE LOGIN -- TELNET PROTOCOL
Up: 3.2 PROTOCOL WALK-THROUGH
Prev: 3.2.4 Telnet
Next: 3.2.6 Telnet Command Structure: RFC-854, p. 13

### 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11

In NVT mode, a Telnet SHOULD NOT send characters with the high-order bit 1, and MUST NOT send it as a parity bit. Implementations that pass the high-order bit to applications SHOULD negotiate binary mode (see Section 3.2.6).

DISCUSSION:

  Implementors should be aware that a strict reading of RFC-854 allows a client or server expecting NVT ASCII to ignore characters with the high-order bit set. In general, binary mode is expected to be used for transmission of an extended (beyond 7-bit) character set with Telnet.

  However, there exist applications that really need an 8- bit NVT mode, which is currently not defined, and these existing applications do set the high-order bit during part or all of the life of a Telnet connection. Note that binary mode is not the same as 8-bit NVT mode, since binary mode turns off end-of-line processing. For this reason, the requirements on the high-order bit are stated as SHOULD, not MUST.

  RFC-854 defines a minimal set of properties of a "network virtual terminal" or NVT; this is not meant to preclude additional features in a real terminal. A Telnet connection is fully transparent to all 7-bit ASCII characters, including arbitrary ASCII control characters. For example, a terminal might support full-screen commands coded as ASCII escape sequences; a Telnet implementation would pass these sequences as uninterpreted data. Thus, an NVT should not be conceived as a terminal type of a highly-restricted device.

Next: 3.2.6 Telnet Command Structure: RFC-854, p. 13

Connected: An Internet Encyclopedia
RFC 1123 - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11