Telnet 3270 regime option
RFC 1041

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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

Rekhter                                                         [Page 1]
RFC 1041               Telnet 3270 Regime Option            January 1988

      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).

Rekhter                                                         [Page 2]
RFC 1041               Telnet 3270 Regime Option            January 1988

   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