RFC 1041

RFC 1041: Telnet 3270 Regime Option 🎀

Okay bestie, let's start with the title block, because it's giving important info 💅

• Network Working Group, Request For Comments 1041 📜
• Author: J. Rekhter, T.J. Watson Research Center, IBM 💖
• Date: January 1988 🌸
• Category: proposed standard 🦋 (more on that in the status section)
• Obsoletes and updates: the title block doesn't list anything this RFC obsoletes or updates ✨

---

Status of This Memo ✨

This RFC is a proposed standard for the Internet community 🌈. Hosts on the Internet that want to support the 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 💅

The command name and code are:

3270-REGIME     29

2. Command Meaning 🦋

Okay, so here's what each command means, bestie 🧚

IAC WILL 3270-REGIME

The sender is willing to send a list of supported 3270 Regimes in a sub-negotiation that comes after 💖

IAC WON'T 3270-REGIME

The sender refuses to send the list of supported 3270 Regimes 🙈

IAC DO 3270-REGIME

The sender is willing to receive a list of supported 3270 Regimes in a sub-negotiation that comes after ✨

IAC DON'T 3270-REGIME

The sender refuses to accept the list of supported 3270 Regimes 💀

IAC SB 3270-REGIME ARE REGIME-LIST IAC SE

The sender sends the list of all possible 3270 Regimes it can support 🌸 The code for ARE is 1.

REGIME-LIST is an ASCII string that has meaning to both sides of the negotiation 🫶 This string may be made up of different terminal type names (as specified in the "Assigned Numbers") that are separated by a space character. Terminal type names with imbedded spaces should escape them with a backslash character ('\'). A backslash character imbedded into a terminal type name should be escaped with another backslash character.

An empty REGIME-LIST means that the sender can only support the NVT ASCII terminal as defined in [4] 🧸

IAC SB 3270-REGIME IS REGIME IAC SE

The sender is stating the name of the terminal it's willing to support. The code for IS is 0 🎀

REGIME is an ASCII string (possibly empty) that is a substring of the received REGIME-LIST string. An empty string means the sender is willing to support only the 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 🌈

Okay, so this option lets a telnet server running VM or MVS negotiate with the telnet client on the type of data stream (3270 or NVT ASCII) that both sides are willing to support 💜

The main reason for this option is to have a simple and efficient way to:

• state that both client and server want to exchange 3270 data stream,
• switch from 3270 Regime into NVT ASCII Regime and back into 3270 Regime,
• dynamically renegotiate 3270 Regime parameters (like terminal type).

Support for the 3270 data stream requires that both sides:

• be able to exchange binary data,
• be able to put well defined delimiters into inbound/outbound data stream,
• be able to establish the agreement between client and server on what type of terminal will be used.

Right now, implementations need 3 different options, TERMINALTYPE [1], BINARY [2] and EOR [3], to be successfully negotiated between client and server before 3270 Regime can be established 😭 It's also unclear at what point in this negotiation process 3270 regime is actually established (whether after TERMINALTYPE, after BINARY, or after EOR). And the order for these negotiations was never specified. Lowkey chaotic 🙈

Subnegotiation for the TERMINALTYPE is only possible with a single terminal type at a time.

Once 3270 Regime is established, there's no standard for how to get out of this regime and back into NVT ASCII mode 💀

Based on the 3270 Regime requirements stated above, we feel that separate negotiation for EOR and BINARY should not be done 🙌 Instead, establishing 3270 Regime should imply that:

• each character in the Telnet data stream should be interpreted as 8 bits of binary data,
• both sides agreed to use a certain character sequence (Telnet IAC EOR) as a delimiter in inbound/outbound Telnet data stream,
• both sides agreed on the type of the terminal they are willing to support.

By providing the list of possible terminals that a Telnet client can support, a telnet server can select the terminal type it can support and pass it back to the Telnet client. That way, multiple TERMINALTYPE negotiations are eliminated ✨

As stated in [5], "The purpose of the Telnet Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communication facility." So things like color support, graphics support, extended data streams mapping, and so on don't logically belong to the Telnet protocol 🎨 They should be considered part of a separate protocol that defines the 3270 inbound/outbound data stream (see [5], [6], [7], [8]). The purpose of this memo is not to describe (or define) the protocols used in 3270 Regime. It's to define a new option for the Telnet Protocol that lets both sides negotiate the 3270 Regime establishment over the telnet connection 🦋

This option doesn't include direct negotiation for things like colors, graphics, or structured fields. However, certain features (like the ability to support colors) may be negotiated indirectly by using certain terminal type names specified in the 3270-REGIME subnegotiation 🌈

We also feel that issues like keyboard mapping, and 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 treated 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 before subnegotiation. The actual exchange of information is done within the option subcommand (IAC SB 3270-REGIME).

Either the Telnet client or the Telnet server can initialize 3270-REGIME negotiation. However, to keep negotiation simple, only the Telnet client is allowed to send the IAC SB 3270-REGIME ARE... IAC SE command, and only the Telnet server is allowed to reply with the IAC SB 3270-REGIME IS... IAC SE command 🧚

Since this negotiation is asymmetric, every time the Telnet client or server decides to negotiate or renegotiate this option, they have to perform the complete negotiation process (DO... WILL... SB 3270-REGIME...) 🔁

Here's an example of how the option is used 👑

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, the side running the 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 a side can support more than one terminal type, the terminal type names are listed in REGIME-LIST from most desirable to least desirable. When the other side receives the REGIME-LIST, it scans from left to right and finds the first terminal type it can support, then returns it in the REGIME part of the 3270-REGIME IS subnegotiation 🎯

The side that wants to switch into NVT ASCII mode should send an empty REGIME-LIST. Since an empty string is a subset of an empty string, the side that receives an empty REGIME-LIST should reply with an empty REGIME. At that point, both sides are switched to NVT ASCII mode 🌸

It's possible to renegotiate 3270 Regime parameters (like terminal type). Certain precautions should be taken to ensure that renegotiation doesn't cause a switch into NVT ASCII mode 😬 As a possible measure, the side that wants to renegotiate for another terminal should include both the current and the new terminal type names in REGIME-LIST. That way, if the other side is unable to change its 3270 Regime terminal type, it will keep using the current terminal type 🫶

Since the IAC character (255 decimal) is used as a delimiter (together with EOR) in the inbound/outbound data stream, care must be taken to escape IAC characters that are part of the data stream itself by using another IAC character 🧠

To prevent ambiguity when interpreting the inbound/outbound data stream during the negotiation process, the following rules should be observed. Bestie, these are important 🚨

1. The Telnet client should not accept any data from the user as soon as it enters 3270 Regime negotiation.
2. The Telnet client should not send any data to the Telnet server after it sends "3270-REGIME ARE...."
3. The Telnet server should try not to send any data to the telnet client while negotiation is in progress.
4. The Telnet server may reply with "3270-REGIME IS..." to the telnet client only after all outstanding data has already been sent to the Telnet client.
5. The 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. The 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. Switching from one regime to another may require flushing all outstanding data in both the telnet client and the 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.