Sent by the Telnet client to suggest that NAWS be used.
IAC WON'T NAWS
Sent by the Telnet client to refuse to use NAWS.
IAC DO NAWS
Sent by the Telnet server to suggest that NAWS be used.
IAC DON'T NAWS
Sent by the Telnet server to refuse to use NAWS.
IAC SB NAWS <16-bit value> <16-bit value> IAC SE
Sent by the Telnet client to inform the Telnet server of the window width and height.
The window size information is conveyed via this option from the Telnet client to the Telnet server. The information is advisory. The server may accept the option, but not use the information that is sent.
The client and server negotiate sending the window size information using the standard Telnet WILL/DO/DON'T/WON'T mechanism. If the
Waitzman [Page 1]
RFC 1073 Telnet Window Size Option October 1988
client and server agree, the client may then send a subnegotiation to convey the window size. If the client's window size is later changed (for instance, the window size is altered by the user), the client may again send the subnegotiation. Because certain operating systems, on which a server may be executing, may not allow the window size information to be updated, the server may send a DON'T NAWS to the client to forbid further subnegotiation after it was initially accepted. A negotiation loop will not form following these rules.
The subnegotiation consists of two values, the width and the height of the window in characters. The values are each sent as two bytes, in the Internet standard byte and bit order. This allows a maximum window width or height of 65535 characters. A value equal to zero is acceptable for the width (or height), and means that no character width (or height) is being sent. In this case, the width (or height) that will be assumed by the Telnet server is operating system specific (it will probably be based upon the terminal type information that may have been sent using the TERMINAL TYPE Telnet option).
The syntax for the subnegotiation is:
IAC SB NAWS WIDTH[1] WIDTH[0] HEIGHT[1] HEIGHT[0] IAC SE
As required by the Telnet protocol, any occurrence of 255 in the subnegotiation must be doubled to distinguish it from the IAC character (which has a value of 255).
This option does not assume any default window size information. Often the terminal type, passed with the TERMINAL TYPE Telnet option, may imply a window size, but that is not necessary for this option.
With the increasing popularity of windowing systems, a Telnet client is often run inside a variable-sized window, and the Telnet server needs to know the window size for proper cursor control. The window may also have its size changed during the Telnet session and the updated window size needs to be conveyed to the server. This memo specifies an option to send the window height and width in characters from a client to a server.
Waitzman [Page 2]
RFC 1073 Telnet Window Size Option October 1988
The Telnet options Negotiate Output Line Width (NAOL) and Negotiate Output Page Size (NAOP) do not have the correct semantics for this purpose, and they are not in common use [see RFC-1011 "Official Internet Protocols", and the "Defense Protocol Handbook"]. The NAOL and NAOP options are bidirectional (i.e., the server might control the client's line width or page size), and are limited to 253 characters in each axis.
This option is a better model of the normal window negotiation process. The client has total control over the size of its window and simply tells the server what the current window size is. Furthermore, the 253 character height and width limitation is too low so the new option has a limit of 65535 characters. Finally, this option sends the window height and width concurrently because they are typically changed simultaneously and many operating systems and windowing applications prefer to think in terms of simultaneous changes in height and width.
A typical user of this option might be a Telnet client running under X. After a user resizes the client's window, this must be communicated to the Telnet client. In 4.3 BSD Unix, the signal SIGWINCH (window changed) might be caught by the Telnet process and a new NAWS subnegotiation sent to the server. Upon receipt of a NAWS subnegotiation, the server might do the appropriate ioctl to handle the new information, and then could send a SIGWINCH to its child, probably a shell.
A more elaborate, X window system specific, version of this option has been implemented at Carnegie-Mellon University by Glenn Marcy and the author. It is widely used in the Carnegie-Mellon University Computer Science Department. Mr. Marcy helped write an early draft of this memo documenting the more elaborate option.