As per Relevance of the word terminal, we have this rfc below:
Network Working Group J.
Request for Comments: 1091 FTP Software, Inc
Obsoletes: RFC 930 February 1989
Telnet Terminal-Type
Status of This
This RFC specifies a standard for the Internet community. Hosts
the Internet that exchange terminal type information within
Telnet protocol are expected to adopt and implement this standard
This standard supersedes RFC 930. A change is made to permit
through a list of possible terminal types and selecting the
appropriate
Distribution of this memo is unlimited
1. Command Name and
TERMINAL-TYPE 24
2. Command
IAC WILL TERMINAL-
Sender is willing to send terminal type information in
subsequent sub-negotiation
IAC WON'T TERMINAL-
Sender refuses to send terminal type information
IAC DO TERMINAL-
Sender is willing to receive terminal type information in
subsequent sub-negotiation
IAC DON'T TERMINAL-
Sender refuses to accept terminal type information
VanBokkelen [Page 1]
RFC 1091 Telnet Terminal-Type Option February 1989
IAC SB TERMINAL-TYPE SEND IAC
Server requests client to transmit his (the client's)
terminal type, and switch emulation modes (if more than
terminal type is supported). The code for SEND is 1. (
below.)
IAC SB TERMINAL-TYPE IS ... IAC
Client is stating the name of his current (or only)
type. The code for IS is 0. (See below.)
3.
WON'T TERMINAL-
Terminal type information will not be exchanged
DON'T TERMINAL-
Terminal type information will not be exchanged
4. Motivation for the
On most machines with bit-mapped displays (e.g., PCs and
workstations) a client terminal emulation program is used to
a conventional ASCII terminal. Most of these programs have
emulation modes, frequently with widely varying characteristics
Likewise, modern host system software and applications can deal
a variety of terminal types. What is needed is a means for
client to present a list of available terminal emulation modes to
server, from which the server can select the one it prefers (
arbitrary reasons). There is also need for a mechanism to
emulation modes during the course of a session, perhaps according
the needs of applications programs
Existing terminal-type passing mechanisms within Telnet were
designed with multiple emulation modes in mind. While multiple
are allowed, they are assumed to be synonyms. Emulation mode
are not defined, and the list of modes can only be scanned once
This document defines a simple extension to the existing mechanisms
which meets both of the above criteria. It makes one
about the behaviour of implementations coded to the previous
in order to obtain full backwards-compatibility
VanBokkelen [Page 2]
RFC 1091 Telnet Terminal-Type Option February 1989
5. Description of the
Willingness to exchange terminal-type information is agreed upon
conventional Telnet option negotiation. WILL and DO are used only
obtain and grant permission for future discussion. The
exchange of status information occurs within option subcommands (
SB TERMINAL-TYPE...).
Once the two hosts have exchanged a WILL and a DO, the sender of
DO TERMINAL-TYPE (the server) is free to request type information
Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE
and only the client may transmit actual type information (within
IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal
information may not be sent spontaneously, but only in response to
request
The terminal type information is an NVT ASCII string. Within
string, upper and lower case are considered equivalent. The
list of valid terminal type names can be found in the
"Assigned Numbers" RFC [4].
The transmission of terminal type information by the Telnet client
response to a query from the Telnet server implies that the
must simultaneously change emulation mode, unless the terminal
sent is a synonym of the preceding terminal type, or there are
prerequisites for entering the new regime (e.g., having agreed
the Telnet binary option). The receipt of such information by
Telnet server does not imply any immediate change of processing
However, the information may be passed to a process, which may
the data it sends to suit the particular characteristics of
terminal. For example, some operating systems have a terminal
that accepts a code indicating the type of terminal being driven
Using the TERMINAL TYPE and BINARY options, a telnet server
on such a system could arrange to have terminals driven as if
were directly connected, including special functions not available
a standard Network Virtual Terminal
Note that this specification is deliberately asymmetric. It
assumed that server operating systems and applications in
cannot change terminal types at arbitrary points in a session. Thus
the client may only send a new type (and potentially change
modes) when the server requests that it do so
6. Implementation
The "terminal type" information may be any NVT ASCII
meaningful to both ends of the negotiation. The list of
type names in "Assigned Numbers" is intended to minimize
VanBokkelen [Page 3]
RFC 1091 Telnet Terminal-Type Option February 1989
caused by alternative "spellings" of the terminal type. For example
confusion would arise if one party were to call a terminal "IBM3278-
2" while the other called it "IBM-3278/2". There is no
acknowledgement for a terminal type that is not understood,
certain other options (such as switching to BINARY mode) may
refused if a valid terminal type name has not been specified
In some cases, either a particular terminal may be known by more
one name, for example a specific type and a more generic type, or
client may be a workstation with integrated display capable
emulating more than one kind of terminal. In such cases, the
of the TERMINAL-TYPE IS command should reply to successive TERMINAL
TYPE SEND commands with the various names. In this way, a
server that does not understand the first response can prompt
alternatives. If different terminal emulations are supported by
client, the mode of the emulator must be changed to match the
type sent, unless the particular emulation has other Telnet
(e.g., BINARY) as prerequisites (in which case, the emulation
switch to the last type sent when the prerequisite is fulfilled).
When types are synonyms, they should be sent in order from most
least specific
When the server (the receiver of the TERMINAL-TYPE IS) receives
same response two consecutive times, this indicates the end of
list of available types. Similarly, the client should indicate
has sent all available names by repeating the last one sent. If
additional request is received, this indicates that the server (
sender of the IS) wishes to return to the top of the list
available types (probably to select the least of N evils).
Server implementations conforming to the previous standard will
sending TERMINAL-TYPE SEND commands after receiving the same
two consecutive times, which will work according to the old standard
It is assumed that client implementations conforming to the
standard will send the last type on the list in response to a
query (as well as the second). New-style servers must recognize
and not send more queries
The type "UNKNOWN" should be used if the type of the terminal
unknown or unlikely to be recognized by the other party
The complete and up-to-date list of terminal type names will
maintained in the "Assigned Numbers". The maximum length of
terminal type name is 40 characters
7. User
Telnet clients and servers conforming to this specification
VanBokkelen [Page 4]
RFC 1091 Telnet Terminal-Type Option February 1989
provide the following functions in their user interfaces
Clients supporting multiple emulation modes should allow the user
specify which of the modes is preferred (which name is sent first),
prior to connection establishment. The order of the names
cannot be changed after the negotiation has begun. This initial
will also become the default with servers which do not
TERMINAL TYPE
Servers should store the current terminal type name and the list
available names in a manner such that they are accessible to both
user (via a keyboard command) and any applications which need
information. In addition, there should be a corresponding
to request a change of terminal types, by initiating a series
SEND/IS sub-negotiations
8.
In this example, the server finds the first type acceptable
Server: IAC DO TERMINAL-
Client: IAC WILL TERMINAL-
(Server may now request a terminal type at any time.)
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC
In this example, the server requests additional terminal types,
accepts the second (and last on the client's list) type sent (RFC 930
compatible):
Server: IAC DO TERMINAL-
Client: IAC WILL TERMINAL-
(Server may now request a terminal type at any time.)
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS ZENITH-H19 IAC
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC
VanBokkelen [Page 5]
RFC 1091 Telnet Terminal-Type Option February 1989
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC
In this example, the server requests additional terminal types,
proceeds beyond the end-of-list, to select the first type offered
the client (new-type client and server):
Server: IAC DO TERMINAL-
Client: IAC WILL TERMINAL-
(Server may now request a terminal type at any time.)
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS DEC-VT100 IAC
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC
Server: IAC SB TERMINAL-TYPE SEND IAC
Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC
9. References
[1] Postel, J., and J. Reynolds, "Telnet Protocol Specification",
RFC 854, USC Information Sciences Institute, May 1983.
[2] Postel, J., and J. Reynolds, "Telnet Option Specification",
RFC 855, USC Information Sciences Institute, May 1983.
[3] Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
RFC 930, University of Wisconsin - Madison, January 1985.
[4] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1010,
USC Information Sciences Institute, May 1987.
VanBokkelen [Page 6]
RFC 1091 Telnet Terminal-Type Option February 1989
Reviser's note
I owe much of this text to RFCs 884 and 930, by Marvin Solomon
Edward Wimmers of the University of Wisconsin - Madison, and I
the idea of the extension to discussions on the "tn3270" mailing
in the Summer of 1987.
Author's
James
FTP Software, Inc
26 Princess
Wakefield, MA 01880-3004
Phone: (617) 246-0900
Email: jbvb@ftp.
VanBokkelen [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
