📄 rfc1647.txt
字号:
-----------------------------------------------------------
| DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | SEQ-NUMBER |
-----------------------------------------------------------
1 byte 1 byte 1 byte 2 bytes
8.1.1 DATA-TYPE Field
The DATA-TYPE field indicates how the data portion of the
message is to be interpreted by the receiver. Possible values
for the DATA-TYPE field are:
Data-type Name Code Meaning
-------------- ---- ---------------------------------
3270-DATA 0x00 The data portion of the message
contains only the 3270 data stream.
SCS-DATA 0x01 The data portion of the message
contains SNA Character Stream data.
RESPONSE 0x02 The data portion of the message
constitutes device-status information
and the RESPONSE-FLAG field indicates
whether this is a positive or negative
response (see below).
BIND-IMAGE 0x03 The data portion of the message is
the SNA bind image from the session
established between the server and the
host application.
UNBIND 0x04 The data portion of the message is
an Unbind reason code.
NVT-DATA 0x05 The data portion of the message is to
be interpreted as NVT data.
Kelly [Page 16]
RFC 1647 TN3270 Enhancements July 1994
REQUEST 0x06 There is no data portion present in
the message. Only the REQUEST-FLAG
field has any meaning.
SSCP-LU-DATA 0x07 The data portion of the message is
data from the SSCP-LU session.
8.1.2 REQUEST-FLAG Field
The REQUEST-FLAG field only has meaning when the DATA-TYPE
field has a value of REQUEST; otherwise, the REQUEST-FLAG field
must be ignored by the receiver and should be set to 0x00 by
the sender. Possible values for the REQUEST-FLAG field are:
Request-Flag Name Code Meaning
----------------- ---- ---------------------------------
ERR-COND-CLEARED 0x00 The client sends this to the server
when some previously encountered
printer error condition has been
cleared. (See the section entitled
"The RESPONSES Function" below.)
8.1.3 RESPONSE-FLAG Field
The RESPONSE-FLAG field only has meaning for certain values of
the 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 sender of the data expects to receive a response. In
this case the possible values of RESPONSE-FLAG are:
Response-Flag Name Code Meaning
------------------ ---- ---------------------------------
NO-RESPONSE 0x00 The sender does not expect the
receiver to respond either
positively or negatively to this
message. The receiver must
therefore not send any response
to this data-message.
ERROR-RESPONSE 0x01 The sender only expects the
receiver to respond to this message
if some type of error occurred, in
which case a negative response must
be sent by the receiver.
ALWAYS-RESPONSE 0x02 The sender expects the receiver to
respond negatively if an error
occurs, or positively if no errors
Kelly [Page 17]
RFC 1647 TN3270 Enhancements July 1994
occur. One or the other must
always be sent by the receiver.
For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is
an actual response to a previous data message (which must by
definition 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 this case the possible values of RESPONSE-FLAG
are:
Response-Flag Name Code Meaning
------------------ ---- ---------------------------------
POSITIVE-RESPONSE 0x00 The previous message was received
and executed successfully with
no errors.
NEGATIVE-RESPONSE 0x01 The previous message was received
but an error(s) occurred while
processing it.
Accompanying status information will be found in the data
portion of the message.
For any other values of the DATA-TYPE field, the RESPONSE-FLAG
field must be ignored by the receiver and should be set to 0x00
by the sender.
8.1.4 SEQ-NUMBER Field
The SEQ-NUMBER field is only used when the RESPONSES function
has been agreed to. It contains a 2 byte binary number, and is
used to correlate positive and negative responses to the data
messages for which they were intended. See the section
entitled "The RESPONSES Function" for further information.
When the RESPONSES function is not agreed to, this field should
always be set to 0x0000 by the sender and ignored by the
receiver.
9. Basic TN3270E
As has been stated earlier, whether or not the use of each of the
TN3270E functions is allowed on a session is negotiated when the
connection is established. It is possible that none of the functions
are agreed to (in this case, the function-list in the FUNCTIONS
REQUEST and FUNCTIONS IS commands is null). This mode of operation
is referred to as "basic TN3270E". Note that, since neither the
SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to,
basic TN3270E refers to terminal sessions only.
Kelly [Page 18]
RFC 1647 TN3270 Enhancements July 1994
Basic TN3270E requires the support of only the following TN3270E
header values:
Header field Value
------------ -----
DATA-TYPE 3270-DATA
DATA-TYPE NVT-DATA
The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used in
basic TN3270E.
9.1 3270 Mode and NVT Mode
At any given time, a TN3270E connection can be considered to be
operating in either "3270 mode" or "NVT mode". In 3270 mode, each
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
request to switch modes. In NVT mode, each party may send data
messages with the DATA-TYPE flag set to NVT-DATA; sending 3270-
DATA is a request to switch modes. The connection is initially in
3270 mode when TN3270E operation is successfully negotiated. When
a party receives a message with a DATA-TYPE different from the
mode it is operating in, the mode of operation for the connection
is switched. Switching modes results in the client performing the
equivalent of a 3270 Erase/Reset operation, as described in [5],
using the default partition (screen) size. The server cannot
assume the client preserves any attributes of the previous
environment across a mode switch.
Note that even when sending NVT-DATA, each side should buffer data
until an entire message is built (for the client, this would
normally mean until the user presses Enter). At that point, a
complete TN3270E data message should be built to transmit the NVT
data.
Typically, NVT data is used by a server to interact with the user
of a client. It allows the server to do this using a simple NVT
data stream, instead of requiring a 3270 data stream. An example
would be a server which displays a list of 3270 applications to
which it can connect the client. The server would use NVT data to
display the list and read the user's choice. Then the server
would connect to the application, and begin the exchange of 3270
data between the application and the client.
Kelly [Page 19]
RFC 1647 TN3270 Enhancements July 1994
10. Details of Processing TN3270E Functions
Agreement by both parties to a specific function in the FUNCTIONS
REQUEST function-list implies agreement by each party to support a
related set of values in the TN3270E header. It also implies a
willingness to adhere to the rules governing the processing of data
messages with regard to the agreed upon function. Either party that
fails to accept header values associated either with agreed upon
functions or with basic TN3270E, or attempts to use header values
associated with a function that is not a part of basic TN3270E and
was not agreed upon, will be considered non-conforming and in
violation of the protocol. The following sections detail for each
TN3270E function the associated header values and processing rules.
10.1 The SCS-CTL-CODES Function
This function can only be supported on a 3270 printer session.
Agreement to support this function requires that the party support
the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE SCS-DATA
A client representing a printer device uses this function to
indicate its willingness to accept a data stream that includes SCS
control codes. For the purposes of NVT mode versus 3270 mode,
SCS-DATA should be treated exactly like 3270-DATA (i.e., it can
cause a switch from 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
be negotiated. This enables the server to know when it should and
should not accept a session with a host application on behalf of
the client. If only the SCS-CTL-CODES function is agreed to, then
the server will not establish sessions with host applications that
would send 3270 data stream control. If both SCS-CTL-CODES and
DATA-STREAM-CTL are agreed to, then the server will establish
sessions both with host applications that would send SCS control
codes and with those that would send 3270 orders.
10.2 The DATA-STREAM-CTL Function
This function can only be supported on a 3270 printer session.
Agreement to support this function requires that the party support
the following TN3270E header values:
Kelly [Page 20]
RFC 1647 TN3270 Enhancements July 1994
Header field Value
------------ -----
DATA-TYPE 3270-DATA
A client representing a printer device uses this function to
indicate its willingness to accept a data stream that includes
3270 orders and attributes.
When a printer device-type has been negotiated, either the SCS-
CTL-CODES function or the DATA-STREAM-CTL function, or both, must
be negotiated. This enables the server to know when it should and
should not accept a session with a host application on behalf of
the client. If only the DATA-STREAM-CTL function is agreed to,
then the server will not establish sessions with host applications
that would send SCS control codes in a data stream. If both SCS-
CTL-CODES and DATA-STREAM-CTL are agreed to, then the server will
establish sessions both with host applications that would send SCS
control codes and with those that would send 3270 orders.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -