SUPDUP extensions: Recent extensions to the SUPDUP Protocol
Optional SUPDUP negotiation fields for graphics capabilities and terminal line speeds.
Crispin, M.R., "Recent extensions to the SUPDUP Protocol", RFC 747, DOI 10.17487/RFC0747, March 1978, <https://www.rfc-editor.org/info/rfc747>.
@misc{rfc747,
series = {Request for Comments},
number = 747,
howpublished = {RFC 747},
publisher = {RFC Editor},
doi = {10.17487/RFC0747},
url = {https://www.rfc-editor.org/info/rfc747},
author = {M.R. Crispin},
title = {{Recent extensions to the SUPDUP Protocol}},
pagetotal = 1,
year = 1978,
month = mar,
} RFC text
NWG/RFC# 747 MRC 21-MAR-78 44015 Recent Extensions to the SUPDUP Protocol Network Working Group Mark Crispin Request for Comments 747 SU-AI NIC 44015 21 March 1978 Updates: RFC 734. See also RFC 746. Recent Extensions to the SUPDUP Protocol Recently, some extensions have been made to the SUPDUP protocol. RFC 746, by Richard Stallman, documented the SUPDUP graphics extension. In addition, a TTYOPT bit has been added and two more variables have been added to the initial negotiation. This RFC describes the changes from RFC 734, but excludes the detailed information in RFC 746. These extensions are upwards and downwards compatable, and are completely optional. For most SUPDUP user and server programs, RFC 734 remains an adequate description of the protocol. However, it is suggested that if the console's line speed is known, the user SUPDUP should be modified to send the new ISPEED and OSPEED variables (sending 0 for SMARTS if the graphics extension is not to be used) so the server can handle buffering for the terminal better. Since these changes are compatable and optional, and since the SUPDUP protocol is being actively worked on at the present time, I have elected to issue this update RFC rather than an updated version of RFC 734. An updated 734 will be issued when the protocol stabilizes again. Three new variables have been added to the initial negotiation. In order, they are SMARTS, ISPEED, and OSPEED. Consequently, the count should now be -10,,0, or, in octal, 777770000000. The SMARTS variable specifies what "smarts" (in general, what graphics capabilities) the terminal has. Like the TTYOPT variable, a bit being true implies that the terminal has this option. RFC 746 describes this variable and the SUPDUP graphics option in complete detail. If the graphics extension is not to be used, SMARTS should be set to 0. The ISPEED and OSPEED variables are respectively the input and output baud rates of the terminal, if known. For example, a 150./1200. baud terminal would have an ISPEED of 150. and an OSPEED of 1200. A speed of zero means the line speed is indeterminate. The %TPPRN TTYOPT bit (value 0,,200) has been added. This bit specifies that the system should swap parenthesis with square brackets on input. This is often desirable for LISP users who are using a terminal which has parenthesis as a shift character but not square brackets. This bit is normally off and servers are not required to implement it. -1-
ISO Plain Language
On this page
§1Optional Additions to SUPDUP
RFC 747 describes changes to the SUPDUP protocol specified in RFC 734, including the graphics extension documented in RFC 746. The author says the extensions are optional and compatible with older and newer programs; RFC 734 remains an adequate description for most SUPDUP user and server programs.
The update adds three variables to initial negotiation, in the order SMARTS, ISPEED and OSPEED. The variable count is now -10,,0, or 777770000000 in octal.
The additions are optional, so programs can continue using the earlier SUPDUP description. Newer programs can send extra details during startup negotiation.
§2SMARTS and Terminal Speeds
SMARTS describes terminal capabilities, especially graphics capabilities. If the graphics extension is not being used, SMARTS should be set to zero. RFC 746 describes the variable and graphics option in detail.
ISPEED and OSPEED report the terminal's input and output baud rates when known. A value of zero means the line speed is indeterminate. The RFC suggests sending these variables when the console line speed is known so the server can handle terminal buffering better.
SMARTS tells the server what the terminal can do. ISPEED and OSPEED tell it how fast input and output travel, or use zero when the speed is unknown.
§3Parenthesis and Bracket Mapping
The RFC adds the %TPPRN TTYOPT bit, with value 0,,200. When enabled, the system swaps parentheses with square brackets on input.
The author notes that this can help LISP users whose terminal has parentheses as a shifted character but does not have square brackets. The bit is normally off, and servers are not required to implement it.
The optional bit swaps parentheses and square brackets as the user types. It is intended for terminals where square brackets are not directly available.