1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
<pre>Network Working Group Marvin Solomon
Request for Comments: 930 Edward Wimmers
Supersedes: <a href="./rfc884">RFC 884</a> University of Wisconsin - Madison
January 1985
<span class="h1">TELNET TERMINAL TYPE OPTION</span>
Status of This Memo
This RFC specifies a standard for the ARPA Internet community. Hosts
on the ARPA Internet that exchange terminal type information within
the Telnet protocol are expected to adopt and implement this
standard. Distribution of this memo is unlimited.
This standard supersedes <a href="./rfc884">RFC 884</a>. The only change is to specify that
the TERMINAL-TYPE IS sub-negotiation should be sent only in response
to the TERMINAL-TYPE SEND sub-negotiation. See below for further
explanation.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Command Name and Code</span>
TERMINAL-TYPE 24
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Command Meanings</span>
IAC WILL TERMINAL-TYPE
Sender is willing to send terminal type information in a
subsequent sub-negotiation
IAC WON'T TERMINAL-TYPE
Sender refuses to send terminal type information
IAC DO TERMINAL-TYPE
Sender is willing to receive terminal type information in a
subsequent sub-negotiation
IAC DON'T TERMINAL-TYPE
Sender refuses to accept terminal type information
IAC SB TERMINAL-TYPE SEND IAC SE
Sender requests receiver to transmit his (the receiver's) terminal
type. The code for SEND is 1. (See below.)
<span class="grey">Solomon & Wimmers [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc930">RFC 930</a> January 1985</span>
Telnet Terminal Type Option
IAC SB TERMINAL-TYPE IS ... IAC SE
Sender is stating the name of his terminal type. The code for IS
is 0. (See below.)
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Default</span>
WON'T TERMINAL-TYPE
Terminal type information will not be exchanged.
DON'T TERMINAL-TYPE
Terminal type information will not be exchanged.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Motivation for the Option</span>
This option allows a telnet server to determine the type of terminal
connected to a user telnet program. The transmission of such
information does not immediately imply any change of processing.
However, the information may be passed to a process, which may alter
the data it sends to suit the particular characteristics of the
terminal. For example, some operating systems have a terminal driver
that accepts a code indicating the type of terminal being driven.
Using the TERMINAL TYPE and BINARY options, a telnet server program
on such a system could arrange to have terminals driven as if they
were directly connected, including such special functions as cursor
addressing, multiple colors, etc., not included in the Network
Virtual Terminal specification. This option fits into the normal
structure of TELNET options by deferring the actual transfer of
status information to the SB command.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Description of the Option</span>
WILL and DO are used only to obtain and grant permission for future
discussion. The actual exchange of status information occurs within
option subcommands (IAC SB TERMINAL-TYPE...).
Once the two hosts have exchanged a WILL and a DO, the sender of the
DO TERMINAL-TYPE is free to request type information. Only the
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 information
(within an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal
type information may not be sent spontaneously, but only in response
to a request.
The terminal type information is an NVT ASCII string. Within this
<span class="grey">Solomon & Wimmers [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc930">RFC 930</a> January 1985</span>
Telnet Terminal Type Option
string, upper and lower case are considered equivalent. The complete
list of valid terminal type names can be found in the latest
"Assigned Numbers" RFC.
The following is an example of use of the option:
Host1: IAC DO TERMINAL-TYPE
Host2: IAC WILL TERMINAL-TYPE
(Host1 is now free to request status information at any time.)
Host1: IAC SB TERMINAL-TYPE SEND IAC SE
Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Implementation Suggestions</span>
The "terminal type" information may be any NVT ASCII string
meaningful to both ends of the negotiation. The list of terminal
type names in "Assigned Numbers" is intended to minimize confusion
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
negative acknowledgement for a terminal type that is not understood,
but certain other options (such as switching to BINARY mode) may be
refused if a valid terminal type name has not been specified. In
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 successive
TERMINAL-TYPE SEND commands with the various names, from most to
least specific. In this way, a telnet server that does not
understand the first response can prompt for alternatives. However,
it should cease sending TERMINAL-TYPE SEND commands after receiving
the same response two consecutive times. Similarly, a sender should
indicate it has sent all available names by repeating the last one
sent. Note that TERMINAL-TYPE IS must only be sent in response to a
request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-TYPE
IS and then received TERMINAL-TYPE SEND couldn't determine whether
the other host was requesting a second option or the TERMINAL-TYPE
SEND and the TERMINAL-TYPE IS crossed in midstream.
The type "UNKNOWN" should be used if the type of the terminal is
unknown or unlikely to be recognized by the other party.
<span class="grey">Solomon & Wimmers [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc930">RFC 930</a> January 1985</span>
Telnet Terminal Type Option
The complete and up-to-date list of terminal type names will be
maintained in the "Assigned Numbers". The maximum length of a
terminal type name is 40 characters.
Solomon & Wimmers [Page 4]
</pre>
|
