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. The
same applies to data messages exchanged after an UNBIND is sent and
before another BIND-IMAGE is received by the client. Once the client
receives a BIND-IMAGE data message, the allowable DATA-TYPE values,
in addition to SSCP-LU-DATA, now include 3270-DATA and/or SCS-DATA,
depending on whether a terminal or printer device-type was
negotiated, and whether a printer client agreed to DATA-STREAM-CTL or
SCS-CTL-CODES, or both. (See the section entitled "The SYSREQ
Function" for further discussion of the SSCP-LU session in an SNA
environment.)
10.4 The RESPONSES 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
SEQ-NUMBER binary values from 0-32767
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 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.
In addition, the sender must keep a count of the messages with a
DATA-TYPE of 3270-DATA or SCS-DATA that it sends on a given TN3270E
session. This counter should start at zero for the first such
message, and be incremented by one for each subsequent message. Note
that this counter is independent of any SNA sequence numbers, and
should not be reset to zero as a result of Bind or Unbind. If the
counter reaches the maximum of 32767, it should be restarted at zero.
The sender must place this value in the SEQ-NUMBER field of the
TN3270E header before it sends the message. Note that the SEQ-NUMBER
field must be set regardless of the value of the RESPONSE-FLAG field.
10.4.1 Response Messages
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, and in which the
SEQ-NUMBER field is a copy of the SEQ-NUMBER field from the message
to which this response corresponds. 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
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.
Normally only the client 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 [7]. All references
to device status and sense codes in this section rely on [7].
The data portion of a 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 (when sent by the client,
this is 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
appropriate 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 an SNA positive Response Unit to the host 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.
10.5 The SYSREQ Function
This function can only be supported when the TN3270E server
represents SNA devices.
Agreement to support this function requires that the party support
the following TN3270E header values:
Header field Value
------------ -----
DATA-TYPE SSCP-LU-DATA
The 3270 SYSREQ key can be useful in an SNA environment when the ATTN
key is not sufficient to terminate a process. (See the section
entitled "The 3270 ATTN Key" for more information.)
10.5.1 Background
In SNA, there is a session between the host application (the PLU, or
Primary Logical Unit) and the TN3270E server representing the client
(the SLU, or Secondary Logical Unit). This is referred to as the
PLU-SLU session, and it is the one on which normal communications
flow. There is also a session between the host telecommunications
access method (the SSCP, or System Services Control Point) and the
SLU, and it is referred to as the SSCP-LU session. This session is
used to carry various control information and is normally transparent
to the user; normal 3270 data stream orders are not allowed in this
data. For more information, refer to [7].
The terminal display and keyboard are usually "owned" by the PLU-SLU
session, meaning any data the user types is sent to the host
application. The SYSREQ key is used to toggle ownership of the
keyboard and display between the PLU-SLU session and the SSCP-LU
session. In other words, the user is able to press SYSREQ and then
communicate directly with the host SSCP. The user may then enter any
valid Unformatted Systems Services commands, which are defined in the
USS table associated with the SLU. The most common USS command users
employ is "LOGOFF," which requests that the SSCP immediately
terminate the PLU-SLU session. The usual reason for requesting such
an action is that the host application (the PLU) has stopped
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-SLU
session. Once "in" the SSCP-LU session, the user may decide to
switch back to the PLU-SLU session by again pressing the SYSREQ key.
10.5.2 TN3270E Implementation of SYSREQ
The design of some TN3270E servers allows them to fully support the
SYSREQ key because they are allowed to send USS commands on the
SSCP-LU session. Other TN3270E servers operate in an environment
which does not allow them to send USS commands to the SSCP; this
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 that
many users employ to immediately terminate the PLU-SLU session.
The Telnet Abort Output (AO) command is the mechanism used to
implement SYSREQ key support in TN3270E because, 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 that have
agreed to the SYSREQ function should provide a key (or combination of
keys) that is identified as 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, a TN3270E server that has agreed to
the SYSREQ function should enter what will be loosely termed
"suspended mode" for the connection. If a server that has not agreed
to the SYSREQ function receives an AO command, it should simply
ignore it. 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. While the connection is
"suspended," any data messages exchanged between the client and
server should have the DATA-TYPE flag set to SSCP-LU-DATA; the data
stream will be as defined in [7], specifically the section entitled
"Operation in SSCP-SLU Session."
At this point, the behavior of the server depends upon whether or not
it is allowed to send USS commands on the SSCP-LU session. Servers
that have this ability should simply act as a vehicle for passing USS
commands and responses between the client and the SSCP.
Servers that are not allowed to send USS commands on the SSCP-LU
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 the
BIND-IMAGE function was agreed upon, then the server should also
send a data message to the client with the DATA-TYPE flag set to
UNBIND and the data portion set to 0x01.
- if the user transmits anything other than LOGOFF, 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.
Regardless of which kind of server is present (i.e., whether or not
it may send USS commands on the SSCP-LU session), while the
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 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.
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 is used 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. 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 data streams. 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
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 structured field(s) listing
which, if any, structured field functions it supports.
The Query Reply is also used to indicate some device capabilities
which do not require the use of structured fields, such as extended
color support and extended highlighting capability. Most host
applications will use Read Partition Query to precisely determine a
device's capabilities when there has been some indication that the
device supports the "extended data stream".
Therefore, all TN3270E clients that negotiate a terminal device-type
that contains a "-E" suffix, the DYNAMIC terminal type, or a printer
device-type, must be able to respond to a Read Partition Query
command. Note that these clients must support both the Read
Partition Query (Type 02), and all forms of the Read Partition Query
List (Type 03).
13. Implementation Guidelines
13.1 3270 Data Stream Notes
Implementors of TN3270E clients should note that the command codes
for the various 3270 Read and Write commands have different values
depending on how the server is connected to the host (local versus
remote, SNA versus non-SNA). Clients should be coded to check for
the various possible values if they wish to be compatible with the
widest range of servers. See [7] for further details.
13.2 Negotiation of the TN3270E Telnet Option
Since TN3270E is a Telnet Option governed by [8], both client and
server are free to attempt to initiate negotiation of TN3270E by
sending a DO TN3270E command. However, just as is usually the case
with the Telnet DO TERMINAL-TYPE, it is anticipated that the server
will normally be the one sending the DO TN3270E, and the client will
be responding with a WILL or a WON'T TN3270E.
13.3 A "Keep-alive" Mechanism
In many environments, it is very helpful to have in place a mechanism
that allows timely notification of the loss of a 3270 session.
TN3270E does not require that any form of keep-alive mechanism be
employed by either clients or servers, but implementors wishing to
support such a mechanism should consider the following guidelines.
There are at least three possible means of providing a keep-alive
mechanism in TN3270E: the TCP Keepalive, the Telnet IAC NOP command
[8], and the Telnet DO TIMING-MARK option [9]. Each method has its
advantages and disadvantages. It is recommended that TN3270E clients
and servers that support keep-alives should support all three
methods, and that both sides should always respond to TIMING-MARKs.
Note that both clients and servers could be configured to "actively"
implement keep-alives. That is, both sides could send a TIMING-MARK
or a NOP or issue a TCP Keepalive in order to determine whether or
not the partner is still alive. Alternatively, network
administrators may wish to configure only one side to send keep-
alives; in this case, the other side would be a "passive" participant
which simply responds to the keep-alives it receives.
Implementors who want their code to be capable of being an "active"
keep-alive participant should make their client or server
configurable so that administrators can set which, if any, keep-alive
mechanism should be employed, and how often it should be used.
Upon failure of a session on which keep-alives are used, both parties
should make the proper notifications. A client should give the user
some indication of the failure, such as an error code in the Operator
Information Area of the screen. A server should notify the host
application that the session has been terminated, for example by
sending an UNBIND with type CLEANUP in an SNA environment.
13.4 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 IAC WILL EOR
Client: IAC WILL EOR IAC DO EOR
Server: IAC DO BINARY IAC WILL BINARY
Client: IAC WILL BINARY IAC DO BINARY
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a TN3270E-
capable client establishing a generic pool (non-specific) 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 data stream 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-E
CONNECT myterm IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT
myterm IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES
BIND-IMAGE IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES BIND-IMAGE
IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a TN3270E-
capable client establishing a terminal session where the client
requests a resource-name and is returned a device-name chosen by the
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-3278-5-E
CONNECT pool1 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT
term0013 IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST BIND-IMAGE IAC SE
Server: IAC SB TN3270E FUNCTIONS IS BIND-IMAGE IAC SE
(3270 data stream 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 data stream 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
Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
RESPONSES IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC
Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a TN3270E-
capable client establishing first a specific terminal session, then a
printer session where the "partner" printer for the assigned terminal
is requested:
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 CONNECT
termxyz 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 data stream 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 SCS-CTL-CODES
RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES
IAC SE
(3270 data stream is exchanged)
The following example shows a TN3270E-capable server and a TN3270E-
capable client establishing first a terminal session where a
resource-name was requested and a server chosen device-name was
returned, then a printer session where the "partner" printer for the
assigned terminal is requested:
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
poolxyz IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT
terma IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 data stream 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 terma IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
terma's-prt IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES
RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES
IAC SE
(3270 data stream is exchanged)
14. Security Considerations
These extensions to telnet do not provide any security features
beyond that of ordinary telnet; so a TN3270E session is no more
secure than an ordinary telnet session. Once standard authentication
and/or privacy mechanisms for telnet have been defined, these may
also be usable by TN3270E. One of the important uses of
authentication would be to answer the question of whether or not a
given user should be allowed to "use" a specific terminal or printer
device-name.
15. References
[1] Rekhter, J., "Telnet 3270 Regime Option", RFC1041, January 1988.
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC1091,
February 1989.
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
27, RFC856, May 1983.
[4] Postel, J., "Telnet End of Record Option", RFC885, December
1983.
[5] "3270 Information Display System - Data Stream Programmer's
Reference", publication number GA24-0059, IBM Corporation.
[6] "SNA Formats", publication number GA27-3136, IBM Corporation.
[7] "3174 Establishment Controller Functional Description",
publication number GA23-0218, IBM Corporation.
[8] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
8, RFC854, May 1983.
[9] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
RFC860, May 1983.
[10] J. Penner, "TN3270 Current Practices", RFC1576, January, 1994.
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 1993 IETF meetings.
- Discussions on the "TN3270E" list, 1993-94 and 1997.
17. Author's Address
Bill Kelly
Division of University Computing
144 Parker Hall
Auburn University, AL 36849
Phone: (334) 844-4512
EMail: kellywh@mail.auburn.edu
18. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.