Re: Stds track RFC Internet Draft
Fred Bohle <fab@md.interlink.com> Wed, 21 July 1993 15:10 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04085; 21 Jul 93 11:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04080; 21 Jul 93 11:10 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa12678; 21 Jul 93 11:10 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 5818; Wed, 21 Jul 93 11:09:32 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 5811; Wed, 21 Jul 93 11:08:52 EDT
Date: Wed, 21 Jul 1993 11:07:38 -0400
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Bohle <fab@md.interlink.com>
Subject: Re: Stds track RFC Internet Draft
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307211110.aa12678@CNRI.Reston.VA.US>
> Here are my comments about the draft. They start with a >.
TN3270 Enhancements Working Group B. Kelly
Internet Draft Auburn University
July 1993
TN3270 Enhancements
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on ds.internic.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract
This document describes a protocol that more fully supports 3270
devices than do the existing tn3270 practices. Specifically, it
defines a method of emulating both the terminal and printer members
of the 3270 family of devices via Telnet; it provides for the
ability of a Telnet client to request that it be assigned a
specific device-name (also referred to as "LU name" or "network
name"); finally, it adds support for a variety of functions such as
the ATTN key, the SYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new
Telnet Option and would be unrelated to the Telnet 3270 Regime
Option as defined in RFC 1041 [1].
B. Kelly Expires January 1994 [Page 1]
Internet Draft TN3270 Enhancements July 1993
TABLE OF CONTENTS
1. INTRODUCTION ............................................... 2
2. TN3270E OVERVIEW ........................................... 3
3. COMMAND NAMES AND CODES .................................... 4
4. COMMAND MEANINGS ........................................... 5
5. DEFAULT SPECIFICATION ...................................... 6
6. MOTIVATION ................................................. 6
7. IMPLEMENTATION RULES ....................................... 6
7.1 DEVICE-TYPE Negotiation ................................ 7
7.2 FUNCTIONS Negotiation .................................. 11
8. TN3270E DATA MESSAGES ...................................... 13
8.1 The TN3270E Message Header ............................. 13
8.1.1 DATA-TYPE Field ................................... 14
8.1.2 REQUEST-FLAG Field ................................ 14
8.1.3 RESPONSE-FLAG Field ............................... 15
9. BASIC TN3270E .............................................. 16
10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 16
10.1 The SNA-CHAR-STREAM Function ........................... 16
10.2 The DATA-STEAM-CTL Function ............................ 17
10.3 The BIND-IMAGE Function ................................ 17
10.4 The RESPONSE Function .................................. 18
11. THE 3270 ATTN KEY .......................................... 21
12. THE 3270 SYSREQ KEY ........................................ 21
13. 3270 STRUCTURED FIELDS ..................................... 22
14. EXAMPLES ................................................... 23
15. REFERENCES ................................................. 25
16. AUTHOR'S NOTE .............................................. 26
17. AUTHOR'S ADDRESS ........................................... 26
1. Introduction
Currently, support for 3270 terminal emulation over Telnet is
accomplished by the de facto standard of negotiating three separate
Telnet Options - Terminal-Type [2], Binary Transmission [3], and
End of Record [4]. Note that there is no RFC that specifies this
negotiation as a standard. RFC 1041 attempted to standardize the
method of negotiating 3270 terminal support by defining the 3270
Regime Telnet Option. Unfortunately, very few developers and
vendors ever implemented RFC 1041.
This document will refer to the existing practice of negotiating
these three Telnet Options before exchanging the 3270 datastream as
"traditional tn3270".
NOTE: Except where otherwise stated, this document does not
distinguish between Telnet servers that represent SNA devices and
those that represent non-SNA 3270 devices.
All references in this document to the 3270 datastream, SNA versus
non-SNA operation, 3270 datastream commands, orders, structured
B. Kelly Expires January 1994 [Page 2]
Internet Draft TN3270 Enhancements July 1993
fields and the like rely on [6]. References to SNA Request and
Response Units rely on [7].
There are several shortcomings in traditional tn3270; among them
are the following:
- It provides no capability for Telnet clients to emulate the 328x
class of printers.
- There is no mechanism by which a Telnet client can request that
a connection be associated with a given 3270 device-name. This
can be of importance when a terminal session is being
established, since many host applications behave differently
depending on the network name of the terminal. In the case of
printer emulation, this capability is an absolute necessity
because a large number of host applications have some method of
pre-defining printer destinations.
- The 3270 ATTN and SYSREQ keys are not universally supported.
- There is no support for the SNA positive/negative response
process. This is particularly important if printer emulation is
to function properly, but is also useful for some terminal
applications. A positive response is used to indicate that
the previously received data has been successfully processed.
A negative response indicates some sort of error at the client
while processing the previously received data; this could be
caused by the host application building a 3270 datastream that
contains an invalid command, or by a mechanical error at the
client side, among other things.
- There is no mechanism by which the client can access the SNA
BIND information. The BIND image contains a detailed
description of the session between the Telnet server and the
host application.
- It is not clear whether clients should support 3270 structured
fields.
2. TN3270E Overview
In order to address these issues, this document proposes a new
Telnet Option - TN3270E (option number has yet to be assigned).
Telnet clients and servers would be free to negotiate support of
the TN3270E option or not. If either side does not support TN3270E,
traditional tn3270 can be used; otherwise, a sub-negotiation will
occur to determine what subset of TN3270E will be used on the
session. It is anticipated that a client or server capable of both
types of 3270 emulation would attempt to negotiate TN3270E first,
and only negotiate traditional tn3270 if the other side refuses
TN3270E.
B. Kelly Expires January 1994 [Page 3]
Internet Draft TN3270 Enhancements July 1993
Once a client and server have agreed to use TN3270E, negotiation of
the TN3270E suboptions can begin. The two major elements of
TN3270E sub-negotiation are:
- a device-type negotiation that is similar to, but somewhat
more complicated than, the existing Telnet Terminal-Type Option.
- the negotiation of a set of supported 3270 functions, such as
printer datastream type (3270 datastream or SNA Character
Stream), positive/negative response exchanges, device status
information, and the passing of BIND information from server to
client.
Successful negotiation of these two suboptions signals the
beginning of 3270 datastream transmission. In order to support
several of the new functions in TN3270E, each data message must be
prefixed by a header. This header will contain flags and
indicators that convey such things as positive and negative
responses and what type of data follows the header (for example,
3270 datastream, SNA Character Stream, or device status
information).
3. Command Names and Codes
TN3270E (to be assigned)
ASSOCIATE 00
CONNECT 01
DEVICE-TYPE 02
FUNCTIONS 03
IS 04
REASON 05
REJECT 06
REQUEST 07
SEND 08
Reason-codes
CONN-PARTNER 00
DEVICE-IN-USE 01
INV-ASSOCIATE 02
INV-DEVICE-NAME 03
INV-DEVICE-TYPE 04
TYPE-NAME-ERROR 05
UNKNOWN-ERROR 06
UNSUPPORTED-REQ 07
Function Names
BIND-IMAGE 00
DATA-STREAM-CTL 01
RESPONSES 02
SNA-CHAR-STREAM 03
B. Kelly Expires January 1994 [Page 4]
Internet Draft TN3270 Enhancements July 1993
4. Command Meanings
IAC WILL TN3270E
The sender of this command is willing to send TN3270E
information in subsequent sub-negotiations.
IAC WON'T TN3270E
The sender of this command refuses to send TN3270E information.
IAC DO TN3270E
The sender of this command is willing to receive TN3270E
information in subsequent sub-negotiations.
IAC DON'T TN3270E
The sender of this command refuses to receive TN3270E
information.
Note that while they are not explicitly negotiated, the equivalent
of the Telnet Binary Transmission Option [3] and the Telnet End of
Record Option [4] is implied in the negotiation of the TN3270E
Option. That is, a party to the negotiation that agrees to support
TN3270E is automatically required to support bi-directional binary
and EOR transmissions.
IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Only the server may send this command. This command is used to
request that the client transmit a device-type and, optionally,
device-name information.
IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
[CONNECT | ASSOCIATE <device-name>] IAC SE
Only the client may send this command. It is used in response
to the server's SEND DEVICE-TYPE command, as well as to suggest
another device-type after the server has sent a DEVICE-TYPE
REJECT command (see below). This command requests emulation of
a specific 3270 device type and model. The REQUEST command may
optionally include either the CONNECT or the ASSOCIATE command
(but not both). If present, CONNECT and ASSOCIATE must both be
followed by <device-name>. (See the section enentitled
"Implementation Rules" for more detailed information.)
IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
<device-name> IAC SE
Only the server may send this command. This command is used to
accept a client's DEVICE-TYPE REQUEST command.
B. Kelly Expires January 1994 [Page 5]
Internet Draft TN3270 Enhancements July 1993
IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE
Only the server may send this command. This command is used to
reject a client's DEVICE-TYPE REQUEST command.
IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE
Either side may send this command. This command is used to
suggest a set of 3270 functions that will be supported on this
session. It is also sent as an implicit rejection of a previous
FUNCTIONS REQUEST command sent by the other side (see the
section entitled "Implementation Rules" for more information).
Note that when used to reject a FUNCTIONS REQUEST command, the
function-list must not be identical to that received in the
previous REQUEST command.
IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE
Either side may send this command. This command is sent as a
response to a FUNCTIONS REQUEST command and implies acceptance
of the set of functions sent to it in the REQUEST command. Note
that the list of functions in the FUNCTIONS IS command must
match the list that was received in the previous FUNCTIONS
REQUEST command.
>
> Is there a need to separate the negotiations into two parts? Can't they
> be combined? Just delimit the two lists by DEVICE-TYPE and FUNCTIONS and
> end with IAC SE.
>
5. Default Specification
WON'T TN3270E
DON'T TN3270E
i.e., TN3270E will not be used.
6. Motivation
See the section entitled "Introduction."
7. Implementation Rules
All TN3270E commands and parameters are NVT ASCII strings in which
upper and lower case are considered equivalent.
Once it has been agreed that TN3270E will be supported, the first
sub-negotiation must concern the DEVICE-TYPE (and possibly
DEVICE-NAME) information. Only after that has been successfully
negotiated can the client and server exchange FUNCTIONS
information. Only after both DEVICE-TYPE and FUNCTIONS have been
successfully negotiated can 3270 datastream transmission occur.
B. Kelly Expires January 1994 [Page 6]
Internet Draft TN3270 Enhancements July 1993
7.1 DEVICE-TYPE Negotiation
Device-type (and device-name) negotiation begins when the server
transmits the DEVICE-TYPE SEND command to the client. The client
responds with the DEVICE-TYPE REQUEST command, which must include
a device-type and may include a device-name request.
Valid device-types are those defined in the "Assigned Numbers"
RFC [5] in the section entitled "Telnet Terminal Names",
restricted to the subset of names that represent IBM 3270
terminals, plus the following:
IBM-3287-1
>
> Let's list them all. Copy the list from Assigned Numbers.
> And shouldn't we only list the ones with the -E suffix, since
> we are requiring the support of Query? We said before that
> the -E suffix really meant support of Query.
>
The above list specifies the names of 3270 printer devices.
An explanation of the CONNECT and ASSOCIATE commands first
requires a discussion of the organization of terminal and
printer device pools that the server maintains and from which it
selects device-names to assign to session requests. (The terms
"device-name", "LU name" and "network name" can be considered
interchangeable in this document.) Also, for the purposes of
this discussion, the term "generic session request" will be used
to describe a request for a session from a Telnet client (either
traditional or TN3270E) that does not include a request for a
specific device-name. The term "specific session request" will
be used to describe a request for a session from a TN3270E
client that includes a request for a specific device-name
(either via CONNECT or ASSOCIATE).
As is the case with traditional tn3270, the TN3270E server must
maintain a set of terminal device-names. A generic request for
a terminal session would result in the server selecting any
availabe device-name from this pool. The server, however, may
also maintain a separate pool of terminal device-names which can
only be used to satisfy specific terminal session requests.
This is to ensure that a terminal device that has some
significance to host applications (and is therefore likely to be
the target of a specific session request) is not "accidentally"
assigned to a generic request and winds up associated with a
client that has no use for it. Note that the reverse situation
is allowed. That is, a specific terminal session request could
ask for a device-name that happens to be in the "generic
terminal pool." The nature of the host applications would
probably mean that such a request has no real use, but it does
no harm to allow the connection to be established.
>
> Steve D'angona asked me to support Reconnect by sending certain
> status codes when we disconnect. Allowing the user to select a
> specific terminal from the generic pool would allow support of
> Reconnect. By the way Steve, if you are listening, what are the
> status codes you want us to send?
>
For each terminal device (in both the "generic" and the
"specific" pools), the TN3270E server could also have defined a
"partner" or "paired" printer device. There should be a unique,
one-to-one mapping between a terminal and its associated
B. Kelly Expires January 1994 [Page 7]
Internet Draft TN3270 Enhancements July 1993
printer. The reasoning behind such a configuration is to allow
for those host applications that produce printed output bound
for a printer whose device-name is determined by the device-name
of the terminal that initiated the print request. These printer
devices can only be assigned to specific printer session
requests that use the ASSOCIATE command (see below).
In addition, the TN3270E server may also maintain a pool of
printer device-names that are not associated with any terminal.
These printer devices can only be assigned to specific printer
session requests that use the CONNECT command (see below). This
allows for those host applications that generate printed output
bound for a printer whose device-name is determined by something
other than the device-name of the terminal that initiated the
print request (for example, when the userid of the person signed
on to a terminal determines the print destination).
Finally, it is possible that a pool of printer device-names
could be maintained and used only to satisfy generic requests
for printers.
CONNECT is used by the client to request that the server
associate a specific device-name with this Telnet session; it
may be used when requesting either a terminal or a printer
session. The specified device-name must not conflict with the
device-type; e.g., if the client requests DEVICE-TYPE IBM-3287-1
(a printer) and specifies CONNECT T1000001, but T1000001 is
defined at the host as a terminal, then the server should deny
the request. Further, if the requested device-name is already
associated with some other Telnet session, or if it is not
defined to the server, the server should deny the request.
ASSOCIATE can be used by the client only when requesting a
DEVICE-TYPE that represents a printer. The ASSOCIATE command
requests that this session be assigned the device-name of the
printer that is paired with the terminal named in the request.
If the device-type does not represent a printer, or if the
device-name is not that of a terminal, then the server should
deny the request. It is anticipated that the device-name
specified in this request would be one returned by the server
when accepting a previous terminal session request (see the IS
command below). Since no means of authentication has been
provided for, it is possible that the printer paired with the
terminal specified in the ASSOCIATE command has already been
assigned to some other Telnet session; in this case, the server
should deny the request.
To summarize, assume a TN3270E server has the following device
pools defined to it (device-names that begin with a "T" are
terminal devices; those that begin with a "P" are printers):
B. Kelly Expires January 1994 [Page 8]
Internet Draft TN3270 Enhancements July 1993
Generic Terminal Pool Specific Terminal Pool
--------------------- ----------------------
TG000001 <--> PTG00001 TS000001 <--> PTS00001
TG000002 <--> PTG00002 TS000001 <--> PTS00002
TG000003 <--> PTG00003 TS000001 <--> PTS00003
Generic Printer Pool Specific Printer Pool
-------------------- ----------------------
PG000001 PS000001
PG000002 PS000002
PG000003 PS000003
Note that the only pool that absolutely must be defined to the
server is the generic terminal pool. The absence of other pools
(or of partner printers for a terminal pool) simply means that
the server is unable to satisfy as wide a variety of requests as
would be possible if all pools were defined to it.
Given the above configuration, the following rules apply:
- a generic terminal request can only be satisfied from the
generic terminal pool (device-names TG000001 - TG000003).
- a specific terminal request (allowable only via the CONNECT
command) can be satisfied from either the generic or the
specific terminal pool, although it is anticipated that the
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.
B. Kelly Expires January 1994 [Page 9]
Internet Draft TN3270 Enhancements July 1993
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 assigned by the server if the client specified neither
CONNECT nor ASSOCIATE.
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
B. Kelly Expires January 1994 [Page 10]
Internet Draft TN3270 Enhancements July 1993
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
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.
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.
B. Kelly Expires January 1994 [Page 11]
Internet Draft TN3270 Enhancements July 1993
- 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
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
datastream 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.
The following list briefly describes the 3270 functions that may
be negotiated in the function-list:
Function Name Description
------------- -----------
SNA-CHAR-STREAM (Printer sessions only). Allows the use
of the SNA Character Stream (SCS) 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 datastream. This
corresponds to LU type 3 SNA sessions.
DATA-STREAM-CTL is mutually exclusive
with SNA-CHAR-STREAM (only one of these
should appear in a function-list).
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 (upon request)
the SNA BIND image to the client.
See the section entitled "Details of Processing TN3270E
Functions" for a more detailed explanation of the meaning and
use of these functions.
B. Kelly Expires January 1994 [Page 12]
Internet Draft TN3270 Enhancements July 1993
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 "message" consists of a series of 3270
commands, buffer orders, buffer 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 3270 blocks of data within the
Telnet data stream.
In TN3270E, each 3270 message must be prefixed with a TN3270E
header, which consists of four 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>
Note also that Telnet commands may appear anywhere in the Telnet
stream. For this reason, 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 occurance 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.
8.1 The TN3270E Message Header
As stated earlier, each data message in TN3270E must be prefixed
by a header, which consists of four bytes and is formatted as
follows:
------------------------------------------------
| DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG |
------------------------------------------------
2 bytes 1 byte 1 byte
B. Kelly Expires January 1994 [Page 13]
Internet Draft TN3270 Enhancements July 1993
8.1.1 DATA-TYPE field
The DATA-TYPE field indicates how the data portion of the
message is to be interpreted by the receiever. Possible values
for the DATA-TYPE field are:
Data-type Name Code Meaning
-------------- ---- ---------------------------------
3270-DATA 00 The data portion of the message
contains only the 3270 datastream.
Note that this is the only DATA-TYPE
value that all TN3270E clients and
servers must support, since it must
be used to identify 3270 terminal
datastreams.
SCS-DATA 01 The data portion of the message
contains SNA Character Stream data.
RESPONSE 02 The data portion of the message
constitutes device-status information
and the RESPONSE-FLAG field indicates
whether this is a postive or negative
response (see below).
BIND-IMAGE 03 The data portion of the message is
the SNA bind image from the session
established between the server and the
host application.
NVT-DATA 04 The data portion of the message is to
be interpreted as NVT data.
REQUEST 05 There is no data portion present in
the message. Only the REQUEST-FLAG
field has any meaning.
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
----------------- ---- ---------------------------------
SEND-BIND 0 The client wishes the server to send
a copy of the SNA bind image used
to establish a session between the
host application and the server.
B. Kelly Expires January 1994 [Page 14]
Internet Draft TN3270 Enhancements July 1993
ERR-COND-CLEARED 1 The client sends this to the server
when some previously encountered
printer error condition has been
cleared. (See the section entitled
"The RESPONSE 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 0 The sender does not expect the
receiver to respond either
positively or negatively to this
message.
ERROR-RESPONSE 1 The sender only expects the
receiver to respond to this message
if some type of error occurred, in
which case a negative response is
expected.
ALWAYS-RESPONSE 2 The sender expects the receiver
to respond negatively if an error
occurs, or positively if no errors
occur.
For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an
actual response to the 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 0 The previous message was received
and executed successfully with
no errors.
NEGATIVE-RESPONSE 1 The previous message was received
but an error(s) occurred while
processing it.
Accompanying device status information will be found in the data
portion of the message.
>
> The TN3278 doc specifies device status in detail. Perhaps we should
> too. You could just copy in the text here from that doc.
>
B. Kelly Expires January 1994 [Page 15]
Internet Draft TN3270 Enhancements July 1993
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.
9. Basic TN3270E
As has been stated earlier, whether or not the use 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."
Basic TN3270E requires the support of only the following TN3270E
header values:
Header field Value
------------ -----
DATA-TYPE 3270-DATA
DATA-TYPE NVT-DATA
When basic TN3270E is in effect, each party must set the DATA-TYPE
field to either 3270-DATA when the data portion of the message
contains 3270 datastream, or to NVT-DATA when the data portion is
to be interpreted is NVT data.
The REQUEST-FLAG and RESPONSE-FLAG fields are not used in basic
TN3270E.
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
>
> Let's define this better. Use such words as "violation of the
> protocol", "will be considered non-conforming".
>
messages as regards the agreed upon function. The following
sections detail for each TN3270E function the associated header
values and processing rules.
10.1 The SNA-CHAR-STREAM Function
This function can only be supported on a 3270 printer session.
If either party receives this function in a FUNCTIONS REQUEST
function-list when the previously negotiated device-type
represents a terminal, it must remove the SNA-CHAR-STREAM
function from the list before responding with a FUNCTIONS
REQUEST of its own.
B. Kelly Expires January 1994 [Page 16]
Internet Draft TN3270 Enhancements July 1993
Agreement to support this function requires that the party
support the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE SCS-DATA
When SNA-CHAR-STREAM is in effect, neither side should send a
data message with a DATA-TYPE of 3270-DATA.
10.2 The DATA-STREAM-CTL Function
This function can only be supported on a 3270 printer session.
If either party receives this function in a FUNCTIONS REQUEST
function-list when the previously negotiated device-type
represents a terminal, it must remove the DATA-STREAM-CTL
function from the list before responding with a FUNCTIONS
REQUEST of its own.
Agreement to support this function requires that the party
support the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE 3270-DATA
When DATA-STREAM-CTL is in effect, neither side should send a
data message with a DATA-TYPE of SCS-DATA.
10.3 The BIND-IMAGE Function
This function can only be supported when the TN3270E server
represents SNA 3270 devices.
>
> Why? Wouldn't printer supporters like to see the bind?
>
Agreement to support this function requires that the party
support the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE BIND-IMAGE
DATA-TYPE REQUEST
REQUEST-FLAG SEND-BIND
At any point after support of the BIND-IMAGE function has been
agreed upon, the client may send a data message to the server in
which the header DATA-TYPE field is set to REQUEST, and the
header REQUEST-FLAG is set to SEND-BIND. There is no data
portion in this message. The server must respond with a data
message in which the header DATA-TYPE field is set to BIND-IMAGE
B. Kelly Expires January 1994 [Page 17]
Internet Draft TN3270 Enhancements July 1993
and the data portion of the message consists solely of the exact
image of the SNA bind that was used to establish the session
between the server and the host application on behalf of this
client.
10.4 The RESPONSE Function
This function can be supported for both terminal and printer
sessions connected to both SNA and non-SNA servers.
Agreement to support this function requires that the party
support the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE RESPONSE
DATA-TYPE REQUEST
RESPONSE-FLAG -all values-
REQUEST-FLAG ERR-COND-CLEARED
When the RESPONSE function is in effect, each party must adhere
to the following rules:
- Whenever a data message is sent with a DATA-TYPE of either
SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG
field to either NO-RESPONSE, ERROR-RESPONSE, or
ALWAYS-RESPONSE. It is anticipated that the client side will
normally set RESPONSE-FLAG to NO-RESPONSE. The server, if it
represents an SNA device, should set RESPONSE-FLAG to reflect
>
> Are we using the Host Requirements convention of MUST/SHOULD/MAY/MUST NOT?
> It seems to me that there are Vtam applications that set DR when it is
> not truly needed, and that TN3270 gets a performance boost by not waiting
> for a round trip time before it sends Vtam a DR. I suggest that this
> decision be made by the Client, or Server based on local information,
> like configuration or local decisions by the person at the Client. If
> we let the Client decide this, we need to put it into this protocol
> somewhere.
>
>
the response value set in the RH of the RU that generated
this data message - Definite Response resulting in a
RESPONSE-FLAG 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.
- 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 in the data portion of the message, then
determine whether or not it should send a data message with a
DATA-TYPE of RESPONSE. If the data 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 no errors
encountered while processing the data, then no RESPONSE type
message should be sent. Otherwise, a data message should be
sent in which the header DATA-TYPE field is set to RESPONSE.
The RESPONSE-FLAG field in this header must have a value of
either POSITIVE-RESPONSE or NEGATIVE-RESPONSE. A
POSITIVE-RESPONSE should be sent if the previously processed
message's header specified ALWAYS-RESPONSE and no errors
B. Kelly Expires January 1994 [Page 18]
Internet Draft TN3270 Enhancements July 1993
were encountered in processing the data. A NEGATIVE-RESPONSE
should be sent when
1) the previously processed message specified ERROR-RESPONSE
or ALWAYS-RESPONSE and
2) some kind of error occurred while processing the data.
Please keep in mind that it is normally only the client that
will be constructing and sending these RESPONSE messages. A
negative response sent by the client to the server is the
equivalent of a Unit Check Status [8]. All references to
device status and sense codes in this section rely on [8].
The data portion of this RESPONSE message must consist of one
byte of binary data. The value of this byte gives a more
detailed account of 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 Meaning
----- -------
0x00 Successful completion (equivalent to "Device
End").
For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -
Value Meaning
----- -------
0x00 An invalid 3270 command was received
(equivalent to "Command Reject").
0x01 Printer is not ready (equivalent to
"Intervention Required").
0x02 An illegal 3270 buffer address or order
sequence was received (equivalent to
"Operation Check").
0x03 Printer is powered off or not connected
(equivalent to "Component Disconnected").
When the server receives any of the above responses, it
should pass along the appropriate information to the host
application. The appopriate information is determined by
whether the server represents an SNA or a non-SNA device.
An SNA server should pass along a POSITIVE-RESPONSE from the
client as a positive SNA Response Unit to the host
B. Kelly Expires January 1994 [Page 19]
Internet Draft TN3270 Enhancements July 1993
application. It should translate a NEGATIVE-RESPONSE from
the client into an SNA negative Response Unit in which the
Sense Data Indicator bit is on and which contains one of
the following sense codes:
RESPONSE-FLAG Equivalent SNA Sense Code
------------- ---------- --------------
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
the client by setting the Device End Status bit on. It
should reflect a NEGATIVE-RESPONSE from the client by setting
the Unit Check Status 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
being passed by the server to the host application, the host
would normally refrain from sending any further data to the
printer. If and when the error condition at the client has
been resolved, the client must send to the server a data
message whose header DATA-TYPE field is set to REQUEST, and
whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that
this message has no data portion. Upon receipt of this
message, the server should pass along the appropriate
information to the host application so that it may resume
sending printer output. Again, the form of this information
depends on whether the server represents an SNA or a
non-SNA device.
An SNA server should reflect an ERR-COND-CLEARED to the host
application by sending an SNA LUSTAT RU with one of the
following sense codes:
- if the previous error condition was an Intervention
Required, the server should send sense code 0x00010000
- if the previous error condition was Component
Disconnected, the server should send sense code 0x082B0000
A non-SNA server should set the corresponding bits in the
Ending Status and Sense Condition bytes.
B. Kelly Expires January 1994 [Page 20]
Internet Draft TN3270 Enhancements July 1993
11. The 3270 ATTN Key
The 3270 ATTN key is interpreted by many host applications in an
SNA environment as an indication that the user wishes to interrupt
the execution of the current process. The Telnet Interrupt Process
(IP) command was defined expressly for such a purpose, so it seems
logical to use IP to implement support for the 3270 ATTN key. This
requires two things:
- TN3270E clients should provide as part of their keyboard
mapping a single key or a combination of keys that map to
the 3270 ATTN key. When the user presses this key(s), the
client should transmit a Telnet IP command to the server.
- TN3270E servers should translate the IP command received from
a TN3270E client into the appropriate form and pass it along
to the host application as an ATTN key. In other words, the
server representing an SLU in an SNA session should send
a SIGNAL RU to the host application.
The ATTN key is not supported in a non-SNA environment; therefore,
a TN3270E server representing non-SNA 3270 devices should ignore
any Telnet IP commands it receives from a client.
12. The 3270 SYSREQ Key
The 3270 SYSREQ key is useful in an SNA environment when the ATTN
key is not sufficient to terminate a process. While there are
other uses for the SYSREQ key, and while its function is more
complicated than what is dealt with in this document, it seems
reasonable to implement a subset of the SYSREQ key support that
would be beneficial to a large number of users. This subset would
be limited to support for the sequence of pressing SYSREQ and
typing LOGOFF that many users employ to immediately terminate an
>
> On a real 3270, you usually hit Clear, type LOGOFF and press SYSREQ.
> On a TN3270E session, I guess you see the SYSREQ followed by LOGOFF.
>
SNA session. It is recognized that in the case of host-resident
TN3270E servers, essentially the same thing can be accomplished by
the user unilaterally closing the Telnet connection, but in the
case of servers that do not reside on the host (for example, the
commercial TCP-to-SNA gateways) users may wish to terminate the SNA
session without closing the Telnet connection.
The Telnet Abort Output (AO) command seems the appropriate
mechanism for implementing this limited SYSREQ key support, given
that in a real SNA session, once the user presses the SYSREQ key,
the host application is prevented from sending any more output to
the terminal (unless the user presses SYSREQ a second time), but
the user's process continues to execute.
In order to implement SYSREQ key support, TN3270E clients should
provide a key (or combination of keys) that is identified as
B. Kelly Expires January 1994 [Page 21]
Internet Draft TN3270 Enhancements July 1993
mapping to the 3270 SYSREQ key. When the user presses this key(s),
the client should transmit a Telnet AO command to the server.
Upon receipt of the AO command, the TN3270E server should enter
what will be loosely termed "suspended mode" for the connection.
Any attempt by the host application to send data to the client
while the connection is "suspended" should be responded to by the
server with a negative response, sense code 0x082D, indicating
an "LU Busy" condition. The server should not transmit anything to
the client on behalf of the host application.
At this point, there are two possible courses of action on the part
of the user:
- transmit the string LOGOFF (upper or lower case), which will
result in the server terminating the SNA session with the host
application. In the case of host-based servers, this will also
have the effect of closing the Telnet connection.
- press the "SYSREQ" key again, which will result in the
transmission of another AO to the server. The server should
then send to the host application an LUSTAT RU with a value of
0x082B indicating "presentation space integrity lost." The
server will then "un-suspend" the Telnet connection to the
client, meaning it will allow the host application to once
again send data to the client.
If, while the Telnet connection is "suspended," the user transmits
anything other than the above, the server should respond with the
string "COMMAND UNRECOGNIZED" to the client. The server should not
send anything to the host application on behalf of the client.
The SYSREQ key is not supported in a non-SNA environment; in fact,
use of this key on a non-SNA 3270 terminal generally gets the user
into difficulties. Therefore, TN3270E servers representing non-SNA
3270 terminals should ignore any Telnet AO commands they receive
from a client.
13. 3270 Structured Fields
3270 structured fields provide a much wider range of features than
"old-style" 3270 data, such as support for graphics, partitions and
IPDS printer datastreams. It would be unreasonable to expect all
TN3270E clients to support all possible structured field functions,
yet there must be a mechanism by which those clients that are
capable of supporting some or all structured field functions can
indicate their wishes.
The design of 3270 structured fields provides a convenient means to
convey the level of support (including no support) for the various
B. Kelly Expires January 1994 [Page 22]
Internet Draft TN3270 Enhancements July 1993
structured field functions. This mechanism is the Read Partition
Query command, which is sent from the host application to the
device. The device responds with a Query Reply(s), listing which,
if any, structured field functions it supports.
Therefore, all TN3270E clients must be able to respond to a Read
Partition Query command, even if only to indicate that it supports
no structured field functions. Note that clients must support both
the Read Partition Query (Type 02), and all forms of the Read
Partition Query List (Type 03).
14. Examples
The following example shows a TN3270E-capable server and a
traditional tn3270 client establishing a connection:
Server: IAC DO TN3270E
Client: IAC WON'T TN3270E
Server: IAC DO TERMINAL-TYPE
Client: IAC WILL TERMINAL-TYPE
Server: IAC SB TERMINAL-TYPE SEND IAC SE
Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
Server: IAC DO EOR
Client: IAC WILL EOR
>
> DO BINARY / WILL BINARY ???
> Let's be complete here.
>
. .
. .
(traditional tn3270 negotiation continues)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a generic terminal session:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
anyterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 datastream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a terminal session where the
client requests a specific device-name:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
CONNECT myterm IAC SE
B. Kelly Expires January 1994 [Page 23]
Internet Draft TN3270 Enhancements July 1993
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT
myterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 datastream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client attempting to establish a terminal session;
multiple attempts are necessary because the device-name initially
requested by the client is already in use:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
CONNECT myterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE REJECT REASON
DEVICE-IN-USE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2
CONNECT herterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
herterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 datastream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing a printer session where the
client requests a specific device-name, and where some amount
of 3270 function negotiation is required before an agreement is
reached:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT
myprt IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
myprt IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
RESPONSES IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
(3270 datastream is exchanged)
The following example shows a TN3270E-capable server and a
TN3270E-capable client establishing first a generic terminal
session, then a printer session where the "partner" printer for
the assigned terminal is requested:
B. Kelly Expires January 1994 [Page 24]
Internet Draft TN3270 Enhancements July 1993
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
termXYZ IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 datastream is exchanged)
. .
. .
(user decides to request a printer session,
so client again connects to Telnet port on server)
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
ASSOCIATE termXYZ IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
termXYZ's-prt IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST SNA-CHAR-STREAM
RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS SNA-CHAR-STREAM RESPONSES
IAC SE
(3270 datastream is exchanged)
15. References
[1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM
Corporation, January 1988.
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
FTP Software, Inc., February 1989.
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
RFC 856, USC/Information Sciences Institute, May 1983.
[4] Postel, J., "Telnet End of Record Option", RFC 885, USC/
Information Sciences Institute, December 1983.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July 1992.
[6] "3270 Information Display System - Data Stream Programmer's
Reference", publication number GA24-0059, IBM Corporation.
[7] "Systems Network Architecture - Network Product Formats",
publication number LY43-0081, IBM Corporation.
B. Kelly Expires January 1994 [Page 25]
Internet Draft TN3270 Enhancements July 1993
[8] "3174 Establishment Controller Functional Description",
publication number GA23-0218, IBM Corporation.
16. Author's Note
Portions of this document were drawn from the following sources:
- A White Paper written by Owen Reddecliffe, WRQ Corporation,
October 1991.
- Experimental work on the part of Cleve Graves and Michelle
Angel, OpenConnect Systems, 1992 - 1993.
- Discussions at the March 1993 IETF meeting.
- Discussions on the "TN3270E" list, Spring 1993.
17. Author's Address
Bill Kelly
Division of University Computing
144 Parker Hall
Auburn, AL 36849
Phone: (205) 844-4512
Email: kellywh@mail.auburn.edu
B. Kelly Expires January 1994 [Page 26]
Bill Kelly phone: (205) 844-4512
Auburn University Internet: kellywh@mail.auburn.edu
>
> Thanks for the effort Bill. I hope we can converge on agreement soon.
>
------------------------------------------------------------------------
Fred Bohle EMAIL: fab@interlink.com
Interlink Computer Sciences AT&T : 301-317-6600
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------
- Stds track RFC Internet Draft Bill Kelly
- Re: Stds track RFC Internet Draft Fred Bohle
- Re: Stds track RFC Internet Draft Bill Kelly