Summary

  • RFC 1073 assigned the client authority over its window size and let it report width and height together, including later changes. The report was explicitly advisory: a server could accept NAWS and still ignore the values.
  • DO/WILL established permission to use the option; the four-byte subnegotiation carried client-stated character geometry; an operating-system update, child notification and application reformat were separate downstream events. None proved pixels, identity or what a person saw.

The Telnet base specification began with an imaginary Network Virtual Terminal whose printer width and page length were unspecified. That modest default made unlike systems interoperable, but it did not tell a screen-oriented application how many character cells were available. By 1988, a Telnet client increasingly lived inside a resizable graphical window rather than standing for one fixed physical terminal.

RFC 1073 addressed that mismatch with NAWS, Negotiate About Window Size, option 31. Its key design choice was not merely a larger number. It changed who controlled the fact. The client had total control of its local window and told the server its current geometry. The server retained control of admission and use.

Permission came before the report

Telnet options used a small symmetric vocabulary. A server could send DO NAWS; a client willing to provide geometry answered WILL NAWS. Either side could refuse with DON'T or WON'T. The option framework treated this first exchange as the gate to a richer subnegotiation, not as the rich information itself.

That distinction prevents a common evidentiary shortcut. DO plus WILL proves that the peers entered an option state. It does not prove that a width and height were later sent. It certainly does not prove that a server stored them, changed a terminal driver, notified a process or reformatted output.

After agreement, the client could send IAC SB NAWS, two bytes of width, two bytes of height and IAC SE. Both dimensions used Internet byte and bit order and described characters, not pixels. A value could reach 65,535. Because Telnet reserved octet 255 as IAC, any 255 occurring inside those four data bytes had to be doubled. The grammar was small, but it still depended on correct framing and unescaping before a number existed.

Zero was not a zero-sized window. It meant the corresponding dimension was not being supplied. The server then chose an operating-system-specific assumption, perhaps informed by separately exchanged terminal-type information. A stored zero therefore carried explicit uncertainty. Converting it into “zero columns” would destroy the meaning the protocol preserved.

A resize produced another statement, not an acknowledgement

RFC 1073 allowed the client to send the subnegotiation again whenever its window changed. Its worked example moved from 80 by 24 characters to 80 by 64. No new DO/WILL exchange was required. The local resize created new evidence, and the client could put that evidence into the existing Telnet stream.

The second report did not acknowledge the first. It did not state that the server had acted on either value. Nor did the option define a success response for a child program's reaction. On a busy path, an observer could therefore see three different times: the local window changed, the NAWS bytes arrived, and a remote application later rendered under some geometry. Calling all three “the resize” would conceal delay and failure.

The memo was unusually direct about the server's freedom. Window-size information was advisory. A server might accept NAWS but not use the submitted data. Some operating systems could not update terminal size after the session began. In that case the server could send DON'T NAWS after initially accepting the option and forbid further reports. The client window could keep changing while the network conversation deliberately stopped describing it.

This was not a contradiction. It was a division of control. The client controlled the object being described. The server controlled whether it wanted reports and whether its local stack could make use of them.

NAWS displaced a misleading bidirectional model

Earlier Telnet options separately negotiated output line width and output page size. RFC 1073 argued that NAOL and NAOP had the wrong semantics for graphical windows. They were bidirectional, suggesting that a server might control a client's line width or page size, and each axis was limited to 253 characters. They were also not in common use according to the contemporary record cited by the memo.

NAWS sent width and height together because window systems normally changed them together. More importantly, it stopped calling client geometry a bargain between equal controllers. The client reported local state; the server decided how to react. A protocol often becomes clearer not by adding power, but by refusing to assign power to the wrong actor.

The distinction also protects interpretation. The server could request use of the option, but it could not resize the local graphical window through NAWS. The client's report described character-cell capacity, not physical monitor dimensions. A value of 300 by 24 in the RFC's example was a valid character layout, not evidence of an unusually wide piece of glass.

Type, speed and geometry remained separate facts

The nearby Telnet options are useful precisely because they do not collapse into one “terminal profile.” RFC 930 defined a server-requested terminal-type exchange and stated that receipt did not immediately imply a processing change. RFC 1091 later allowed a client to cycle through available emulation modes, while preserving the server's role in asking for them.

RFC 1079 assigned option 32 to terminal speed. After permission, the requester asked for an ASCII transmit/receive-rate pair; the peer did not send speed spontaneously. An implementation might round an unsupported rate in a safe direction. NAWS did something different: after permission, the client could report each local resize without being asked again, and the values were binary axes rather than a speed string.

Terminal type could help a server choose a fallback when NAWS supplied zero for one axis. That did not make type a geometry measurement. Speed could guide padding or interface choices. That did not make speed a window dimension. The protocol family kept each claim narrow enough that a receiver could know which local policy it was applying.

The IANA Telnet Options registry still places NAWS at 31 and TERMINAL-SPEED at 32. The registry proves code assignment and document provenance. It does not prove that a present service implements either option, that an implementation follows the RFC, or that any particular session used it.

One four-byte report crossed several local authorities

RFC 1073's implementation sketch shows why receipt was not outcome. A graphical environment first informed the Telnet client that its window had changed. On 4.3BSD, the client might catch SIGWINCH. The client then sent NAWS. A server might use an ioctl to change its terminal state and might signal a child process, probably a shell.

Every verb in that chain was conditional. The window manager, Telnet client, network parser, server terminal layer and child application owned different transitions. A trace at one boundary could not certify the next. Even a child that received a signal might retain cached layout state or format output before processing it. Correctly formatted bytes still could not prove that a human saw them.

This layered account is more durable than a success flag. It tells an operator where to look when a remote screen wraps incorrectly: option state, raw report, escaping, stored geometry, child notification and application behavior are independently testable.

Sources and limits

RFC 1073 documents a proposed 1988 option and a contemporary implementation example. It does not establish universal adoption, present deployment, product conformance or direct descent into SSH pseudo-terminals, responsive web design or remote-desktop systems. RFCs 854 and 855 explain the surrounding Telnet grammar; RFCs 930, 1079 and 1091 establish adjacent status exchanges, not proof that NAWS was applied.

The historical lesson is narrower. A report can be valuable without commanding its recipient. NAWS made changing geometry portable by saying who owned the window, who could refuse the conversation, what zero meant and where the evidence stopped. Four bytes described a client state. The reaction remained local.