Telnet 3270 regime option
A Telnet option that lets a client and server agree on a 3270 terminal type in one negotiation.
Rekhter, Y., "Telnet 3270 regime option", RFC 1041, DOI 10.17487/RFC1041, January 1988, <https://www.rfc-editor.org/info/rfc1041>.
@misc{rfc1041,
series = {Request for Comments},
number = 1041,
howpublished = {RFC 1041},
publisher = {RFC Editor},
doi = {10.17487/RFC1041},
url = {https://www.rfc-editor.org/info/rfc1041},
author = {Y. Rekhter},
title = {{Telnet 3270 regime option}},
pagetotal = 6,
year = 1988,
month = jan,
} RFC text
Contents
Network Working Group J. Rekhter
Request For Comments: 1041 T.J. Watson Research Center, IBM
January 1988
Telnet 3270 Regime Option
STATUS OF THIS MEMO
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.
1. Command Name and Code
3270-REGIME 29
2. Command Meaning
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 [4].
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
[4].
3. Default
WON'T 3270-REGIME
3270 Regime will not be established.
DON'T 3270-REGIME
3270 Regime will not be established.
4. Motivation for the option
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:
o state, that both client and server want to exchange 3270 data
stream,
o switch from 3270 Regime into NVT ASCII Regime and back into 3270
Regime,
o dynamically renegotiate 3270 Regime parameters (like terminal
type).
Support for 3270 data stream requires that both sides:
o be able to exchange binary data,
o be able to put well defined delimiters into inbound/outbound
data stream,
o be able to establish the agreement between client and server on
what type of terminal will be used.
Current implementations requires 3 different options, TERMINALTYPE
[1], BINARY [2] and EOR [3], 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:
o each character in the Telnet data stream should be interpreted
as 8 bits of binary data,
o both sides agreed to use a certain character sequence(Telnet IAC
EOR) as a delimiter in inbound/outbound Telnet data stream,
o both sides agreed on the type of the terminal they are willing
to support.
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 [5], "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 [5], [6], [7], [8]). 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.
5. Description of the Option
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
3270-REGIME).
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:
1. Host A: IAC DO 3270-REGIME
2. Host B: IAC WILL 3270-REGIME
3. Host B: IAC DO 3270-REGIME
4. Host A: IAC WILL 3270-REGIME
5. (At this point side which runs Telnet client can start
subnegotiation.)
6. Host A: IAC SB 3270-REGIME ARE 'ibm3279-3 ibm3279-2 ibm3278-3'
IAC SE
7. Host B: IAC SB 3270-REGIME IS 'ibm3279-2' IAC SE
6. Implementation Suggestions
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:
1. Telnet client should not accept any data from the user as soon
as it enters 3270 Regime negotiation.
2. Telnet client should not send any data to the Telnet server
after it sends "3270-REGIME ARE....".
3. Telnet server should try not to send any data to the telnet
client while negotiation is in progress.
4. Telnet server may reply with "3270-REGIME IS..." to the telnet
client only after all outstanding data have been already sent
to the Telnet client.
5. Telnet server can switch from its previous regime to the new
regime only after it sends "IAC SB 3270-REGIME IS 'regime' IAC
SE" to the telnet client.
6. Telnet client can switch from its previous regime to the new
regime only after it receives "IAC SB 3270-REGIME IS 'regime'
IAC SE".
7. Switch from one regime to another may require flushing of all
outstanding data in both telnet client and telnet server.
7. References
[1] RFC-854, Telnet Terminal Type Option.
[2] RFC-856, Telnet Binary Transmission.
[3] RFC-885, Telnet End Of Record Option.
[4] RFC-854, Telnet Protocol Specification.
[5] IBM 3270 Information Display System. 3274 Control Unit
Description and Programmer's Guide. GA23-0061-1.
[6] IBM 3279 Information Display System: Color and Programmed
Symbols. GA33-3056-1.
[7] IBM 3270 Information Display System. Data Stream Programmer's
Reference. GA23-0059-1.
[8] IBM 3270 Information Display System. Description and
Configuration: APL/Text Feature. GA18-2044-0.
AI ELI5
On this page
§1Why a 3270 Regime Option
RFC 1041 lets a Telnet server on VM or MVS negotiate with a Telnet client whether to use the 3270 data stream or plain NVT ASCII. Before it, 3270 support needed three options negotiated together: TERMINALTYPE, BINARY and EOR. The order was never specified, it was unclear when 3270 mode was actually in effect, TERMINALTYPE could offer only one terminal type at a time, and there was no standard way back to NVT ASCII.
Establishing the 3270 regime now implies three things: every character is 8 bits of binary data, both sides use IAC EOR as a delimiter, and both sides agree on a terminal type. The memo does not define the 3270 protocols themselves, and treats colors, graphics and keyboard mapping as outside Telnet or a local matter. Features such as color may be negotiated indirectly through terminal type names.
Before this, the two computers had to have three separate chats to set up a mainframe terminal, and nobody said in what order. Now it is one chat.
§2Commands and Subnegotiation
The option is named 3270-REGIME with code 29. WILL and DO grant permission for a later subnegotiation, and WON'T and DON'T refuse it. The default is WON'T/DON'T, meaning no 3270 regime.
Two subnegotiations carry the content. IAC SB 3270-REGIME ARE REGIME-LIST IAC SE (code 1) lists every regime the sender supports. IAC SB 3270-REGIME IS REGIME IAC SE (code 0) states the one chosen, which must be a substring of the received list. The list is an ASCII string of terminal type names separated by spaces, with embedded spaces and backslashes escaped by a backslash. An empty list or empty regime means NVT ASCII only.
The terminal hands over a menu of the kinds it can be, and the computer circles one.
§3How the Negotiation Runs
Either side may start the option, but both must exchange WILL 3270-REGIME and DO 3270-REGIME before subnegotiation. To keep it simple, only the client may send ARE and only the server may reply with IS. Because it is asymmetric, each renegotiation repeats the whole process.
The RFC's example has the client send ibm3279-3 ibm3279-2 ibm3278-3, and the server answer ibm3279-2. Lists run from most to least desirable, and the receiver picks the first type it supports. Sending an empty list switches both sides to NVT ASCII. To change terminal type without accidentally dropping to NVT ASCII, include both the current and new types in the list.
The terminal lists its favorites first, and the computer takes the first one it knows how to handle.
- IAC DO 3270-REGIME
- IAC WILL 3270-REGIME
- IAC DO 3270-REGIME
- IAC WILL 3270-REGIME
- SB 3270-REGIME ARE 'ibm3279-3 ibm3279-2 ibm3278-3' SE
- SB 3270-REGIME IS 'ibm3279-2' SE
§4Implementation Rules
Because IAC (255 decimal) is used as a delimiter with EOR, an IAC that is part of the data must be escaped with another IAC. To avoid ambiguity during negotiation, the client should accept no user data once negotiation starts and send nothing after ARE. The server should try not to send data meanwhile, and may reply with IS only after all outstanding data has been sent.
The server switches regimes only after sending IS, and the client only after receiving it. A switch may require flushing outstanding data on both sides.
While they are deciding, both sides stop talking about anything else, so nothing gets mixed up.