source: PinConnection/rfc854 telnet.htm

Last change on this file was 408, checked in by chronos, 13 years ago
  • Added: PinConnection package now have partialy implemented TCommTelnet class for handling telnet commands.
File size: 49.2 KB
Line 
1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
2<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
3 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
4 <meta name="robots" content="index,follow">
5 <meta name="creator" content="rfcmarkup version 1.101">
6 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
7<meta name="DC.Relation.Replaces" content="rfc764">
8<meta name="DC.Identifier" content="urn:ietf:rfc:854">
9<meta name="DC.Date.Issued" content="May, 1983">
10<meta name="DC.Creator" content="Postel, J.">
11<meta name="DC.Creator" content="Reynolds, J.K.">
12<meta name="DC.Description.Abstract" content="This is the specification of the Telnet protocol used for remote\nterminal access in the ARPA Internet. The purpose of the TELNET\nProtocol is to provide a fairly general, bi-directional, eight-bit\nbyte oriented communications facility. Its primary goal is to allow a\nstandard method of interfacing terminal devices and terminal-oriented\nprocesses to each other. It is envisioned that the protocol may also\nbe used for terminal-terminal communication (&quot;linking&quot;) and process-\nprocess communication (distributed computation). This RFC specifies a\nstandard for the ARPA Internet community. Hosts on the ARPA Internet\nare expected to adopt and implement this standard. Obsoletes NIC\n18639.">
13<meta name="DC.Title" content="Telnet Protocol Specification">
14
15 <link rel="icon" href="http://tools.ietf.org/images/rfc.png" type="image/png">
16 <link rel="shortcut icon" href="http://tools.ietf.org/images/rfc.png" type="image/png">
17 <title>RFC 854 - Telnet Protocol Specification</title>
18
19
20 <style type="text/css">
21 body {
22 margin: 0px 8px;
23 font-size: 1em;
24 }
25 h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
26 font-weight: bold;
27 line-height: 0pt;
28 display: inline;
29 white-space: pre;
30 font-family: monospace;
31 font-size: 1em;
32 font-weight: bold;
33 }
34 pre {
35 font-size: 1em;
36 margin-top: 0px;
37 margin-bottom: 0px;
38 }
39 .pre {
40 white-space: pre;
41 font-family: monospace;
42 }
43 .header{
44 font-weight: bold;
45 }
46 .newpage {
47 page-break-before: always;
48 }
49 .invisible {
50 text-decoration: none;
51 color: white;
52 }
53 a.selflink {
54 color: black;
55 text-decoration: none;
56 }
57 @media print {
58 body {
59 font-family: monospace;
60 font-size: 10.5pt;
61 }
62 h1, h2, h3, h4, h5, h6 {
63 font-size: 1em;
64 }
65
66 a:link, a:visited {
67 color: inherit;
68 text-decoration: none;
69 }
70 .noprint {
71 display: none;
72 }
73 }
74 @media screen {
75 .grey, .grey a:link, .grey a:visited {
76 color: #777;
77 }
78 .docinfo {
79 background-color: #EEE;
80 }
81 .top {
82 border-top: 7px solid #EEE;
83 }
84 .bgwhite { background-color: white; }
85 .bgred { background-color: #F44; }
86 .bggrey { background-color: #666; }
87 .bgbrown { background-color: #840; }
88 .bgorange { background-color: #FA0; }
89 .bgyellow { background-color: #EE0; }
90 .bgmagenta{ background-color: #F4F; }
91 .bgblue { background-color: #66F; }
92 .bgcyan { background-color: #4DD; }
93 .bggreen { background-color: #4F4; }
94
95 .legend { font-size: 90%; }
96 .cplate { font-size: 70%; border: solid grey 1px; }
97 }
98 </style>
99 <!--[if IE]>
100 <style>
101 body {
102 font-size: 13px;
103 margin: 10px 10px;
104 }
105 </style>
106 <![endif]-->
107
108 <script type="text/javascript"><!--
109 function addHeaderTags() {
110 var spans = document.getElementsByTagName("span");
111 for (var i=0; i < spans.length; i++) {
112 var elem = spans[i];
113 if (elem) {
114 var level = elem.getAttribute("class");
115 if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
116 elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
117 }
118 }
119 }
120 }
121 var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Best Common Practice:</td><td><span class='cplate bgmagenta'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Proposed Standard:</td><td><span class='cplate bgblue'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Draft Standard:</td> <td><span class='cplate bgcyan'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Standard:</td> <td><span class='cplate bggreen'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'>&nbsp;&nbsp;&nbsp;&nbsp;</span></td></tr> </table>";
122 function showElem(id) {
123 var elem = document.getElementById(id);
124 elem.innerHTML = eval(id+"_html");
125 elem.style.visibility='visible';
126 }
127 function hideElem(id) {
128 var elem = document.getElementById(id);
129 elem.style.visibility='hidden';
130 elem.innerHTML = "";
131 }
132 // -->
133 </script>
134</head>
135<body onload="addHeaderTags()">
136 <div style="height: 13px;">
137 <div onmouseover="this.style.cursor='pointer';" onclick="showElem('legend');" onmouseout="hideElem('legend')" style="height: 6px; position: absolute;" class="pre noprint docinfo bggreen" title="Click for colour legend."> </div>
138 <div id="legend" class="docinfo noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showElem('legend');" onmouseout="hideElem('legend');">
139 </div>
140 </div>
141<span class="pre noprint docinfo top">[<a href="http://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/rfc/rfc854.txt" title="Plaintext version of this document">txt</a>|<a href="http://tools.ietf.org/pdf/rfc854" title="PDF version of this document">pdf</a>] [<a href="http://www.rfc-editor.org/errata_search.php?rfc=854">Errata</a>] </span><br>
142<span class="pre noprint docinfo"> </span><br>
143<span class="pre noprint docinfo">Updated by: <a href="http://tools.ietf.org/html/rfc5198">5198</a> STANDARD</span><br>
144<span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br>
145<pre>Network Working Group J. Postel
146Request for Comments: 854 J. Reynolds
147 ISI
148Obsoletes: NIC 18639 May 1983
149
150 <span class="h1"><h1>TELNET PROTOCOL SPECIFICATION</h1></span>
151
152
153This RFC specifies a standard for the ARPA Internet community. Hosts on
154the ARPA Internet are expected to adopt and implement this standard.
155
156INTRODUCTION
157
158 The purpose of the TELNET Protocol is to provide a fairly general,
159 bi-directional, eight-bit byte oriented communications facility. Its
160 primary goal is to allow a standard method of interfacing terminal
161 devices and terminal-oriented processes to each other. It is
162 envisioned that the protocol may also be used for terminal-terminal
163 communication ("linking") and process-process communication
164 (distributed computation).
165
166GENERAL CONSIDERATIONS
167
168 A TELNET connection is a Transmission Control Protocol (TCP)
169 connection used to transmit data with interspersed TELNET control
170 information.
171
172 The TELNET Protocol is built upon three main ideas: first, the
173 concept of a "Network Virtual Terminal"; second, the principle of
174 negotiated options; and third, a symmetric view of terminals and
175 processes.
176
177 1. When a TELNET connection is first established, each end is
178 assumed to originate and terminate at a "Network Virtual Terminal",
179 or NVT. An NVT is an imaginary device which provides a standard,
180 network-wide, intermediate representation of a canonical terminal.
181 This eliminates the need for "server" and "user" hosts to keep
182 information about the characteristics of each other's terminals and
183 terminal handling conventions. All hosts, both user and server, map
184 their local device characteristics and conventions so as to appear to
185 be dealing with an NVT over the network, and each can assume a
186 similar mapping by the other party. The NVT is intended to strike a
187 balance between being overly restricted (not providing hosts a rich
188 enough vocabulary for mapping into their local character sets), and
189 being overly inclusive (penalizing users with modest terminals).
190
191 NOTE: The "user" host is the host to which the physical terminal
192 is normally attached, and the "server" host is the host which is
193 normally providing some service. As an alternate point of view,
194
195
196
197
198<span class="grey">Postel &amp; Reynolds [Page 1]</span>
199</pre><!--NewPage--><pre class="newpage"><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
200<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
201
202
203 applicable even in terminal-to-terminal or process-to-process
204 communications, the "user" host is the host which initiated the
205 communication.
206
207 2. The principle of negotiated options takes cognizance of the fact
208 that many hosts will wish to provide additional services over and
209 above those available within an NVT, and many users will have
210 sophisticated terminals and would like to have elegant, rather than
211 minimal, services. Independent of, but structured within the TELNET
212 Protocol are various "options" that will be sanctioned and may be
213 used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to
214 allow a user and server to agree to use a more elaborate (or perhaps
215 just different) set of conventions for their TELNET connection. Such
216 options could include changing the character set, the echo mode, etc.
217
218 The basic strategy for setting up the use of options is to have
219 either party (or both) initiate a request that some option take
220 effect. The other party may then either accept or reject the
221 request. If the request is accepted the option immediately takes
222 effect; if it is rejected the associated aspect of the connection
223 remains as specified for an NVT. Clearly, a party may always refuse
224 a request to enable, and must never refuse a request to disable some
225 option since all parties must be prepared to support the NVT.
226
227 The syntax of option negotiation has been set up so that if both
228 parties request an option simultaneously, each will see the other's
229 request as the positive acknowledgment of its own.
230
231 3. The symmetry of the negotiation syntax can potentially lead to
232 nonterminating acknowledgment loops -- each party seeing the incoming
233 commands not as acknowledgments but as new requests which must be
234 acknowledged. To prevent such loops, the following rules prevail:
235
236 a. Parties may only request a change in option status; i.e., a
237 party may not send out a "request" merely to announce what mode it
238 is in.
239
240 b. If a party receives what appears to be a request to enter some
241 mode it is already in, the request should not be acknowledged.
242 This non-response is essential to prevent endless loops in the
243 negotiation. It is required that a response be sent to requests
244 for a change of mode -- even if the mode is not changed.
245
246 c. Whenever one party sends an option command to a second party,
247 whether as a request or an acknowledgment, and use of the option
248 will have any effect on the processing of the data being sent from
249 the first party to the second, then the command must be inserted
250 in the data stream at the point where it is desired that it take
251
252
253<span class="grey">Postel &amp; Reynolds [Page 2]</span>
254</pre><!--NewPage--><pre class="newpage"><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
255<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
256
257
258 effect. (It should be noted that some time will elapse between
259 the transmission of a request and the receipt of an
260 acknowledgment, which may be negative. Thus, a host may wish to
261 buffer data, after requesting an option, until it learns whether
262 the request is accepted or rejected, in order to hide the
263 "uncertainty period" from the user.)
264
265 Option requests are likely to flurry back and forth when a TELNET
266 connection is first established, as each party attempts to get the
267 best possible service from the other party. Beyond that, however,
268 options can be used to dynamically modify the characteristics of the
269 connection to suit changing local conditions. For example, the NVT,
270 as will be explained later, uses a transmission discipline well
271 suited to the many "line at a time" applications such as BASIC, but
272 poorly suited to the many "character at a time" applications such as
273 NLS. A server might elect to devote the extra processor overhead
274 required for a "character at a time" discipline when it was suitable
275 for the local process and would negotiate an appropriate option.
276 However, rather than then being permanently burdened with the extra
277 processing overhead, it could switch (i.e., negotiate) back to NVT
278 when the detailed control was no longer necessary.
279
280 It is possible for requests initiated by processes to stimulate a
281 nonterminating request loop if the process responds to a rejection by
282 merely re-requesting the option. To prevent such loops from
283 occurring, rejected requests should not be repeated until something
284 changes. Operationally, this can mean the process is running a
285 different program, or the user has given another command, or whatever
286 makes sense in the context of the given process and the given option.
287 A good rule of thumb is that a re-request should only occur as a
288 result of subsequent information from the other end of the connection
289 or when demanded by local human intervention.
290
291 Option designers should not feel constrained by the somewhat limited
292 syntax available for option negotiation. The intent of the simple
293 syntax is to make it easy to have options -- since it is
294 correspondingly easy to profess ignorance about them. If some
295 particular option requires a richer negotiation structure than
296 possible within "DO, DON'T, WILL, WON'T", the proper tack is to use
297 "DO, DON'T, WILL, WON'T" to establish that both parties understand
298 the option, and once this is accomplished a more exotic syntax can be
299 used freely. For example, a party might send a request to alter
300 (establish) line length. If it is accepted, then a different syntax
301 can be used for actually negotiating the line length -- such a
302 "sub-negotiation" might include fields for minimum allowable, maximum
303 allowable and desired line lengths. The important concept is that
304
305
306
307
308<span class="grey">Postel &amp; Reynolds [Page 3]</span>
309</pre><!--NewPage--><pre class="newpage"><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
310<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
311
312
313 such expanded negotiations should never begin until some prior
314 (standard) negotiation has established that both parties are capable
315 of parsing the expanded syntax.
316
317 In summary, WILL XXX is sent, by either party, to indicate that
318 party's desire (offer) to begin performing option XXX, DO XXX and
319 DON'T XXX being its positive and negative acknowledgments; similarly,
320 DO XXX is sent to indicate a desire (request) that the other party
321 (i.e., the recipient of the DO) begin performing option XXX, WILL XXX
322 and WON'T XXX being the positive and negative acknowledgments. Since
323 the NVT is what is left when no options are enabled, the DON'T and
324 WON'T responses are guaranteed to leave the connection in a state
325 which both ends can handle. Thus, all hosts may implement their
326 TELNET processes to be totally unaware of options that are not
327 supported, simply returning a rejection to (i.e., refusing) any
328 option request that cannot be understood.
329
330 As much as possible, the TELNET protocol has been made server-user
331 symmetrical so that it easily and naturally covers the user-user
332 (linking) and server-server (cooperating processes) cases. It is
333 hoped, but not absolutely required, that options will further this
334 intent. In any case, it is explicitly acknowledged that symmetry is
335 an operating principle rather than an ironclad rule.
336
337 A companion document, "TELNET Option Specifications," should be
338 consulted for information about the procedure for establishing new
339 options.
340
341THE NETWORK VIRTUAL TERMINAL
342
343 The Network Virtual Terminal (NVT) is a bi-directional character
344 device. The NVT has a printer and a keyboard. The printer responds
345 to incoming data and the keyboard produces outgoing data which is
346 sent over the TELNET connection and, if "echoes" are desired, to the
347 NVT's printer as well. "Echoes" will not be expected to traverse the
348 network (although options exist to enable a "remote" echoing mode of
349 operation, no host is required to implement this option). The code
350 set is seven-bit USASCII in an eight-bit field, except as modified
351 herein. Any code conversion and timing considerations are local
352 problems and do not affect the NVT.
353
354 TRANSMISSION OF DATA
355
356 Although a TELNET connection through the network is intrinsically
357 full duplex, the NVT is to be viewed as a half-duplex device
358 operating in a line-buffered mode. That is, unless and until
359
360
361
362
363<span class="grey">Postel &amp; Reynolds [Page 4]</span>
364</pre><!--NewPage--><pre class="newpage"><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
365<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
366
367
368 options are negotiated to the contrary, the following default
369 conditions pertain to the transmission of data over the TELNET
370 connection:
371
372 1) Insofar as the availability of local buffer space permits,
373 data should be accumulated in the host where it is generated
374 until a complete line of data is ready for transmission, or
375 until some locally-defined explicit signal to transmit occurs.
376 This signal could be generated either by a process or by a
377 human user.
378
379 The motivation for this rule is the high cost, to some hosts,
380 of processing network input interrupts, coupled with the
381 default NVT specification that "echoes" do not traverse the
382 network. Thus, it is reasonable to buffer some amount of data
383 at its source. Many systems take some processing action at the
384 end of each input line (even line printers or card punches
385 frequently tend to work this way), so the transmission should
386 be triggered at the end of a line. On the other hand, a user
387 or process may sometimes find it necessary or desirable to
388 provide data which does not terminate at the end of a line;
389 therefore implementers are cautioned to provide methods of
390 locally signaling that all buffered data should be transmitted
391 immediately.
392
393 2) When a process has completed sending data to an NVT printer
394 and has no queued input from the NVT keyboard for further
395 processing (i.e., when a process at one end of a TELNET
396 connection cannot proceed without input from the other end),
397 the process must transmit the TELNET Go Ahead (GA) command.
398
399 This rule is not intended to require that the TELNET GA command
400 be sent from a terminal at the end of each line, since server
401 hosts do not normally require a special signal (in addition to
402 end-of-line or other locally-defined characters) in order to
403 commence processing. Rather, the TELNET GA is designed to help
404 a user's local host operate a physically half duplex terminal
405 which has a "lockable" keyboard such as the IBM 2741. A
406 description of this type of terminal may help to explain the
407 proper use of the GA command.
408
409 The terminal-computer connection is always under control of
410 either the user or the computer. Neither can unilaterally
411 seize control from the other; rather the controlling end must
412 relinguish its control explicitly. At the terminal end, the
413 hardware is constructed so as to relinquish control each time
414 that a "line" is terminated (i.e., when the "New Line" key is
415 typed by the user). When this occurs, the attached (local)
416
417
418<span class="grey">Postel &amp; Reynolds [Page 5]</span>
419</pre><!--NewPage--><pre class="newpage"><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
420<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
421
422
423 computer processes the input data, decides if output should be
424 generated, and if not returns control to the terminal. If
425 output should be generated, control is retained by the computer
426 until all output has been transmitted.
427
428 The difficulties of using this type of terminal through the
429 network should be obvious. The "local" computer is no longer
430 able to decide whether to retain control after seeing an
431 end-of-line signal or not; this decision can only be made by
432 the "remote" computer which is processing the data. Therefore,
433 the TELNET GA command provides a mechanism whereby the "remote"
434 (server) computer can signal the "local" (user) computer that
435 it is time to pass control to the user of the terminal. It
436 should be transmitted at those times, and only at those times,
437 when the user should be given control of the terminal. Note
438 that premature transmission of the GA command may result in the
439 blocking of output, since the user is likely to assume that the
440 transmitting system has paused, and therefore he will fail to
441 turn the line around manually.
442
443 The foregoing, of course, does not apply to the user-to-server
444 direction of communication. In this direction, GAs may be sent at
445 any time, but need not ever be sent. Also, if the TELNET
446 connection is being used for process-to-process communication, GAs
447 need not be sent in either direction. Finally, for
448 terminal-to-terminal communication, GAs may be required in
449 neither, one, or both directions. If a host plans to support
450 terminal-to-terminal communication it is suggested that the host
451 provide the user with a means of manually signaling that it is
452 time for a GA to be sent over the TELNET connection; this,
453 however, is not a requirement on the implementer of a TELNET
454 process.
455
456 Note that the symmetry of the TELNET model requires that there is
457 an NVT at each end of the TELNET connection, at least
458 conceptually.
459
460 STANDARD REPRESENTATION OF CONTROL FUNCTIONS
461
462 As stated in the Introduction to this document, the primary goal
463 of the TELNET protocol is the provision of a standard interfacing
464 of terminal devices and terminal-oriented processes through the
465 network. Early experiences with this type of interconnection have
466 shown that certain functions are implemented by most servers, but
467 that the methods of invoking these functions differ widely. For a
468 human user who interacts with several server systems, these
469 differences are highly frustrating. TELNET, therefore, defines a
470 standard representation for five of these functions, as described
471
472
473<span class="grey">Postel &amp; Reynolds [Page 6]</span>
474</pre><!--NewPage--><pre class="newpage"><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
475<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
476
477
478 below. These standard representations have standard, but not
479 required, meanings (with the exception that the Interrupt Process
480 (IP) function may be required by other protocols which use
481 TELNET); that is, a system which does not provide the function to
482 local users need not provide it to network users and may treat the
483 standard representation for the function as a No-operation. On
484 the other hand, a system which does provide the function to a
485 local user is obliged to provide the same function to a network
486 user who transmits the standard representation for the function.
487
488 Interrupt Process (IP)
489
490 Many systems provide a function which suspends, interrupts,
491 aborts, or terminates the operation of a user process. This
492 function is frequently used when a user believes his process is
493 in an unending loop, or when an unwanted process has been
494 inadvertently activated. IP is the standard representation for
495 invoking this function. It should be noted by implementers
496 that IP may be required by other protocols which use TELNET,
497 and therefore should be implemented if these other protocols
498 are to be supported.
499
500 Abort Output (AO)
501
502 Many systems provide a function which allows a process, which
503 is generating output, to run to completion (or to reach the
504 same stopping point it would reach if running to completion)
505 but without sending the output to the user's terminal.
506 Further, this function typically clears any output already
507 produced but not yet actually printed (or displayed) on the
508 user's terminal. AO is the standard representation for
509 invoking this function. For example, some subsystem might
510 normally accept a user's command, send a long text string to
511 the user's terminal in response, and finally signal readiness
512 to accept the next command by sending a "prompt" character
513 (preceded by &lt;CR&gt;&lt;LF&gt;) to the user's terminal. If the AO were
514 received during the transmission of the text string, a
515 reasonable implementation would be to suppress the remainder of
516 the text string, but transmit the prompt character and the
517 preceding &lt;CR&gt;&lt;LF&gt;. (This is possibly in distinction to the
518 action which might be taken if an IP were received; the IP
519 might cause suppression of the text string and an exit from the
520 subsystem.)
521
522 It should be noted, by server systems which provide this
523 function, that there may be buffers external to the system (in
524
525
526
527
528<span class="grey">Postel &amp; Reynolds [Page 7]</span>
529</pre><!--NewPage--><pre class="newpage"><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
530<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
531
532
533 the network and the user's local host) which should be cleared;
534 the appropriate way to do this is to transmit the "Synch"
535 signal (described below) to the user system.
536
537 Are You There (AYT)
538
539 Many systems provide a function which provides the user with
540 some visible (e.g., printable) evidence that the system is
541 still up and running. This function may be invoked by the user
542 when the system is unexpectedly "silent" for a long time,
543 because of the unanticipated (by the user) length of a
544 computation, an unusually heavy system load, etc. AYT is the
545 standard representation for invoking this function.
546
547 Erase Character (EC)
548
549 Many systems provide a function which deletes the last
550 preceding undeleted character or "print position"* from the
551 stream of data being supplied by the user. This function is
552 typically used to edit keyboard input when typing mistakes are
553 made. EC is the standard representation for invoking this
554 function.
555
556 *NOTE: A "print position" may contain several characters
557 which are the result of overstrikes, or of sequences such as
558 &lt;char1&gt; BS &lt;char2&gt;...
559
560 Erase Line (EL)
561
562 Many systems provide a function which deletes all the data in
563 the current "line" of input. This function is typically used
564 to edit keyboard input. EL is the standard representation for
565 invoking this function.
566
567 THE TELNET "SYNCH" SIGNAL
568
569 Most time-sharing systems provide mechanisms which allow a
570 terminal user to regain control of a "runaway" process; the IP and
571 AO functions described above are examples of these mechanisms.
572 Such systems, when used locally, have access to all of the signals
573 supplied by the user, whether these are normal characters or
574 special "out of band" signals such as those supplied by the
575 teletype "BREAK" key or the IBM 2741 "ATTN" key. This is not
576 necessarily true when terminals are connected to the system
577 through the network; the network's flow control mechanisms may
578 cause such a signal to be buffered elsewhere, for example in the
579 user's host.
580
581
582
583<span class="grey">Postel &amp; Reynolds [Page 8]</span>
584</pre><!--NewPage--><pre class="newpage"><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
585<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
586
587
588 To counter this problem, the TELNET "Synch" mechanism is
589 introduced. A Synch signal consists of a TCP Urgent notification,
590 coupled with the TELNET command DATA MARK. The Urgent
591 notification, which is not subject to the flow control pertaining
592 to the TELNET connection, is used to invoke special handling of
593 the data stream by the process which receives it. In this mode,
594 the data stream is immediately scanned for "interesting" signals
595 as defined below, discarding intervening data. The TELNET command
596 DATA MARK (DM) is the synchronizing mark in the data stream which
597 indicates that any special signal has already occurred and the
598 recipient can return to normal processing of the data stream.
599
600 The Synch is sent via the TCP send operation with the Urgent
601 flag set and the DM as the last (or only) data octet.
602
603 When several Synchs are sent in rapid succession, the Urgent
604 notifications may be merged. It is not possible to count Urgents
605 since the number received will be less than or equal the number
606 sent. When in normal mode, a DM is a no operation; when in urgent
607 mode, it signals the end of the urgent processing.
608
609 If TCP indicates the end of Urgent data before the DM is found,
610 TELNET should continue the special handling of the data stream
611 until the DM is found.
612
613 If TCP indicates more Urgent data after the DM is found, it can
614 only be because of a subsequent Synch. TELNET should continue
615 the special handling of the data stream until another DM is
616 found.
617
618 "Interesting" signals are defined to be: the TELNET standard
619 representations of IP, AO, and AYT (but not EC or EL); the local
620 analogs of these standard representations (if any); all other
621 TELNET commands; other site-defined signals which can be acted on
622 without delaying the scan of the data stream.
623
624 Since one effect of the SYNCH mechanism is the discarding of
625 essentially all characters (except TELNET commands) between the
626 sender of the Synch and its recipient, this mechanism is specified
627 as the standard way to clear the data path when that is desired.
628 For example, if a user at a terminal causes an AO to be
629 transmitted, the server which receives the AO (if it provides that
630 function at all) should return a Synch to the user.
631
632 Finally, just as the TCP Urgent notification is needed at the
633 TELNET level as an out-of-band signal, so other protocols which
634 make use of TELNET may require a TELNET command which can be
635 viewed as an out-of-band signal at a different level.
636
637
638<span class="grey">Postel &amp; Reynolds [Page 9]</span>
639</pre><!--NewPage--><pre class="newpage"><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
640<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
641
642
643 By convention the sequence [IP, Synch] is to be used as such a
644 signal. For example, suppose that some other protocol, which uses
645 TELNET, defines the character string STOP analogously to the
646 TELNET command AO. Imagine that a user of this protocol wishes a
647 server to process the STOP string, but the connection is blocked
648 because the server is processing other commands. The user should
649 instruct his system to:
650
651 1. Send the TELNET IP character;
652
653 2. Send the TELNET SYNC sequence, that is:
654
655 Send the Data Mark (DM) as the only character
656 in a TCP urgent mode send operation.
657
658 3. Send the character string STOP; and
659
660 4. Send the other protocol's analog of the TELNET DM, if any.
661
662 The user (or process acting on his behalf) must transmit the
663 TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
664 gets through to the server's TELNET interpreter.
665
666 The Urgent should wake up the TELNET process; the IP should
667 wake up the next higher level process.
668
669 THE NVT PRINTER AND KEYBOARD
670
671 The NVT printer has an unspecified carriage width and page length
672 and can produce representations of all 95 USASCII graphics (codes
673 32 through 126). Of the 33 USASCII control codes (0 through 31
674 and 127), and the 128 uncovered codes (128 through 255), the
675 following have specified meaning to the NVT printer:
676
677 NAME CODE MEANING
678
679 NULL (NUL) 0 No Operation
680 Line Feed (LF) 10 Moves the printer to the
681 next print line, keeping the
682 same horizontal position.
683 Carriage Return (CR) 13 Moves the printer to the left
684 margin of the current line.
685
686
687
688
689
690
691
692
693<span class="grey">Postel &amp; Reynolds [Page 10]</span>
694</pre><!--NewPage--><pre class="newpage"><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
695<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
696
697
698 In addition, the following codes shall have defined, but not
699 required, effects on the NVT printer. Neither end of a TELNET
700 connection may assume that the other party will take, or will
701 have taken, any particular action upon receipt or transmission
702 of these:
703
704 BELL (BEL) 7 Produces an audible or
705 visible signal (which does
706 NOT move the print head).
707 Back Space (BS) 8 Moves the print head one
708 character position towards
709 the left margin.
710 Horizontal Tab (HT) 9 Moves the printer to the
711 next horizontal tab stop.
712 It remains unspecified how
713 either party determines or
714 establishes where such tab
715 stops are located.
716 Vertical Tab (VT) 11 Moves the printer to the
717 next vertical tab stop. It
718 remains unspecified how
719 either party determines or
720 establishes where such tab
721 stops are located.
722 Form Feed (FF) 12 Moves the printer to the top
723 of the next page, keeping
724 the same horizontal position.
725
726 All remaining codes do not cause the NVT printer to take any
727 action.
728
729 The sequence "CR LF", as defined, will cause the NVT to be
730 positioned at the left margin of the next print line (as would,
731 for example, the sequence "LF CR"). However, many systems and
732 terminals do not treat CR and LF independently, and will have to
733 go to some effort to simulate their effect. (For example, some
734 terminals do not have a CR independent of the LF, but on such
735 terminals it may be possible to simulate a CR by backspacing.)
736 Therefore, the sequence "CR LF" must be treated as a single "new
737 line" character and used whenever their combined action is
738 intended; the sequence "CR NUL" must be used where a carriage
739 return alone is actually desired; and the CR character must be
740 avoided in other contexts. This rule gives assurance to systems
741 which must decide whether to perform a "new line" function or a
742 multiple-backspace that the TELNET stream contains a character
743 following a CR that will allow a rational decision.
744
745 Note that "CR LF" or "CR NUL" is required in both directions
746
747
748<span class="grey">Postel &amp; Reynolds [Page 11]</span>
749</pre><!--NewPage--><pre class="newpage"><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
750<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
751
752
753 (in the default ASCII mode), to preserve the symmetry of the
754 NVT model. Even though it may be known in some situations
755 (e.g., with remote echo and suppress go ahead options in
756 effect) that characters are not being sent to an actual
757 printer, nonetheless, for the sake of consistency, the protocol
758 requires that a NUL be inserted following a CR not followed by
759 a LF in the data stream. The converse of this is that a NUL
760 received in the data stream after a CR (in the absence of
761 options negotiations which explicitly specify otherwise) should
762 be stripped out prior to applying the NVT to local character
763 set mapping.
764
765 The NVT keyboard has keys, or key combinations, or key sequences,
766 for generating all 128 USASCII codes. Note that although many
767 have no effect on the NVT printer, the NVT keyboard is capable of
768 generating them.
769
770 In addition to these codes, the NVT keyboard shall be capable of
771 generating the following additional codes which, except as noted,
772 have defined, but not reguired, meanings. The actual code
773 assignments for these "characters" are in the TELNET Command
774 section, because they are viewed as being, in some sense, generic
775 and should be available even when the data stream is interpreted
776 as being some other character set.
777
778 Synch
779
780 This key allows the user to clear his data path to the other
781 party. The activation of this key causes a DM (see command
782 section) to be sent in the data stream and a TCP Urgent
783 notification is associated with it. The pair DM-Urgent is to
784 have required meaning as defined previously.
785
786 Break (BRK)
787
788 This code is provided because it is a signal outside the
789 USASCII set which is currently given local meaning within many
790 systems. It is intended to indicate that the Break Key or the
791 Attention Key was hit. Note, however, that this is intended to
792 provide a 129th code for systems which require it, not as a
793 synonym for the IP standard representation.
794
795 Interrupt Process (IP)
796
797 Suspend, interrupt, abort or terminate the process to which the
798 NVT is connected. Also, part of the out-of-band signal for
799 other protocols which use TELNET.
800
801
802
803<span class="grey">Postel &amp; Reynolds [Page 12]</span>
804</pre><!--NewPage--><pre class="newpage"><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
805<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
806
807
808 Abort Output (AO)
809
810 Allow the current process to (appear to) run to completion, but
811 do not send its output to the user. Also, send a Synch to the
812 user.
813
814 Are You There (AYT)
815
816 Send back to the NVT some visible (i.e., printable) evidence
817 that the AYT was received.
818
819 Erase Character (EC)
820
821 The recipient should delete the last preceding undeleted
822 character or "print position" from the data stream.
823
824 Erase Line (EL)
825
826 The recipient should delete characters from the data stream
827 back to, but not including, the last "CR LF" sequence sent over
828 the TELNET connection.
829
830 The spirit of these "extra" keys, and also the printer format
831 effectors, is that they should represent a natural extension of
832 the mapping that already must be done from "NVT" into "local".
833 Just as the NVT data byte 68 (104 octal) should be mapped into
834 whatever the local code for "uppercase D" is, so the EC character
835 should be mapped into whatever the local "Erase Character"
836 function is. Further, just as the mapping for 124 (174 octal) is
837 somewhat arbitrary in an environment that has no "vertical bar"
838 character, the EL character may have a somewhat arbitrary mapping
839 (or none at all) if there is no local "Erase Line" facility.
840 Similarly for format effectors: if the terminal actually does
841 have a "Vertical Tab", then the mapping for VT is obvious, and
842 only when the terminal does not have a vertical tab should the
843 effect of VT be unpredictable.
844
845TELNET COMMAND STRUCTURE
846
847 All TELNET commands consist of at least a two byte sequence: the
848 "Interpret as Command" (IAC) escape character followed by the code
849 for the command. The commands dealing with option negotiation are
850 three byte sequences, the third byte being the code for the option
851 referenced. This format was chosen so that as more comprehensive use
852 of the "data space" is made -- by negotiations from the basic NVT, of
853 course -- collisions of data bytes with reserved command values will
854 be minimized, all such collisions requiring the inconvenience, and
855
856
857
858<span class="grey">Postel &amp; Reynolds [Page 13]</span>
859</pre><!--NewPage--><pre class="newpage"><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
860<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
861
862
863 inefficiency, of "escaping" the data bytes into the stream. With the
864 current set-up, only the IAC need be doubled to be sent as data, and
865 the other 255 codes may be passed transparently.
866
867 The following are the defined TELNET commands. Note that these codes
868 and code sequences have the indicated meaning only when immediately
869 preceded by an IAC.
870
871 NAME CODE MEANING
872
873 SE 240 End of subnegotiation parameters.
874 NOP 241 No operation.
875 Data Mark 242 The data stream portion of a Synch.
876 This should always be accompanied
877 by a TCP Urgent notification.
878 Break 243 NVT character BRK.
879 Interrupt Process 244 The function IP.
880 Abort output 245 The function AO.
881 Are You There 246 The function AYT.
882 Erase character 247 The function EC.
883 Erase Line 248 The function EL.
884 Go ahead 249 The GA signal.
885 SB 250 Indicates that what follows is
886 subnegotiation of the indicated
887 option.
888 WILL (option code) 251 Indicates the desire to begin
889 performing, or confirmation that
890 you are now performing, the
891 indicated option.
892 WON'T (option code) 252 Indicates the refusal to perform,
893 or continue performing, the
894 indicated option.
895 DO (option code) 253 Indicates the request that the
896 other party perform, or
897 confirmation that you are expecting
898 the other party to perform, the
899 indicated option.
900 DON'T (option code) 254 Indicates the demand that the
901 other party stop performing,
902 or confirmation that you are no
903 longer expecting the other party
904 to perform, the indicated option.
905 IAC 255 Data Byte 255.
906
907
908
909
910
911
912
913<span class="grey">Postel &amp; Reynolds [Page 14]</span>
914</pre><!--NewPage--><pre class="newpage"><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
915<span class="grey"><a href="http://tools.ietf.org/html/rfc854">RFC 854</a> May 1983</span>
916
917
918CONNECTION ESTABLISHMENT
919
920 The TELNET TCP connection is established between the user's port U
921 and the server's port L. The server listens on its well known port L
922 for such connections. Since a TCP connection is full duplex and
923 identified by the pair of ports, the server can engage in many
924 simultaneous connections involving its port L and different user
925 ports U.
926
927 Port Assignment
928
929 When used for remote user access to service hosts (i.e., remote
930 terminal access) this protocol is assigned server port 23
931 (27 octal). That is L=23.
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968Postel &amp; Reynolds [Page 15]
969
970</pre><br>
971<span class="noprint"><small><small>Html markup produced by rfcmarkup 1.101, available from
972<a href="http://tools.ietf.org/tools/rfcmarkup/">http://tools.ietf.org/tools/rfcmarkup/</a>
973</small></small></span>
974
975</body></html>
Note: See TracBrowser for help on using the repository browser.