As per Relevance of the word possible, we have this rfc below:
Network Working Group J.
Request For Comments: 1041 T.J. Watson Research Center,
January 1988
Telnet 3270 Regime
STATUS OF THIS
This RFC specifies a proposed standard for the Internet community
Hosts on the Internet, that want to support 3270 data stream
the Telnet protocol, are expected to adopt and implement
standard. Distribution of this memo is unlimited
1. Command Name and
3270-REGIME 29
2. Command
IAC WILL 3270-
Sender is willing to send list of supported 3270 Regimes
a subsequent sub-negotiation
IAC WON'T 3270-
Sender refuses to send the list of supported 3270 Regimes
IAC DO 3270-
Sender is willing to receive a list of supported 3270 Regimes in
subsequent sub-negotiation
IAC DON'T 3270-
Sender refuses to accept the list of supported 3270 Regimes
IAC SB 3270-REGIME ARE REGIME-LIST IAC
Sender sends the list of all possible 3270 Regimes it is able
support. The code for ARE is 1.
REGIME-LIST is an ASCII string which has meaning to both sides
the negotiation. This string may be composed of
terminal type names (as specified in the "Assigned Numbers")
are separated by space character. Terminal type names which
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
escaped with another backslash character
Empty REGIME-LIST means, that sender is able to support only
ASCII terminal as defined in [4].
IAC SB 3270-REGIME IS REGIME IAC
Sender is stating the name of the terminal it is willing
support. The code for IS is 0.
REGIME is an ASCII string (possibly empty) which is substring
the received REGIME-LIST string. Empty string means that
sender is willing to support only NVT ASCII terminal as defined
[4].
3.
WON'T 3270-
3270 Regime will not be established
DON'T 3270-
3270 Regime will not be established
4. Motivation for the
This option allows a telnet server running VM or MVS to
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
to
o state, that both client and server want to exchange 3270
stream
o switch from 3270 Regime into NVT ASCII Regime and back into 3270
Regime
o dynamically renegotiate 3270 Regime parameters (like
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/
data stream
o be able to establish the agreement between client and server
what type of terminal will be used
Current implementations requires 3 different options,
[1], BINARY [2] and EOR [3], to be successfully negotiated
client and server prior to establishing 3270 Regime. Moreover, it
unclear at what point in this negotiation process, 3270 regime
actually established (whether after TERMINALTYPE or after BINARY
after EOR). Also, order for these negotiations was never specified
Subnegotiation for the TERMINALTYPE is possible with only
terminal type at a time
Once 3270 Regime is established, there is no standard of how to
out of this regime back into NVT ASCII mode
Based on the 3270 Regime requirements, which stated above, we
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
as 8 bits of binary data
o both sides agreed to use a certain character sequence(Telnet
EOR) as a delimiter in inbound/outbound Telnet data stream
o both sides agreed on the type of the terminal they are
to support
By providing the list of possible terminals which Telnet client
support, telnet server could select the type of the terminal it
support and pass it back to the Telnet client, thus
multiple TERMINALTYPE negotiations
As stated in [5], "The purpose of the Telnet Protocol is to provide
fairly general, bi-directional, eight-bit byte oriented
facility." Therefore we feel that such issues as color support
graphics support, extended data streams mapping, etc., do not
logically to the Telnet protocol, but rather should be considered
a part of a separate protocol which defines 3270 inbound/
data stream (see [5], [6], [7], [8]). The purpose of this memo
Rekhter [Page 3]
RFC 1041 Telnet 3270 Regime Option January 1988
not to describe (or define) protocols which are used in 3270 Regime
but rather define a new option for the Telnet Protocol, which
allow both sides to negotiate for the 3270 Regime establishment
the telnet connection
While this options does not include direct negotiation for
things as colors, graphics, structured fields, etc., certain
(like the ability to support colors) may be negotiated indirectly
using certain terminal type names specified in 3270-
subnegotiation
We also feel that such issues as keyboard mapping, whether to
one telnet for both ASCII and 3270 mode or two separate programs,
for ASCII and another for 3270 mode, are implementation dependent
should be considered as a local matter
5. Description of the
WILL and DO commands are used to obtain and grant permission for
subsequent subnegotiation. Both sides must exchange WILL 3270-
and DO 3270-REGIME prior to subnegotiation. The actual exchange
information is done within the option subcommand (IAC
3270-REGIME).
Either Telnet client or Telnet server can initialize 3270-
negotiation. However, in order to simplify negotiation, only
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-
IS... IAC SE command
Since this negotiation is asymmetric, each time Telnet client/
decide to negotiate/renegotiate this option they have to
complete negotiation process (DO... WILL... SB 3270-REGIME...).
The following is an example of use of the option
1. Host A: IAC DO 3270-
2. Host B: IAC WILL 3270-
3. Host B: IAC DO 3270-
4. Host A: IAC WILL 3270-
5. (At this point side which runs Telnet client can
subnegotiation.)
Rekhter [Page 4]
RFC 1041 Telnet 3270 Regime Option January 1988
6. Host A: IAC SB 3270-REGIME ARE 'ibm3279-3 ibm3279-2 ibm3278-3'
IAC
7. Host B: IAC SB 3270-REGIME IS 'ibm3279-2' IAC
6. Implementation
If the side is able to support more that one terminal type,
terminal type names are listed in REGIME-LIST from most desirable
least desirable. Other side upon receive of the REGIME-LIST scans
from left to right and finds the first terminal type which it is
to support returns it in REGIME part of the 3270-REGIME
subnegotiation
The side which wants to switch into NVT ASCII mode should send
REGIME-LIST. Since empty string is a subset of empty string,
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
type). Certain precaution should be taken to insure that
renegotiation would not cause switch into NVT ASCII mode. As
possible measure, the side which wants to renegotiate for
terminal should include both the current and the new terminal
names into REGIME-LIST. This way, if the other side is unable
change 3270 Regime terminal type, it will continue to use
terminal type
Since IAC character (255 decimal) is used as a delimiter (
with EOR) in inbound/outbound data stream, care must be taken
escape IAC characters which are part of data stream itself
another IAC character
To prevent ambiguity in interpreting inbound/outbound data
during negotiation process the following rules should be observed
1. Telnet client should not accept any data from the user as
as it enters 3270 Regime negotiation
2. Telnet client should not send any data to the Telnet
after it sends "3270-REGIME ARE....".
3. Telnet server should try not to send any data to the
client while negotiation is in progress
4. Telnet server may reply with "3270-REGIME IS..." to the
client only after all outstanding data have been already
Rekhter [Page 5]
RFC 1041 Telnet 3270 Regime Option January 1988
to the Telnet client
5. Telnet server can switch from its previous regime to the
regime only after it sends "IAC SB 3270-REGIME IS 'regime'
SE" to the telnet client
6. Telnet client can switch from its previous regime to the
regime only after it receives "IAC SB 3270-REGIME IS 'regime
IAC SE".
7. Switch from one regime to another may require flushing of
outstanding data in both telnet client and telnet server
7.
[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
Description and Programmer's Guide. GA23-0061-1.
[6] IBM 3279 Information Display System: Color and
Symbols. GA33-3056-1.
[7] IBM 3270 Information Display System. Data Stream Programmer'
Reference. GA23-0059-1.
[8] IBM 3270 Information Display System. Description
Configuration: APL/Text Feature. GA18-2044-0.
Rekhter [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
