Summary

  • RFC 1116 moved Telnet line editing and some signal handling to the client. That cut per-keystroke traffic and gave the user local response on long-delay or per-packet-priced networks.
  • DO/WILL consent, MODE_ACK and SLC_ACK closed different configuration loops. None acknowledged that a command line had reached an application, been authorized, run or produced a result.
  • EDIT held an editable buffer until a terminator or forwarding condition released it. Once sent, that prefix could no longer be changed locally; it still had to cross transport, Telnet parsing and remote process decisions.

The fast response lived on the near side

RFC 1116 opened with a practical measure of distance. Character-at-a-time Telnet could consume a couple of packets for every key. With local editing enabled, Linemode aimed for a couple per command line. A user on a long-delay path saw keys and corrections immediately, then paid the network delay only after finishing the line. Networks that charged per packet supplied a second incentive, and front-end processing spared supercomputers from handling isolated characters.

This was not merely compression. Work moved. The client-side terminal machinery could erase a character, erase a line, trap a signal and assemble a coherent unit before the server saw the unit. The interface became smoother precisely because visible interaction stopped being a continuous observation of the remote process.

The current RFC Editor record keeps the August 1989 proposal and its obsolescence relation. The IETF Datatracker record preserves the standards-history metadata. In October 1990, RFC 1184 replaced RFC 1116, added mode bits and visual-editing characters, and retained the client-side editing design. The historical claim belongs to that sequence, not to an assertion about current use.

Permission to negotiate was not the negotiated mode

Linemode used Telnet option 34. The general option grammar in RFC 855 separates two steps: the peers first agree with DO and WILL that an option may be discussed, then exchange its parameters in subnegotiation. Either side can end that permission with DONT or WONT.

RFC 1116's default was WONT LINEMODE and DONT LINEMODE. A TCP connection, a Telnet greeting or the registry number therefore said nothing about active local editing. Even a successful DO/WILL pair established only permission to negotiate editing and signalling state.

MODE carried the next state. Under ordinary operation, the server initiated a mask and the client confirmed it. EDIT located line processing; TRAPSIG located interpretation of characters associated with interrupt, break, abort, end-of-file or suspend. MODE_ACK made the two Telnet processes settle on the same mask. It did not refer to the user's next line and could not attest to an application behind the server.

The distinction matters in logs. “Linemode accepted,” “EDIT active” and “remote command completed” are not increasingly detailed descriptions of one event. They are evidence from different state machines.

A complete line was a local object

With EDIT set, the client processed the user's input and sent completed lines. RFC 1184 described the ordinary boundary concretely: after local editing, CR LF or another special character caused the edited data to be sent. Before that point, the user could still change the buffer without asking the remote host to undo anything.

FORWARDMASK complicated the simple picture. The server could ask the client to release buffered input when selected ASCII characters appeared. SLC_FORW1 and SLC_FORW2 supplied two more forwarding characters. A client whose terminal driver could not express the exact requested set was allowed to accept a broader control-character set and forward on that.

The result was deliberate local discretion inside an agreed envelope. A line terminator was not the only boundary, and the server's requested mask did not always enumerate the client's exact release points. RFC 1184 supplied the irreversible fact: once data was forwarded, the forwarded portion could no longer be edited.

Irreversible locally did not mean effective remotely. The bytes still had to leave the client, traverse TCP, reach the Telnet receiver, survive option/control parsing, enter the attached process, meet that process's syntax and policy, and produce output. The local editor owned none of those later observations.

Acknowledging a character map did not acknowledge its effect

The Set Local Characters, or SLC, suboption negotiated triplets: a function, modifiers and the ASCII character assigned to it. The support level could mean not supported, supported but unchangeable, explicitly valued or defaulted. SLC_ACK meant that the receiver agreed to the setting.

That acknowledgement was easy to overread. It closed a configuration disagreement about which local character represented a function. It did not say that the user had pressed that character. If pressed, it did not say the corresponding Telnet command arrived. If it arrived, it did not prove that the attached system supported or completed the action.

RFC 1184 made the final boundary visible. ABORT and IP might share an effect on a system with only one interruption method. Unsupported ABORT, EOF or SUSP functionality could simply be ignored. SLC_FLUSHIN and SLC_FLUSHOUT were advisory, and the user interface could override the suggested flush behavior. A named signal was a request in a protocol context, not a durable record that a process stopped or bytes disappeared.

Echo and flow kept their own authorities

RFC 857 explains why a character appearing on the screen is weak remote evidence. The Echo option coordinates whether one side echoes for the other. It does not control whether a system echoes for itself. Linemode could therefore present an immediate local response while the network path remained silent.

Flow control also looked adjacent and stayed separate. RFC 1116 and RFC 1184 did not absorb FLOW into the Linemode mask; they used the Telnet Remote Flow Control option defined by RFC 1080. That option governed whether local terminal-output XON/XOFF handling could be toggled after separate consent. It was not keyboard editing, application suspension, TCP flow control or congestion.

This modularity prevented one convenient status bit from claiming a whole terminal. Editing location, echo location, special-character mapping, output-flow consumption and remote process behavior had distinct owners.

The missing acknowledgement belonged to the application

The IANA Telnet Options registry still assigns 34 to Linemode and cites RFC 1184. That row tells parsers what an option number names. It does not show that a current session negotiated the option, that an implementation conforms or that any command ran.

RFC 854 supplies Telnet's NVT and control-command substrate. It can carry data and signals to the remote Telnet process. Linemode can make the client efficient and can make configuration state converge. Neither specification turns transport evidence into application evidence.

A defensible record therefore keeps the last part explicit. Client buffer complete. Prefix forwarded. TCP accepted bytes locally. Server Telnet decoded them. Remote process received a line. Policy admitted it. Execution began. Execution ended. Output returned. The user associated that output with the line. Each statement needs its own observation.

The point is not that local interfaces deceive. Linemode succeeded by making a useful local fact feel immediate. The error begins when an institution stores that fact under a remote-result name.

Sources