Telnet 3270 regime option
RFC 1041
Document | Type |
RFC - Historic
(January 1988; No errata)
Updated by RFC 6270
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-10-01 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1041 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 communicationShow full document text