RFC relevance of terminal

As per Relevance of the word terminal, we have this rfc below:

Network Working Group B.
Request for Comments: 2355 Auburn
Obsoletes: 1647 June 1998
Category: Standards

TN3270

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved

This document describes a protocol that more fully supports 3270
devices than do traditional tn3270 practices. Specifically,
defines a method of emulating both the terminal and printer
of the 3270 family of devices via Telnet; it provides for the
of a Telnet client to request that it be assigned a specific device
name (also referred to as "LU name" or "network name"); finally,
adds support for a variety of functions such as the ATTN key,
SYSREQ key, and SNA response handling

This protocol is negotiated under the TN3270E Telnet Option, and
unrelated to the Telnet 3270 Regime Option as defined in RFC 1041
[1].

TABLE OF

1. Introduction ............................................... 2
1.1 Changes to RFC 1647 .................................... 4
2. TN3270E OVERVIEW ........................................... 5
3. COMMAND NAMES AND CODES .................................... 6
4. COMMAND MEANINGS ........................................... 7
5. DEFAULT SPECIFICATION ...................................... 9
6. MOTIVATION ................................................. 9
7. TN3270E SUB-NEGOTIATION RULES .............................. 9
7.1 DEVICE-TYPE Negotiation ................................ 9
7.1.1 Device Pools ...................................... 10
7.1.2 CONNECT Command ................................... 12

Kelly Standards Track [Page 1]

RFC 2355 TN3270 Enhancements June 1998

7.1.3 ASSOCIATE Command ................................. 12
7.1.4 Accepting a Request ............................... 13
7.1.5 REJECT Command .................................... 13
7.2 FUNCTIONS Negotiation .................................. 14
7.2.1 Commands .......................................... 14
7.2.2 List of TN3270E Functions ......................... 16
8. TN3270E DATA MESSAGES ...................................... 16
8.1 The TN3270E Message Header ............................. 18
8.1.1 DATA-TYPE Field ................................... 18
8.1.2 REQUEST-FLAG Field ................................ 19
8.1.3 RESPONSE-FLAG Field ............................... 19
8.1.4 SEQ-NUMBER Field .................................. 20
9. BASIC TN3270E .............................................. 20
9.1 3270 Mode and NVT Mode ................................. 21
10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 22
10.1 The SCS-CTL-CODES Function ............................. 22
10.2 The DATA-STREAM-CTL Function ........................... 23
10.3 The BIND-IMAGE Function ................................ 24
10.4 The RESPONSES Function ................................. 25
10.4.1 Response Messages ................................. 26
10.5 The SYSREQ Function .................................... 28
10.5.1 Background ........................................ 28
10.5.2 TN3270E Implementation of SYSREQ .................. 29
11. THE 3270 ATTN KEY .......................................... 30
12. 3270 STRUCTURED FIELDS ..................................... 31
13. IMPLEMENTATION GUIDELINES .................................. 31
13.1 3270 Data Stream Notes ................................. 31
13.2 Negotiation of the TN3270E Telnet Option ............... 32
13.3 A "Keep-alive" Mechanism ............................... 32
13.4 Examples ............................................... 32
14. SECURITY CONSIDERATIONS .................................... 36
15. REFERENCES ................................................. 36
16. AUTHOR'S NOTE .............................................. 37
17. AUTHOR'S ADDRESS ........................................... 37
18. Full Copyright Statement ................................... 38

1.

Traditionally, support for 3270 terminal emulation over Telnet
been accomplished by the de facto standard of negotiating
separate Telnet Options - Terminal-Type [2], Binary Transmission [3],
and End of Record [4]. Note that there is no RFC that specifies
negotiation as a standard. RFC 1041 attempted to standardize
method of negotiating 3270 terminal support by defining the 3270
Regime Telnet Option. Very few developers and vendors
implemented RFC 1041.

Kelly Standards Track [Page 2]

RFC 2355 TN3270 Enhancements June 1998

This document will refer to the existing practice of
these three Telnet Options before exchanging the 3270 data stream
"traditional tn3270". Traditional tn3270 is documented in [10].

NOTE: Except where otherwise stated, this document does
distinguish between Telnet servers that represent SNA devices
those that represent non-SNA 3270 devices

All references in this document to the 3270 data stream, 3270
stream commands, orders, structured fields and the like rely on [5].

References to SNA Request and Response Units rely on [6].
to SNA versus non-SNA operation rely on [7].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.

There were several shortcomings in traditional tn3270; among
were the following

- It provided no capability for Telnet clients to emulate the 328
class of printers

- There was no mechanism by which a Telnet client could request
a connection be associated with a given 3270 device-name.
can be of importance when a terminal session is being established
since many host applications behave differently depending on
network name of the terminal. In the case of printer emulation
this capability is an absolute necessity because a large number
host applications have some method of pre-defining
destinations

- The 3270 ATTN and SYSREQ keys were not universally supported

- There was no support for the SNA positive/negative
process. This is particularly important if printer emulation
to function properly, but is also useful for some
applications. A positive response is used to indicate that
previously received data has been successfully processed.
negative response indicates some sort of error has occurred
processing the previously received data; this could be caused
the host application building a 3270 data stream that contains
invalid command, or by a mechanical error at the client side
among other things

Kelly Standards Track [Page 3]

RFC 2355 TN3270 Enhancements June 1998

- There was no mechanism by which the client could access the
Bind information. The Bind image contains a detailed
of the session between the Telnet server and the host application

- There was no mechanism by which the server could determine
a client supported 3270 structured fields, or a client
request that it receive them

1.1 Changes to RFC 1647

This document replaces RFC 1647; the following is a summary of
changes that have been incorporated

- Reworded the Introduction to refer to traditional tn3270 in
past tense

Affected sections: 1.

- Added this section documenting changes to RFC 1647

Affected sections: 1.1

- Clarified the specification of numeric literals contained in
document

Affected sections: 3. (first paragraph

- Extensively revised several sections

1) clarify the motivation behind and use of the

2) remove restrictive wording regarding the
and use of server maintained device
3) distinguish between device-names and resource-names in
TN3270E device-type negotiation, and define a maximum length
device-names and resource-

