📄 rfc1647.txt
字号:
majority of such requests would ask for terminals in the
specific terminal pool (TS000001 - TS000003).
- a generic printer request can only be satisfied from the
generic printer pool (device-names PG000001 - PG000003).
- a specific printer request may come in one of two forms:
via ASSOCIATE: the request can only be satisfied using the
partner of the specified terminal, which
may be in the generic or the specific
terminal pool; therefore, devices in the
ranges PTG00001 - PTG00003 and PTS00001 -
PTS00003 can be used to satisfy the request.
via CONNECT: the request can be satisfied either from
the generic or the specific printer pools
(although, as with specific terminal requests,
it is likely that most such requests will name
printers in the specific printer pool); this
request cannot be satisfied with the partner
printer of a terminal in either the specific or
the generic terminal pools.
7.1.5 Accepting a Request
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 the CONNECT portion.
If the server wishes to accept the request, it sends back the
DEVICE-TYPE IS command confirming the requested device-type and
the CONNECT command specifying the device-name of the terminal
or printer assigned to this Telnet session. This device-name
may be the one directly requested (via CONNECT) by the client,
the one indirectly requested (via ASSOCIATE) by the client, or
one chosen by the server if the client specified neither
CONNECT nor ASSOCIATE.
Kelly [Page 11]
RFC 1647 TN3270 Enhancements July 1994
7.1.6 REJECT Command
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 Explanation
---------------- -----------------------------------
INV-DEVICE-TYPE The server does not support the
requested device-type.
INV-DEVICE-NAME The device-name specified in the
CONNECT or ASSOCIATE command is
not known to the server.
DEVICE-IN-USE The requested device-name is
already associated with another
Telnet session.
TYPE-NAME-ERROR The requested device-name is
incompatible with the requested
device-type (such as terminal/
printer mismatch).
UNSUPPORTED-REQ The server is unable to satisfy
the type of request sent by the
client; e.g., a specific terminal
or printer was requested but the
server does not have such a pool of
device-names defined to it, or the
ASSOCIATE command was used but no
partner printers are defined to the
server.
INV-ASSOCIATE The client used the ASSOCIATE
command and either the device-type
is not a printer or the device-name
is not a terminal.
CONN-PARTNER The client used the CONNECT command
to request a specific printer but
the device-name requested is the
partner to some terminal.
UNKNOWN-ERROR Any other error in device type or
name processing has occurred.
Kelly [Page 12]
RFC 1647 TN3270 Enhancements July 1994
The process of negotiating a device-type and device-name that
are acceptable to both client and server may entail several
iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT
commands. The client should make use of the reason-code
specified by the server in any DEVICE-TYPE REJECT command(s) to
minimize the amount of negotiation necessary. For example, if
the client initially requests that it be assigned a specific
terminal device-name via the CONNECT command, and the server
rejects the request with a reason-code of UNSUPPORTED-REQ, the
client should make no further specific terminal requests in the
negotiations. If at any point in the process either side
wishes to "bail out," it can simply send a WON'T (or DON'T)
TN3270E command to the other side. At this point both sides
are free to negotiate other Telnet options (including
traditional tn3270).
7.2 FUNCTIONS Negotiation
Once the DEVICE-TYPE negotiation has successfully completed (i.e,
when the client receives the DEVICE-TYPE IS command), the client
should initiate the FUNCTIONS negotiation by sending the \.
FUNCTIONS REQUEST command to the server. After this initial
REQUEST command, both sides are free to transmit FUNCTIONS REQUEST
and FUNCTIONS IS commands as needed.
7.2.1 Commands
The FUNCTIONS REQUEST command contains a list of the 3270
functions that the sender would like to see supported on this
session. All functions not in the list are to be considered
unsupported. The function-list consists of a string of 2-byte
entries separated from one another by a single space character.
The list is terminated by the IAC code that precedes the SE
command. Functions may appear in any order in the list.
Upon receipt of a FUNCTIONS REQUEST command, the recipient has
two choices:
- it may respond in the positive (meaning it agrees to support
all functions in the list, and not to transmit any data
related to functions not in the list). To do this, it sends
the FUNCTIONS IS command with the function-list exactly as it
was received. At this point, FUNCTIONS negotiation has
successfully completed.
- it may respond in the negative by sending a FUNCTIONS
REQUEST command in which the function-list differs from the
one it received (and not simply in the order of appearance
Kelly [Page 13]
RFC 1647 TN3270 Enhancements July 1994
of functions in the list; at least one function must have
been added to, or removed from, the list).
To avoid endlessly looping, neither party should add to the
function-list it receives any function that it has previously
added and that the other side has removed.
The process of sending FUNCTIONS REQUEST commands back and
forth continues until one side receives a function-list it is
willing to live with. It uses the FUNCTIONS IS command to
accept the list, and, once this command is received by the
other side, all necessary negotiation has been completed. At
this point, 3270 data stream 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
entitled "Basic TN3270E" for more information.
7.2.2 List of TN3270E Functions
The following list briefly describes the 3270 functions that
may be negotiated in the function-list:
Function Name Description
------------- -----------
SCS-CTL-CODES (Printer sessions only). Allows the use
of the SNA Character Stream (SCS) and SCS
control codes on the session. SCS is
used with LU type 1 SNA sessions.
DATA-STREAM-CTL (Printer sessions only). Allows the use
of the standard 3270 data stream. This
corresponds to LU type 3 SNA sessions.
RESPONSES Provides support for positive and
negative response handling. Allows the
server to reflect to the client any and
all definite, exception, and no response
requests sent by the host application.
BIND-IMAGE Allows the server to send the SNA Bind
image and Unbind notification to the
client.
SYSREQ Allows the client and server to emulate
some (or all, depending on the server) of
the functions of the SYSREQ key in an SNA
environment.
Kelly [Page 14]
RFC 1647 TN3270 Enhancements July 1994
See the section entitled "Details of Processing TN3270E
Functions" for a more detailed explanation of the meaning and
use of these functions.
8. TN3270E Data Messages
3270 device communications are generally understood to be block
oriented in nature. That is, each partner buffers data until an
entire "message" has been built, at which point the data is sent to
the other side. The "outbound message" (from host to device)
consists of a 3270 command and a series of buffer orders, buffer
addresses, and data, while the "inbound message" contains only buffer
orders, addresses and data. The end of a message is understood to be
the last byte transmitted (note that this discussion disregards SNA
chaining). The Telnet EOR command is used to delimit these natural
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 (see
the section entitled "The TN3270E Message Header").
A "data message" in TN3270E therefore has the following construction:
<TN3270E Header><data><IAC EOR>
It should be noted that it is possible that, for certain message
types, there is no data portion present. In this case, the TN3270E
data message consists of:
<TN3270E Header><IAC EOR>
If either side wishes to transmit the decimal value 255 and have it
interpreted as data, it must "double" this byte. In other words, a
single occurrence of decimal 255 will be interpreted by the other
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 no
trailing IAC EOR. If a TN3270E data message containing either IAC IP
(to be interpreted as 3270 Attention) or IAC AO (to be interpreted as
SYSREQ) is received, the receiver should defer processing the command
until the 3270 data has been processed (see the appropriate sections
for discussion of 3270 Attention and SYSREQ). If a TN3270E data
message containing any other IAC-command sequence (other than IAC
IAC) is received, it is implementation dependent when the IAC-command
sequence will be processed, but it must be processed. The receiver
may process it immediately, which in effect causes it to be processed
Kelly [Page 15]
RFC 1647 TN3270 Enhancements July 1994
as if it had been received before the current TN3270E data message,
or the processing may be deferred until after the current TN3270E
data message has been processed. It is because of this ambiguity
that the presence of Telnet commands within a TN3270E data message
(i.e., between the header and the trailing IAC EOR) is not
recommended; neither clients nor servers should send such data.
8.1 The TN3270E Message Header
As stated earlier, each data message in TN3270E must be prefixed
by a header, which consists of five bytes and is formatted as
follows:
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -