Network Working Group J. Rekhter Request For Comments: 1041 T.J. Watson Research Center, IBM January 1988
This RFC specifies a proposed standard for the Internet community. Hosts on the Internet, that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard. Distribution of this memo is unlimited.
IAC WILL 3270-REGIME
Sender is willing to send list of supported 3270 Regimes in a subsequent sub-negotiation.
IAC WON'T 3270-REGIME
Sender refuses to send the list of supported 3270 Regimes.
IAC DO 3270-REGIME
Sender is willing to receive a list of supported 3270 Regimes in a subsequent sub-negotiation.
IAC DON'T 3270-REGIME
Sender refuses to accept the list of supported 3270 Regimes.
IAC SB 3270-REGIME ARE REGIME-LIST IAC SE
Sender sends the list of all possible 3270 Regimes it is able to support. The code for ARE is 1.
REGIME-LIST is an ASCII string which has meaning to both sides of the negotiation. This string may be composed of different terminal type names (as specified in the "Assigned Numbers") which are separated by space character. Terminal type names which have
imbedded spaces should escape it with backslash character ('\'). Backslash character imbedded into terminal type name should be escaped with another backslash character.
Empty REGIME-LIST means, that sender is able to support only NVT ASCII terminal as defined in .
IAC SB 3270-REGIME IS REGIME IAC SE
Sender is stating the name of the terminal it is willing to support. The code for IS is 0.
REGIME is an ASCII string (possibly empty) which is substring of the received REGIME-LIST string. Empty string means that the sender is willing to support only NVT ASCII terminal as defined in .
3270 Regime will not be established.
3270 Regime will not be established.
This option allows a telnet server running VM or MVS to negotiate with the telnet client on the type of data stream (3270 or NVT ASCII) which both sides are willing support.
The main reason for this option is to allow simple and efficient way to:
Support for 3270 data stream requires that both sides:
Current implementations requires 3 different options, TERMINALTYPE , BINARY  and EOR , to be successfully negotiated between client and server prior to establishing 3270 Regime. Moreover, it is unclear at what point in this negotiation process, 3270 regime is actually established (whether after TERMINALTYPE or after BINARY or after EOR). Also, order for these negotiations was never specified.
Subnegotiation for the TERMINALTYPE is possible with only single terminal type at a time.
Once 3270 Regime is established, there is no standard of how to get out of this regime back into NVT ASCII mode.
Based on the 3270 Regime requirements, which stated above, we feel that separate negotiation for EOR and BINARY should not be done. Rather, 3270 Regime establishment should imply that:
By providing the list of possible terminals which Telnet client can support, telnet server could select the type of the terminal it can support and pass it back to the Telnet client, thus eliminating multiple TERMINALTYPE negotiations.
As stated in , "The purpose of the Telnet Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communication facility." Therefore we feel that such issues as color support, graphics support, extended data streams mapping, etc., do not belong logically to the Telnet protocol, but rather should be considered as a part of a separate protocol which defines 3270 inbound/outbound data stream (see , , , ). The purpose of this memo is
not to describe (or define) protocols which are used in 3270 Regime, but rather define a new option for the Telnet Protocol, which would allow both sides to negotiate for the 3270 Regime establishment over the telnet connection.
While this options does not include direct negotiation for such things as colors, graphics, structured fields, etc., certain features (like the ability to support colors) may be negotiated indirectly by using certain terminal type names specified in 3270-REGIME subnegotiation.
We also feel that such issues as keyboard mapping, whether to have one telnet for both ASCII and 3270 mode or two separate programs, one for ASCII and another for 3270 mode, are implementation dependent and should be considered as a local matter.
WILL and DO commands are used to obtain and grant permission for the
subsequent subnegotiation. Both sides must exchange WILL 3270-REGIME
and DO 3270-REGIME prior to subnegotiation. The actual exchange of
information is done within the option subcommand (IAC SB
Either Telnet client or Telnet server can initialize 3270-REGIME negotiation. However, in order to simplify negotiation, only Telnet client is allowed to send IAC SB 3270-REGIME ARE... IAC SE command, and only Telnet server is allowed to reply with IAC SB 3270-REGIME IS... IAC SE command.
Since this negotiation is asymmetric, each time Telnet client/server decide to negotiate/renegotiate this option they have to perform complete negotiation process (DO... WILL... SB 3270-REGIME...).
The following is an example of use of the option:
If the side is able to support more that one terminal type, then terminal type names are listed in REGIME-LIST from most desirable to least desirable. Other side upon receive of the REGIME-LIST scans it from left to right and finds the first terminal type which it is able to support returns it in REGIME part of the 3270-REGIME IS subnegotiation.
The side which wants to switch into NVT ASCII mode should send empty REGIME-LIST. Since empty string is a subset of empty string, the side which receives empty REGIME-LIST should reply with empty REGIME. At that point both sides are switched to NVT ASCII mode.
It is possible to renegotiate 3270 Regime parameters (like terminal type). Certain precaution should be taken to insure that such renegotiation would not cause switch into NVT ASCII mode. As a possible measure, the side which wants to renegotiate for another terminal should include both the current and the new terminal type names into REGIME-LIST. This way, if the other side is unable to change 3270 Regime terminal type, it will continue to use current terminal type.
Since IAC character (255 decimal) is used as a delimiter (together with EOR) in inbound/outbound data stream, care must be taken to escape IAC characters which are part of data stream itself with another IAC character.
To prevent ambiguity in interpreting inbound/outbound data stream during negotiation process the following rules should be observed:
to the Telnet client.
 RFC-854, Telnet Terminal Type Option.
 RFC-856, Telnet Binary Transmission.
 RFC-885, Telnet End Of Record Option.
 RFC-854, Telnet Protocol Specification.
 IBM 3270 Information Display System. 3274 Control Unit Description and Programmer's Guide. GA23-0061-1.
 IBM 3279 Information Display System: Color and Programmed Symbols. GA33-3056-1.
 IBM 3270 Information Display System. Data Stream Programmer's Reference. GA23-0059-1.
 IBM 3270 Information Display System. Description and Configuration: APL/Text Feature. GA18-2044-0.