Affected sections: 4. (DEVICE-TYPE REQUEST command) and 7.1.1
through 7.1.6

- Corrected the erroneous specification of the format of
function-list sent during TN3270E functions negotiation

Affected sections: 7.2.1 (first paragraph

Kelly Standards Track [Page 4]

RFC 2355 TN3270 Enhancements June 1998

- Added a statement addressing what a client or server should
if an impasse is reached during TN3270E functions negotiation

Affected sections: 7.2.1 (last paragraph

- Added a DATA-TYPE of PRINT-EOJ with a value of 0x08 to
the end-of-job indication for printers

Affected sections: 8.1.1, 10.1, 10.2

- Clarified the description of the SEQ-NUMBER Field to state

1) the field should be sent in network byte order (big endian
2) either byte that contains a 0xff must be doubled to 0
before sending, and stripped back to 0xff after receipt

Affected sections: 8.1.4

- Defined the format and maximum length of the Bind image

Affected sections: 10.3 (fourth paragraph

- Clarified the misleading wording regarding allowable DATA-
when BIND-IMAGE has been negotiated and a BIND has been sent

Affected sections: 10.3 (last paragraph

- Clarified the use of the SEQ-NUMBER field in regards to when
should be reset to zero

Affected sections: 10.4 (last paragraph

- Clarified the format of the data when the DATA-TYPE field
SSCP-LU-DATA

Affected sections: 10.5.2 (fourth paragraph

- Reworded the Security section to refer to Kerberos

Affected sections: 14.

2. TN3270E

In order to address these issues, this document proposes a new
Option - TN3270E. Telnet clients and servers would be free
negotiate support of the TN3270E option or not. If either side
not support TN3270E, traditional tn3270 can be used; otherwise,
sub-negotiation will occur to determine what subset of TN3270E

Kelly Standards Track [Page 5]

RFC 2355 TN3270 Enhancements June 1998

be used on the session. It is anticipated that a client or
capable of both types of 3270 emulation would attempt to
TN3270E first, and only negotiate traditional tn3270 if the
side refuses TN3270E

Once a client and server have agreed to use TN3270E, negotiation
the TN3270E suboptions can begin. The two major elements of TN3270
sub-negotiation are

- a device-type negotiation that is similar to, but
more complicated than, the existing Telnet Terminal-Type Option

- the negotiation of a set of supported 3270 functions, such
printer data stream type (3270 data stream or SNA
Stream), positive/negative response exchanges, device
information, and the passing of BIND information from server
client

Successful negotiation of these two suboptions signals the
of 3270 data stream transmission. In order to support several of
new functions in TN3270E, each data message must be prefixed by
header. This header will contain flags and indicators that
such things as positive and negative responses and what type of
follows the header (for example, 3270 data stream, SNA
Stream, or device status information).

3. Command Names and

Please note that all numeric literals in this document
decimal values, unless they are preceded by "0x", in which case
hexadecimal value is represented

TN3270E 40
ASSOCIATE 00
CONNECT 01
DEVICE-TYPE 02
FUNCTIONS 03
IS 04
REASON 05
REJECT 06
REQUEST 07
SEND 08

Reason-
CONN-PARTNER 00
DEVICE-IN-USE 01
INV-ASSOCIATE 02
INV-NAME 03

Kelly Standards Track [Page 6]

RFC 2355 TN3270 Enhancements June 1998

INV-DEVICE-TYPE 04
TYPE-NAME-ERROR 05
UNKNOWN-ERROR 06
UNSUPPORTED-REQ 07

Function
BIND-IMAGE 00
DATA-STREAM-CTL 01
RESPONSES 02
SCS-CTL-CODES 03
SYSREQ 04

4. Command

Refer to the Telnet Protocol Specification [8] for the meaning
IAC, DO, WILL, etc

IAC WILL TN3270

The sender of this command is willing to send TN3270E
in subsequent sub-negotiations

IAC WON'T TN3270

The sender of this command refuses to send TN3270E information

IAC DO TN3270

The sender of this command is willing to receive TN3270
information in subsequent sub-negotiations

IAC DON'T TN3270

The sender of this command refuses to receive TN3270E information

Note that while they are not explicitly negotiated, the equivalent
the Telnet Binary Transmission Option [3] and the Telnet End
Record Option [4] is implied in the negotiation of the TN3270
Option. That is, a party to the negotiation that agrees to
TN3270E is automatically required to support bi-directional
and EOR transmissions

IAC SB TN3270E SEND DEVICE-TYPE IAC

Only the server may send this command. This command is used
request that the client transmit a device-type and, optionally
device-name information

Kelly Standards Track [Page 7]

RFC 2355 TN3270 Enhancements June 1998

IAC SB TN3270E DEVICE-TYPE REQUEST [ [CONNECT <resource-name>] | [ASSOCIATE ] ] IAC

Only the client may send this command. It is used in response
the server's SEND DEVICE-TYPE command, as well as to
another device-type after the server has sent a DEVICE-TYPE
command (see below). This command requests emulation of
specific 3270 device type and model. The REQUEST command
optionally include either the CONNECT or the ASSOCIATE
(but not both). If present, CONNECT must be followed
<resource-name> and ASSOCIATE must be followed by .
(See the section entitled "DEVICE-TYPE Negotiation" for
detailed information.)

IAC SB TN3270E DEVICE-TYPE IS
IAC

Only the server may send this command. This command is used
accept a client's DEVICE-TYPE REQUEST command and to return
server-defined device-name

IAC SB TN3270E DEVICE-TYPE REJECT REASON IAC

Only the server may send this command. This command is used
reject a client's DEVICE-TYPE REQUEST command

IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC

Either side may send this command. This command is used
suggest a set of 3270 functions that will be supported on
session. It is also sent as an implicit rejection of a
FUNCTIONS REQUEST command sent by the other side (see the
entitled "FUNCTIONS Negotiation" for more information). Note
when used to reject a FUNCTIONS REQUEST command, the function-
must not be identical to that received in the previous
command

IAC SB TN3270E FUNCTIONS IS <function-list> IAC

Either side may send this command. This command is sent as
response to a FUNCTIONS REQUEST command and implies acceptance
the set of functions sent to it in the REQUEST command. Note
the list of functions in the FUNCTIONS IS command must match
list that was received in the previous FUNCTIONS REQUEST command

Kelly Standards Track [Page 8]

RFC 2355 TN3270 Enhancements June 1998

5. Default

WON'T TN3270

DON'T TN3270

i.e., TN3270E will not be used

6.

See the section entitled "Introduction".

7. TN3270E Sub-negotiation

Once it has been agreed that TN3270E will be supported, the
sub-negotiation must concern the DEVICE-TYPE (and possibly device
name) information. Only after that has been successfully
can the client and server exchange FUNCTIONS information. Only
both DEVICE-TYPE and FUNCTIONS have been successfully negotiated
3270 data stream transmission occur

7.1 DEVICE-TYPE

Device-type names are NVT ASCII strings, all upper case

Device-type (and device-name) negotiation begins when the
transmits the DEVICE-TYPE SEND command to the client. The
responds with the DEVICE-TYPE REQUEST command, which must include
device-type and may include a resource-name or device-name request

Valid device-types are

erminals: IBM-3278-2 IBM-3278-2-E (24 row x 80 col display
IBM-3278-3 IBM-3278-3-E (32 row x 80 col display
IBM-3278-4 IBM-3278-4-E (43 row x 80 col display
IBM-3278-5 IBM-3278-5-E (27 row x 132 col display
IBM-DYNAMIC (no pre-defined display size

printers: IBM-3287-1

Note that the use of '3278' and '3287' is NOT intended to exclude
particular device capabilities; they are used here only because
are commonly known designations for a terminal and a printer
of the 3270 family of devices. The intention is to simplify
device-type negotiation (in comparison to traditional tn3270)
minimizing the number of possible device-types, and by breaking
association of a specific piece of IBM hardware with a related set
data stream capabilities. For example, negotiation of device-

Kelly Standards Track [Page 9]

RFC 2355 TN3270 Enhancements June 1998

IBM-3278-2-E does NOT in and of itself preclude the use of any of
functions associated with a physical 3279 model S2B. A client'
ability to support the more advanced functions of the 3270
stream will be indicated not by negotiation of an IBM device type
model number, but rather by the combination of Read Partition
and Query Reply

All of the terminal device-types support a "primary" display size
24 rows by 80 columns. The "-3", "-4" and "-5" types each support
"alternate" display size as noted in the above list. The IBM-
device-type implies no pre-defined alternate display size; this
will be passed from the client to host applications as part of
Query Reply structured field, and it can represent any display
the client and the host application can support

Terminal device-types with the "-E" suffix should only be
by clients that are willing to support some subset of the 3270
"extended data stream". This usually includes at a minimum
for extended colors and highlighting, but may also include a
of other functions, such as graphics capability, alternate
sets, and partitions

Clients that negotiate a terminal device-type with the "-E" suffix
the DYNAMIC type, as well as those that negotiate a printer device
type, must be able to accept and respond to a Read Partition
command (see the section entitled "3270 Structured Fields").
allows the client to indicate to host applications which subsets
the 3270 extended data stream the client is willing to support

In a VTAM/SNA environment, negotiation of IBM-DYNAMIC as the device
type should result in a Bind in which the Presentation Services
screen field (the eleventh byte in the logmode's PSERVIC field)
set to 0x03, indicating that the alternate screen size will
determined by the Query Reply (Usable Area).

7.1.1 Device

An explanation of the CONNECT and ASSOCIATE commands first requires
discussion of the organization of terminal and printer device
that the server maintains and from which it selects device-names
assign to session requests. Definition of a few terms is also
order

The terms "device-name", "LU name" and "network name" can
considered interchangeable in this document. They refer to
specific terminal or printer device

Kelly Standards Track [Page 10]

RFC 2355 TN3270 Enhancements June 1998

The term "resource-name" is less specific; it may refer to a device
name, but it may also be the name of a pool of printer or
devices. Such a named pool could serve to group devices with
operational or administrative characteristics. In fact,
document places no restrictions on how a server makes use
resource-names, so long as the server can take a resource-
specified by the client and use it to come up with a device-name
assign to the session. Note, however, that servers must
allowing ambiguity; for example, they must not allow the
of a device-name with the same name as that of a pool of devices

Device-names and resource-names are specified as NVT ASCII strings
which upper and lower case are considered equivalent. The length
device-names and resource-names should not exceed 8 bytes

A "generic session request" is one which includes neither the
nor the ASSOCIATE command, while a "specific session request" is
that includes either the CONNECT or the ASSOCIATE command

If a TN3270E server wishes to support traditional tn3270 clients,
must maintain a set of terminal device-names that can be used
satisfy requests from such clients for terminal sessions. This
pool could be used to satisfy generic requests for terminal
from TN3270E clients

The server may also maintain any number of other pools of device
names. For example, there could be a pool of terminal device-
reserved for a specific department within the organization, or a
of terminal device-names that have access to certain applications
the host

For any of these terminal device pools, the TN3270E server may
have defined a "partner" or "paired" printer device for each
in the pool. There should be a unique, one-to-one mapping between
terminal and its associated printer. The reasoning behind such
configuration is to allow for those host applications that
printed output bound for a printer whose device-name is determined
the device-name of the terminal that initiated the print request
These printer devices can only be assigned to specific
session requests that use the ASSOCIATE command (see below).

In addition, the TN3270E server may also maintain one or more
of printer device-names that are not associated with any terminal
These printer devices can only be assigned to specific
session requests that use the CONNECT command (see below).
allows for those host applications that generate printed output
for a printer whose device-name is determined by something other
the device-name of the terminal that initiated the print request (

Kelly Standards Track [Page 11]

RFC 2355 TN3270 Enhancements June 1998

example, when the userid of the person signed on to a
determines the print destination). It is also possible that a
of printer device-names could be maintained to satisfy
requests for printers (i.e., those that specify neither CONNECT
ASSOCIATE).

7.1.2 CONNECT

CONNECT can be used by the client in two ways: if the resource-
it specifies is a device-name, then the client is requesting
specific device-name. If the specified resource-name is not
device-name, then the client is requesting any one of the device
names associated with the resource-name

In either case, the resource indicated by the specified resource-
must not conflict with the device-type; e.g., if the client
DEVICE-TYPE IBM-3287-1 (a printer) and specifies CONNECT T1000001,
but T1000001 is a device-name defined at the host as a terminal,
the server must deny the request. Further, if the
resource-name is a device-name already associated with some
Telnet session, or if it is not defined to the server, the
must deny the request

7.1.3 ASSOCIATE

ASSOCIATE can be used by the client only when requesting a DEVICE
TYPE that represents a printer, and the specified device-name must
that of a terminal that was returned by the server in a
DEVICE-TYPE IS CONNECT command

The ASSOCIATE command requests that this session be assigned
device-name of the printer that is paired with the terminal named
the request. If the device-type does not represent a printer, or
the device-name is not that of a terminal, then the server must
the request. Also, if the server does not have defined a
printer for the specified terminal, it must deny the request

The use of the ASSOCIATE command is to be as follows: A client
connects and requests a terminal from one of the terminal pools;
then uses the terminal device-name returned by the server (
"Accepting a Request", section 7.1.4 below) in a second
request, this time asking for the printer that is paired with
terminal session it just established. This allows clients
associate a printer session with a terminal rather than having
have prior knowledge of a printer device-name

Kelly Standards Track [Page 12]

RFC 2355 TN3270 Enhancements June 1998

7.1.4 Accepting a

The server must accept the client's request or deny it as a whole -
it cannot, for example, accept the DEVICE-TYPE request but deny
CONNECT portion

If the server wishes to accept the request, it sends back
DEVICE-TYPE IS command confirming the requested device-type and
CONNECT command specifying the device-name of the terminal or
assigned to this session

Normally, the client should accept any DEVICE-TYPE IS CONNECT sent by the server. An exception to this
be if the client must (e.g., to satisfy local-site policy)
connected to a specific LU name and is presented with a device-
which does not match the one requested by the client (this
happen, for example, if the client requested what it thought was
device-name, but what was defined at the server as the name of a
of devices). In this case, the client should reject the DEVICE-
IS command by terminating TN3270E negotiations

7.1.5 REJECT

If the server wishes to deny the request, it sends back the DEVICE
TYPE REJECT command with one of the following reason-codes

Reason code name
---------------- -----------------------------------
INV-DEVICE-TYPE The server does not support
requested device-type

INV-NAME The resource-name or device-
specified in the CONNECT or
command is not known to the server

DEVICE-IN-USE The requested device-name
already associated with
session

TYPE-NAME-ERROR The requested device-name
resource-name is
with the requested device-
(such as terminal/printer mismatch).

UNSUPPORTED-REQ The server is unable to
the type of request sent by
client; e.g., a specific
or printer was requested but

Kelly Standards Track [Page 13]

RFC 2355 TN3270 Enhancements June 1998

server does not have any such pools
device-names defined to it, or
ASSOCIATE command was used but
partner printers are defined to
server

INV-ASSOCIATE The client used the
command and either the device-
is not a printer or the device-
is not a terminal

CONN-PARTNER The client used the CONNECT
to request a specific printer
the device-name requested is
partner to some terminal

UNKNOWN-ERROR Any other error in device type
name processing has occurred

The process of negotiating a device-type and device-name that
acceptable to both client and server may entail several iterations
DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT commands. The client
make use of the reason-code specified by the server in any DEVICE
TYPE REJECT command(s) to minimize the amount of
necessary. For example, if the client initially requests that it
assigned a specific terminal device-name via the CONNECT command,
the server rejects the request with a reason-code of UNSUPPORTED-REQ
the client must make no further specific terminal requests in
negotiations. If at any point in the process either side wishes
"bail out," it can simply send a WON'T (or DON'T) TN3270E command
the other side. At this point both sides are free to negotiate
Telnet options (including traditional tn3270).

7.2 FUNCTIONS

Once the DEVICE-TYPE negotiation has successfully completed (i.e
when the client receives a DEVICE-TYPE IS command that
acceptable), the client must initiate the FUNCTIONS negotiation
sending the FUNCTIONS REQUEST command to the server. After
initial REQUEST command, both sides are free to transmit
REQUEST and FUNCTIONS IS commands as needed

7.2.1

The FUNCTIONS REQUEST command contains a list of the TN3270
functions that the sender would like to see supported on
session. All functions not in the list are to be
unsupported. The list is terminated by the IAC code that

Kelly Standards Track [Page 14]

RFC 2355 TN3270 Enhancements June 1998

the SE command. Functions may appear in any order in the list

Upon receipt of a FUNCTIONS REQUEST command, the recipient has
choices

- it may respond in the positive (meaning it agrees to
all functions in the list, and not to transmit any data related
functions not in the list). To do this, it sends the FUNCTIONS
command with the function-list exactly as it was received. At
point, FUNCTIONS negotiation has successfully completed

- it may respond in the negative by sending a
REQUEST command in which the function-list differs from the one
received (and not simply in the order of appearance of functions
the list; at least one function must have been added to, or
from, the list).

To avoid endlessly looping, both parties must not add to
function-list it receives any function that it has previously
and that the other side has removed

The process of sending FUNCTIONS REQUEST commands back and
continues until one side receives a function-list it is willing
live with. It uses the FUNCTIONS IS command to accept the list
and, once this command is received by the other side, all
negotiation has been completed. At this point, 3270 data
transmission can begin

Note that it is possible that the function-list agreed to is null
this is referred to as "basic TN3270E". See the section
"Basic TN3270E" for more information

If an impasse is reached during FUNCTIONS negotiation (for example
if a client requested and was granted a DEVICE-TYPE representing
printer, but refuses to accept either the SCS-CTL-CODES or DATA
STREAM-CTL function), then the "offended" party should
the negotiation by sending an IAC DON'T (or WON'T) TN3270E

Kelly Standards Track [Page 15]

RFC 2355 TN3270 Enhancements June 1998

7.2.2 List of TN3270E

The following list briefly describes the 3270 functions that may
negotiated in the function-list

Function Name
------------- -----------
SCS-CTL-CODES (Printer sessions only). Allows the
of the SNA Character Stream (SCS) and
control codes on the session. SCS
used with LU type 1 SNA sessions

DATA-STREAM-CTL (Printer sessions only). Allows the
of the standard 3270 data stream.
corresponds to LU type 3 SNA sessions

RESPONSES Provides support for positive
negative response handling. Allows
server to reflect to the client any
all definite, exception, and no
requests sent by the host application

BIND-IMAGE Allows the server to send the SNA
image and Unbind notification to
client

SYSREQ Allows the client and server to
some (or all, depending on the server)
the functions of the SYSREQ key in an
environment

See the section entitled "Details of Processing TN3270E Functions
for a more detailed explanation of the meaning and use of
functions

If in the process of functions negotiation an unrecognized
code is recieved, the recipient should simply remove that
code from the list and continue normal functions negotiation

8. TN3270E Data

3270 device communications are generally understood to be
oriented in nature. That is, each partner buffers data until
entire "message" has been built, at which point the data is sent
the other side. The "outbound message" (from host to device
consists of a 3270 command and a series of buffer orders,
addresses, and data, while the "inbound message" contains only
orders, addresses and data. The end of a message is understood to

Kelly Standards Track [Page 16]

RFC 2355 TN3270 Enhancements June 1998

the last byte transmitted (note that this discussion disregards
chaining). The Telnet EOR command is used to delimit these
blocks of 3270 data within the Telnet data stream

In TN3270E, each 3270 message must be prefixed with a TN3270E header
which consists of five bytes and whose format is defined below (
the section entitled "The TN3270E Message Header"). A "data message
in TN3270E therefore has the following construction

It should be noted that it is possible that, for certain
types, there is no data portion present. In this case, the TN3270
data message consists of

If either side wishes to transmit the decimal value 255 and have
interpreted as data, it must "double" this byte. In other words,
single occurrence of decimal 255 will be interpreted by the
side as an IAC, while two successive bytes containing decimal 255
will be treated as one data byte with a value of decimal 255.

It is strongly recommended that Telnet commands (other than IAC IAC
should be sent between TN3270E data messages, with no header and
trailing IAC EOR. If a TN3270E data message containing either IAC
(to be interpreted as 3270 Attention) or IAC AO (to be interpreted
SYSREQ) is received, the receiver should defer processing the
until the 3270 data has been processed (see the appropriate
for discussion of 3270 Attention and SYSREQ). If a TN3270E
message containing any other IAC-command sequence (other than
IAC) is received, it is implementation dependent when the IAC-
sequence will be processed, but it must be processed. The
may process it immediately, which in effect causes it to be
as if it had been received before the current TN3270E data message
or the processing may be deferred until after the current TN3270
data message has been processed. It is because of this
that the presence of Telnet commands within a TN3270E data
(i.e., between the header and the trailing IAC EOR) is
recommended; neither clients nor servers should send such data

Kelly Standards Track [Page 17]

RFC 2355 TN3270 Enhancements June 1998

8.1 The TN3270E Message

As stated earlier, each data message in TN3270E must be prefixed by
header, which consists of five bytes and is formatted as follows

-----------------------------------------------------------
| DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | SEQ-NUMBER |
-----------------------------------------------------------
1 byte 1 byte 1 byte 2

8.1.1 DATA-TYPE

The DATA-TYPE field indicates how the data portion of the message
to be interpreted by the receiver. Possible values for the DATA-
field are

Data-type Name Code
-------------- ---- ---------------------------------
3270-DATA 0x00 The data portion of the
contains only the 3270 data stream

SCS-DATA 0x01 The data portion of the
contains SNA Character Stream data

RESPONSE 0x02 The data portion of the
constitutes device-status
and the RESPONSE-FLAG field
whether this is a positive or
response (see below).

BIND-IMAGE 0x03 The data portion of the message
the SNA bind image from the
established between the server and
host application

UNBIND 0x04 The data portion of the message
an Unbind reason code

NVT-DATA 0x05 The data portion of the message is
be interpreted as NVT data

REQUEST 0x06 There is no data portion present
the message. Only the REQUEST-
field has any meaning

SSCP-LU-DATA 0x07 The data portion of the message
data from the SSCP-LU session

Kelly Standards Track [Page 18]

RFC 2355 TN3270 Enhancements June 1998

PRINT-EOJ 0x08 There is no data portion present
the message. This value can be
only by the server, and only on
printer session

8.1.2 REQUEST-FLAG

The REQUEST-FLAG field only has meaning when the DATA-TYPE field
a value of REQUEST; otherwise, the REQUEST-FLAG field must be
by the receiver and should be set to 0x00 by the sender.
values for the REQUEST-FLAG field are

Request-Flag Name Code
----------------- ---- ---------------------------------
ERR-COND-CLEARED 0x00 The client sends this to the
when some previously
printer error condition has
cleared. (See the section
"The RESPONSES Function" below.)

8.1.3 RESPONSE-FLAG

The RESPONSE-FLAG field only has meaning for certain values of
DATA-TYPE field. For DATA-TYPE field values of 3270-DATA and SCS
DATA, the RESPONSE-FLAG is an indication of whether or not the
of the data expects to receive a response. In this case the
values of RESPONSE-FLAG are

Response-Flag Name Code
------------------ ---- ---------------------------------
NO-RESPONSE 0x00 The sender does not expect
receiver to respond
positively or negatively to
message. The receiver
therefore not send any
to this data-message

ERROR-RESPONSE 0x01 The sender only expects
receiver to respond to this
if some type of error occurred,
which case a negative response
be sent by the receiver

ALWAYS-RESPONSE 0x02 The sender expects the receiver
respond negatively if an
occurs, or positively if no
occur. One or the other
always be sent by the receiver

Kelly Standards Track [Page 19]

RFC 2355 TN3270 Enhancements June 1998

For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is
actual response to a previous data message (which must by
have had a DATA-TYPE of either 3270-DATA or SCS-DATA and a RESPONSE
FLAG value of either ERROR-RESPONSE or ALWAYS-RESPONSE). In
case the possible values of RESPONSE-FLAG are

Response-Flag Name Code
------------------ ---- ---------------------------------
POSITIVE-RESPONSE 0x00 The previous message was
and executed successfully
no errors

NEGATIVE-RESPONSE 0x01 The previous message was
but an error(s) occurred
processing it

Accompanying status information will be found in the data portion
the message

For any other values of the DATA-TYPE field, the RESPONSE-FLAG
must be ignored by the receiver and should be set to 0x00 by
sender

8.1.4 SEQ-NUMBER

The SEQ-NUMBER field is only used when the RESPONSES function
been agreed to. It contains a 2 byte binary number, and is used
correlate positive and negative responses to the data messages
which they were intended. This field must be sent in network
order ("big endian"). If either byte contains a 0xff, it should
doubled to 0xffff before sending and stripped back to 0xff
receipt; this is standard IAC escaping. See the section
"The RESPONSES Function" for further information on the use of
SEQ-NUMBER field. When the RESPONSES function is not agreed to,
field should always be set to 0x0000 by the sender and ignored by
receiver

9. Basic TN3270

As has been stated earlier, whether or not the use of each of
TN3270E functions is allowed on a session is negotiated when
connection is established. It is possible that none of the
are agreed to (in this case, the function-list in the
REQUEST and FUNCTIONS IS commands is null). This mode of
is referred to as "basic TN3270E". Note that, since neither
SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to
basic TN3270E refers to terminal sessions only

Kelly Standards Track [Page 20]

RFC 2355 TN3270 Enhancements June 1998

Basic TN3270E requires the support of only the following TN3270
header values

Header field
------------ -----
DATA-TYPE 3270-
DATA-TYPE NVT-

The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used
basic TN3270E

9.1 3270 Mode and NVT

At any given time, a TN3270E connection can be considered to
operating in either "3270 mode" or "NVT mode". In 3270 mode,
party may send data messages with the DATA-TYPE flag set to 3270-
DATA; sending a DATA-TYPE flag set to NVT-DATA constitutes a
to switch modes. In NVT mode, each party may send data messages
the DATA-TYPE flag set to NVT-DATA; sending 3270-DATA is a request
switch modes. The connection is initially in 3270 mode when TN3270
operation is successfully negotiated. When a party receives
message with a DATA-TYPE different from the mode it is operating in
the mode of operation for the connection is switched.
modes results in the client performing the equivalent of a 3270
Erase/Reset operation, as described in [5], using the
partition (screen) size. The server cannot assume the
preserves any attributes of the previous environment across a
switch

Note that even when sending NVT-DATA, each side should buffer
until an entire message is built (for the client, this would
mean until the user presses Enter). At that point, a
TN3270E data message should be built to transmit the NVT data

Typically, NVT data is used by a server to interact with the user
a client. It allows the server to do this using a simple NVT
stream, instead of requiring a 3270 data stream. An example would
a server which displays a list of 3270 applications to which it
connect the client. The server would use NVT data to display
list and read the user's choice. Then the server would connect
the application, and begin the exchange of 3270 data between
application and the client

Kelly Standards Track [Page 21]

RFC 2355 TN3270 Enhancements June 1998

10. Details of Processing TN3270E

Agreement by both parties to a specific function in the
REQUEST function-list implies agreement by each party to support
related set of values in the TN3270E header. It also implies
willingness to adhere to the rules governing the processing of
messages with regard to the agreed upon function. Either party
fails to accept header values associated either with agreed
functions or with basic TN3270E, or attempts to use header
associated with a function that is not a part of basic TN3270E
was not agreed upon, will be considered non-conforming and
violation of the protocol. The following sections detail for
TN3270E function the associated header values and processing rules

10.1 The SCS-CTL-CODES

This function can only be supported on a 3270 printer session

Agreement to support this function requires that the party
the following TN3270E header values

Header field
------------ -----
DATA-TYPE SCS-
DATA-TYPE PRINT-

A client representing a printer device uses this function to
its willingness to accept a data stream that includes SCS
codes. For the purposes of NVT mode versus 3270 mode, SCS-DATA
be treated exactly like 3270-DATA (i.e., it can cause a switch
NVT mode to 3270 mode).

When a printer device-type has been negotiated, either the SCS-CTL
CODES function or the DATA-STREAM-CTL function, or both, must
negotiated. This enables the server to know when it should
should not accept a session with a host application on behalf of
client. If only the SCS-CTL-CODES function is agreed to, then
server will not establish sessions with host applications that
send 3270 data stream control. If both SCS-CTL-CODES and DATA
STREAM-CTL are agreed to, then the server will establish
both with host applications that would send SCS control codes
with those that would send 3270 orders

The server should send a TN3270E message with DATA-TYPE set
PRINT-EOJ at the end of each print job to indicate to the client
it may now take whatever action is appropriate for its
(e.g., close a disk or spool file, etc.). The server may
multiple criteria for determining when it should send a PRINT-EOJ

Kelly Standards Track [Page 22]

RFC 2355 TN3270 Enhancements June 1998

such as receipt of SNA End Bracket from the host application,
expiration of a pre-defined timeout value

10.2 The DATA-STREAM-CTL

This function can only be supported on a 3270 printer session

Agreement to support this function requires that the party
the following TN3270E header values

Header field
------------ -----
DATA-TYPE 3270-
DATA-TYPE PRINT-

A client representing a printer device uses this function to
its willingness to accept a data stream that includes 3270 orders
attributes

When a printer device-type has been negotiated, either the SCS-CTL
CODES function or the DATA-STREAM-CTL function, or both, must
negotiated. This enables the server to know when it should
should not accept a session with a host application on behalf of
client. If only the DATA-STREAM-CTL function is agreed to, then
server will not establish sessions with host applications that
send SCS control codes in a data stream. If both SCS-CTL-CODES
DATA-STREAM-CTL are agreed to, then the server will
sessions both with host applications that would send SCS
codes and with those that would send 3270 orders

The server should send a TN3270E message with DATA-TYPE set
PRINT-EOJ at the end of each print job to indicate to the client
it may now take whatever action is appropriate for its
(e.g., close a disk or spool file, etc.). The server may
multiple criteria for determining when it should send a PRINT-EOJ
such as receipt of SNA End Bracket from the host application,
expiration of a pre-defined timeout value

Kelly Standards Track [Page 23]

RFC 2355 TN3270 Enhancements June 1998

10.3 The BIND-IMAGE

This function can only be supported when the TN3270E
represents SNA terminals and printers

Agreement to support this function requires that the party
the following TN3270E header values

Header field
------------ -----
DATA-TYPE BIND-
DATA-TYPE
DATA-TYPE SSCP-LU-

When BIND-IMAGE is in effect, the server must inform the client
an SNA session has been established with a host application, and
such a session has been terminated. It uses DATA-TYPE values
BIND-IMAGE and UNBIND to convey this information

When establishing an SNA session on behalf of a client, the
will receive a Bind RU from the host application. It will
receive a Start Data Traffic RU. Once both of these have
responded to positively by the server, it must then inform the
of the presence of this session by sending it a data message with
DATA-TYPE flag set to BIND-IMAGE. The data portion of this
must contain the bind image exactly as it was received in the Bind
that the server accepted on behalf of the client. The format
maximum length of this bind image are defined in [6].

When an SNA session between the server and a host application
terminated, the server must send a data message to the client
the DATA-TYPE flag set to UNBIND. If the server was notified of
session termination via an SNA Unbind RU, it should include
Unbind reason code in the data portion of the message it sends to
client. If the server itself requested the SNA session
(for example, as part of SYSREQ key processing), it should set
data portion of the UNBIND message to 0x01, indicating "normal end
session".

Another aspect of the BIND-IMAGE function alters the allowable DATA
TYPE flag values slightly from the behavior described in the
entitled "Basic TN3270E". When BIND-IMAGE is in effect,
messages with DATA-TYPE set to 3270-DATA or SCS-DATA are not
before the first BIND-IMAGE is received by the client; only SSCP-LU
DATA or NVT-DATA can be used to transmit user- oriented data.
same applies to data messages exchanged after an UNBIND is sent
before another BIND-IMAGE is received by the client. Once the
receives a BIND-IMAGE data message, the allowable DATA-TYPE values

Kelly Standards Track [Page 24]

RFC 2355 TN3270 Enhancements June 1998

in addition to SSCP-LU-DATA, now include 3270-DATA and/or SCS-DATA
depending on whether a terminal or printer device-type
negotiated, and whether a printer client agreed to DATA-STREAM-CTL
SCS-CTL-CODES, or both. (See the section entitled "The
Function" for further discussion of the SSCP-LU session in an
environment.)

10.4 The RESPONSES

This function can be supported for both terminal and printer
connected to both SNA and non-SNA servers

Agreement to support this function requires that the party
the following TN3270E header values

Header field
------------ -----
DATA-TYPE
DATA-TYPE
RESPONSE-FLAG -all values
REQUEST-FLAG ERR-COND-
SEQ-NUMBER binary values from 0-32767

Whenever a data message is sent with a DATA-TYPE of either SCS-
or 3270-DATA, the sender must set the RESPONSE-FLAG field to
NO-RESPONSE, ERROR-RESPONSE, or ALWAYS-RESPONSE. It is
that the client side will normally set RESPONSE-FLAG to NO-RESPONSE
The server, if it represents an SNA device, should set RESPONSE-
to reflect the response value set in the RH of the RU that
this data message - Definite Response resulting in a RESPONSE-
value of ALWAYS-RESPONSE, Exception Response resulting in ERROR
RESPONSE being set, and No Response causing a setting of NO-RESPONSE
A non-SNA server should set RESPONSE-FLAG to ERROR-RESPONSE

In addition, the sender must keep a count of the messages with
DATA-TYPE of 3270-DATA or SCS-DATA that it sends on a given TN3270
session. This counter should start at zero for the first
message, and be incremented by one for each subsequent message.
that this counter is independent of any SNA sequence numbers,
should not be reset to zero as a result of Bind or Unbind. If
counter reaches the maximum of 32767, it should be restarted at zero
The sender must place this value in the SEQ-NUMBER field of
TN3270E header before it sends the message. Note that the SEQ-
field must be set regardless of the value of the RESPONSE-FLAG field

Kelly Standards Track [Page 25]

RFC 2355 TN3270 Enhancements June 1998

10.4.1 Response

Whenever a data message with a DATA-TYPE of either SCS-DATA or 3270-
DATA is received, the receiver must attempt to process the data
the data portion of the message, then determine whether or not
should send a data message with a DATA-TYPE of RESPONSE. If the
message it has just processed had a RESPONSE-FLAG value of NO
RESPONSE, or if it had a value of ERROR-RESPONSE and there were
errors encountered while processing the data, then no RESPONSE
message should be sent. Otherwise, a data message should be sent
which the header DATA-TYPE field is set to RESPONSE, and in which
SEQ-NUMBER field is a copy of the SEQ-NUMBER field from the
to which this response corresponds. The RESPONSE-FLAG field in
header must have a value of either POSITIVE-RESPONSE or NEGATIVE
RESPONSE. A POSITIVE-RESPONSE should be sent if the
processed message's header specified ALWAYS-RESPONSE and no
were encountered in processing the data. A NEGATIVE-RESPONSE
be sent

1) the previously processed message specified ERROR-
or ALWAYS-RESPONSE

2) some kind of error occurred while processing the data

Normally only the client will be constructing and sending
RESPONSE messages. A negative response sent by the client to
server is the equivalent of a Unit Check Status [7]. All
to device status and sense codes in this section rely on [7].

The data portion of a RESPONSE message must consist of one byte
binary data. The value of this byte gives a more detailed account
the results of having processed the previously received data message
The possible values for this byte are

For a RESPONSE-FLAG value of POSITIVE-RESPONSE -

Value
----- -------
0x00 Successful completion (when sent by the client
this is equivalent to "Device End").

For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -

Value
----- -------
0x00 An invalid 3270 command was
(equivalent to "Command Reject").

Kelly Standards Track [Page 26]

RFC 2355 TN3270 Enhancements June 1998

0x01 Printer is not ready (equivalent
"Intervention Required").

0x02 An illegal 3270 buffer address or
sequence was received (equivalent
"Operation Check").

0x03 Printer is powered off or not
(equivalent to "Component Disconnected").

When the server receives any of the above responses, it should
along the appropriate information to the host application.
appropriate information is determined by whether the
represents an SNA or a non-SNA device

An SNA server should pass along a POSITIVE-RESPONSE from the
as an SNA positive Response Unit to the host application. It
translate a NEGATIVE-RESPONSE from the client into an SNA
Response Unit in which the Sense Data Indicator bit is on and
contains one of the following sense codes

RESPONSE-FLAG Equivalent SNA Sense
------------- ---------- --------------
0x00 Command Reject 0x10030000

0x01 Intervention Required 0x08020000

0x02 Operation Check 0x10050000

0x03 Component Disconnected 0x08310000

A non-SNA server should pass along a POSITIVE-RESPONSE from
client by setting the Device End Status bit on. It should reflect
NEGATIVE-RESPONSE from the client by setting the Unit Check
Bit on, and setting either the Command Reject, Intervention Required
or Operation Check Sense bit on when responding to the Sense command

In the case of Intervention Required or Component Disconnected
passed by the server to the host application, the host would
refrain from sending any further data to the printer. If and
the error condition at the client has been resolved, the client
send to the server a data message whose header DATA-TYPE field is
to REQUEST, and whose REQUEST-FLAG is set to ERR-COND-CLEARED.
that this message has no data portion. Upon receipt of this message
the server should pass along the appropriate information to the
application so that it may resume sending printer output. Again,
form of this information depends on whether the server represents
SNA or a non-SNA device

Kelly Standards Track [Page 27]

RFC 2355 TN3270 Enhancements June 1998

An SNA server should reflect an ERR-COND-CLEARED to the
application by sending an SNA LUSTAT RU with one of the
sense codes

- if the previous error condition was an
Required, the server should send sense code 0x00010000

- if the previous error condition was
Disconnected, the server should send sense code 0x082B0000

A non-SNA server should set the corresponding bits in the
Status and Sense Condition bytes

10.5 The SYSREQ

This function can only be supported when the TN3270E
represents SNA devices

Agreement to support this function requires that the party
the following TN3270E header values

Header field
------------ -----
DATA-TYPE SSCP-LU-

The 3270 SYSREQ key can be useful in an SNA environment when the
key is not sufficient to terminate a process. (See the
entitled "The 3270 ATTN Key" for more information.)

10.5.1

In SNA, there is a session between the host application (the PLU,
Primary Logical Unit) and the TN3270E server representing the
(the SLU, or Secondary Logical Unit). This is referred to as
PLU-SLU session, and it is the one on which normal
flow. There is also a session between the host
access method (the SSCP, or System Services Control Point) and
SLU, and it is referred to as the SSCP-LU session. This session
used to carry various control information and is normally
to the user; normal 3270 data stream orders are not allowed in
data. For more information, refer to [7].

The terminal display and keyboard are usually "owned" by the PLU-
session, meaning any data the user types is sent to the
application. The SYSREQ key is used to toggle ownership of
keyboard and display between the PLU-SLU session and the SSCP-
session. In other words, the user is able to press SYSREQ and
communicate directly with the host SSCP. The user may then enter

Kelly Standards Track [Page 28]

RFC 2355 TN3270 Enhancements June 1998

valid Unformatted Systems Services commands, which are defined in
USS table associated with the SLU. The most common USS command
employ is "LOGOFF," which requests that the SSCP
terminate the PLU-SLU session. The usual reason for requesting
an action is that the host application (the PLU) has
responding altogether

Whenever the keyboard and display are owned by the SSCP-LU session
no data is allowed to flow in either direction on the PLU-
session. Once "in" the SSCP-LU session, the user may decide
switch back to the PLU-SLU session by again pressing the SYSREQ key

10.5.2 TN3270E Implementation of

The design of some TN3270E servers allows them to fully support
SYSREQ key because they are allowed to send USS commands on
SSCP-LU session. Other TN3270E servers operate in an
which does not allow them to send USS commands to the SSCP;
makes full support of the SYSREQ key impossible. For such servers
TN3270E provides for emulation of a minimal subset of functions
namely, for the sequence of pressing SYSREQ and typing LOGOFF
many users employ to immediately terminate the PLU-SLU session

The Telnet Abort Output (AO) command is the mechanism used
implement SYSREQ key support in TN3270E because, in a real
session, once the user presses the SYSREQ key, the host
is prevented from sending any more output to the terminal (unless
user presses SYSREQ a second time), but the user's process
to execute

In order to implement SYSREQ key support, TN3270E clients that
agreed to the SYSREQ function should provide a key (or combination
keys) that is identified as mapping to the 3270 SYSREQ key. When
user presses this key(s), the client should transmit a Telnet
command to the server

Upon receipt of the AO command, a TN3270E server that has agreed
the SYSREQ function should enter what will be loosely
"suspended mode" for the connection. If a server that has not
to the SYSREQ function receives an AO command, it should
ignore it. Any attempt by the host application to send data to
client while the connection is "suspended" should be responded to
the server with a negative response, sense code 0x082D, indicating
"LU Busy" condition. The server should not transmit anything to
client on behalf of the host application. While the connection
"suspended," any data messages exchanged between the client
server should have the DATA-TYPE flag set to SSCP-LU-DATA; the
stream will be as defined in [7], specifically the section

Kelly Standards Track [Page 29]

RFC 2355 TN3270 Enhancements June 1998

"Operation in SSCP-SLU Session."

At this point, the behavior of the server depends upon whether or
it is allowed to send USS commands on the SSCP-LU session.
that have this ability should simply act as a vehicle for passing
commands and responses between the client and the SSCP

Servers that are not allowed to send USS commands on the SSCP-
session should behave as follows

- if the user transmits the string LOGOFF (upper or lower case),
the server should send an Unbind SNA RU to the host application
This will result in termination of the PLU-SLU session. If
BIND-IMAGE function was agreed upon, then the server should
send a data message to the client with the DATA-TYPE flag set
UNBIND and the data portion set to 0x01.

- if the user transmits anything other than LOGOFF, the
should respond with the string "COMMAND UNRECOGNIZED" to
client. The server should not send anything to the
application on behalf of the client

Regardless of which kind of server is present (i.e., whether or
it may send USS commands on the SSCP-LU session), while
connection is suspended, the user may press the "SYSREQ" key again
This will result in the transmission of another AO to the server
The server should then send to the host application an LUSTAT RU
a value of 0x082B indicating "presentation space integrity lost".
server will then "un-suspend" the Telnet