As per Relevance of the word terminal, we have this rfc below:
Network Working Group Marvin
Request for Comments: 930 Edward
Supersedes: RFC 884 University of Wisconsin -
January 1985
TELNET TERMINAL TYPE
Status of This
This RFC specifies a standard for the ARPA Internet community.
on the ARPA Internet that exchange terminal type information
the Telnet protocol are expected to adopt and implement
standard. Distribution of this memo is unlimited
This standard supersedes RFC 884. The only change is to specify
the TERMINAL-TYPE IS sub-negotiation should be sent only in
to the TERMINAL-TYPE SEND sub-negotiation. See below for
explanation
1. Command Name and
TERMINAL-TYPE 24
2. Command
IAC WILL TERMINAL-
Sender is willing to send terminal type information in
subsequent sub-
IAC WON'T TERMINAL-
Sender refuses to send terminal type
IAC DO TERMINAL-
Sender is willing to receive terminal type information in
subsequent sub-
IAC DON'T TERMINAL-
Sender refuses to accept terminal type
IAC SB TERMINAL-TYPE SEND IAC
Sender requests receiver to transmit his (the receiver's)
type. The code for SEND is 1. (See below.)
Solomon & Wimmers [Page 1]
RFC 930 January 1985
Telnet Terminal Type
IAC SB TERMINAL-TYPE IS ... IAC
Sender is stating the name of his terminal type. The code for
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
This option allows a telnet server to determine the type of
connected to a user telnet program. The transmission of
information does not immediately imply any 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 such special functions as
addressing, multiple colors, etc., not included in the
Virtual Terminal specification. This option fits into the
structure of TELNET options by deferring the actual transfer
status information to the SB command
5. Description of the
WILL and DO are used only to obtain and grant permission for
discussion. The actual exchange of status information occurs
option subcommands (IAC SB TERMINAL-TYPE...).
Once the two hosts have exchanged a WILL and a DO, the sender of
DO TERMINAL-TYPE is free to request type information. Only
sender of the DO may send requests (IAC SB TERMINAL-TYPE SEND IAC SE
and only the sender of the WILL may transmit actual type
(within an IAC SB TERMINAL-TYPE IS ... IAC SE command).
type information may not be sent spontaneously, but only in
to a request
The terminal type information is an NVT ASCII string. Within
Solomon & Wimmers [Page 2]
RFC 930 January 1985
Telnet Terminal Type
string, upper and lower case are considered equivalent. The
list of valid terminal type names can be found in the
"Assigned Numbers" RFC
The following is an example of use of the option
Host1: IAC DO TERMINAL-
Host2: IAC WILL TERMINAL-
(Host1 is now free to request status information at any time.)
Host1: IAC SB TERMINAL-TYPE SEND IAC
Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC
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
caused by alternative "spellings" of the terminal type. For example
confusion would arise if one party were to call a
"IBM3278-2" while the other called it "IBM-3278/2". There is
negative acknowledgement for a terminal type that is not understood
but certain other options (such as switching to BINARY mode) may
refused if a valid terminal type name has not been specified.
some cases, a particular terminal may be known by more than one name
for example a specific type and a more generic type. In such cases
the sender of the TERMINAL-TYPE IS command should reply to
TERMINAL-TYPE SEND commands with the various names, from most
least specific. In this way, a telnet server that does
understand the first response can prompt for alternatives. However
it should cease sending TERMINAL-TYPE SEND commands after
the same response two consecutive times. Similarly, a sender
indicate it has sent all available names by repeating the last
sent. Note that TERMINAL-TYPE IS must only be sent in response to
request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-
IS and then received TERMINAL-TYPE SEND couldn't determine
the other host was requesting a second option or the TERMINAL-
SEND and the TERMINAL-TYPE IS crossed in midstream
The type "UNKNOWN" should be used if the type of the terminal
unknown or unlikely to be recognized by the other party
Solomon & Wimmers [Page 3]
RFC 930 January 1985
Telnet Terminal Type
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
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
