Summary

  • RFC 1079’s TERMINAL-SPEED option made a remote terminal characteristic available only after negotiated permission and an explicit request.
  • The reply could guide display-related choices, but it did not establish a network-path fact or authorize a change to TCP, routing, or service policy.

A number with a deliberately small job

Early terminal software had to accommodate physical devices whose behavior was visibly shaped by line speed. A program that sent a full screen at the rhythm suitable for one terminal could make another feel unusable. RFC 1079 starts from that practical world: operating systems often kept the bit rate of directly attached terminals and modems, and used it for timing-dependent display processes such as delay padding. Some interfaces were also arranged differently for fast and slow terminals.

The RFC did not propose that Telnet discover the network. It proposed that comparable terminal information be made available across a Telnet connection. That choice matters because the same numeral can look much more authoritative than it is. 9600,100 resembles a measurement. In RFC 1079 it is an NVT ASCII statement supplied by one peer about transmit and receive terminal speeds. It is not a probe, a sampled throughput result, a statement by an intervening router, or a promise about what the TCP connection will deliver next.

The distinction is not pedantry. A terminal-facing program can decide that a conservative presentation is preferable after receiving a value. Another layer would still have to observe retransmissions, flow control, current application state, or the user’s actual response if those facts mattered. A display hint may be useful precisely because it does not claim to settle all of those questions.

Permission was separate from the value

RFC 854 gave Telnet a general grammar for optional conventions. The Network Virtual Terminal remains the common fallback; WILL, WON'T, DO, and DON'T let peers agree, or decline to agree, to use something richer. RFC 1079 applies that grammar to option 32, TERMINAL-SPEED.

Its default is telling: WON'T TERMINAL-SPEED and DON'T TERMINAL-SPEED. Nothing is exchanged unless the peers move away from that default. A WILL says a peer is willing to send terminal-speed information in a later subnegotiation. A DO says a peer is willing to receive it. Neither command is itself a report. They open a narrow possibility for a later conversation.

Only after both commands have appeared may the sender of DO TERMINAL-SPEED ask with IAC SB TERMINAL-SPEED SEND IAC SE. Only the sender of WILL TERMINAL-SPEED may answer with IAC SB TERMINAL-SPEED IS ... IAC SE. The information may not arrive spontaneously. This is a small but consequential allocation of agency: one side grants and issues the request; the other side supplies a requested characteristic. No third party becomes an oracle, and no bare willingness token becomes a performance result.

RFC 1079 requires the actual response to be an NVT ASCII pair of decimal transmit and receive speeds, separated by a comma, with no leading zeroes or extraneous spaces. That strict form supports interoperable parsing. It does not turn the syntax into proof that the represented equipment, intervening path, or display behavior is accurate. A well-formed string is evidence of a conforming exchange grammar, not a universal evidence ledger.

The RFC’s own advice stays local

The implementation suggestion makes the boundary even clearer. A system may only offer a discrete set of locally supported terminal speeds. If it receives another value, RFC 1079 suggests choosing the nearest allowed one in a safe direction. For padding, it says rounding upward can be safer because excess padding is preferable to too little.

That is an instruction about a program’s local response to supplied metadata. It is not an instruction to reshape the line, reserve bandwidth, reconfigure a modem, slow a router, or infer congestion. The operating choice remains local and reversible. A program can retain the original string, record the value it selected, and revise its display behavior on a later request without claiming that it has controlled the network beneath the Telnet stream.

RFC 930, the terminal-type option that RFC 1079 names as its model, offers a useful nearby comparison. It uses the same separation between permission and a later SEND/IS exchange, and says that transmitting terminal type does not immediately imply a processing change. The two options differ in their payloads, but they share an engineering discipline: status information can inform a remote program without becoming a command over every layer involved in a session.

What the value cannot settle

A received 1200,1200 can support a claim that one Telnet participant sent those ASCII characters in the defined exchange. It does not prove that the terminal is physically attached at that speed, that a modem is synchronized, that the TCP path has the same capacity, that packets are not being lost, that the user sees the intended screen, or that a service interaction succeeded. It does not identify a person or terminal, authorize an action, or establish the current use of Telnet on a particular network.

Keeping these boundaries visible prevents a familiar escalation. A local characteristic becomes a number; a number becomes a supposed measurement; a supposed measurement becomes a reason to dictate transport or operational policy. RFC 1079 supplies none of those later transitions. It supplies an optional, requested, parseable item of terminal metadata. Any broader claim needs its own observation, authority, and evidence.

Sources and evidence boundary

The frozen source set is RFC 1079, RFC 854, RFC 930, and RFC 1123. RFC 1079 supplies the option’s motivation, commands, defaults, response syntax, and local implementation suggestion. RFC 854 supplies the Telnet NVT and negotiation framework. RFC 930 supplies the historical request/response comparison, and RFC 1123 situates RFC 1079 among Telnet references. None establishes current deployment, a named implementation, link capacity, path performance, identity, authorization, accessibility, or application outcome.