diff options
Diffstat (limited to 'doc/rfc/rfc764.txt')
| -rw-r--r-- | doc/rfc/rfc764.txt | 869 |
1 files changed, 869 insertions, 0 deletions
diff --git a/doc/rfc/rfc764.txt b/doc/rfc/rfc764.txt new file mode 100644 index 0000000..80f7f2a --- /dev/null +++ b/doc/rfc/rfc764.txt @@ -0,0 +1,869 @@ + +IEN 148 J. Postel +RFC 764 ISI + June 1980 + + TELNET PROTOCOL SPECIFICATION + + +INTRODUCTION + + The purpose of the TELNET Protocol is to provide a fairly general, + bi-directional, eight-bit byte oriented communications facility. Its + primary goal is to allow a standard method of interfacing terminal + devices and terminal-oriented processes to each other. It is + envisioned that the protocol may also be used for terminal-terminal + communication ("linking") and process-process communication + (distributed computation). + +GENERAL CONSIDERATIONS + + A TELNET connection is a Transmission Control Protocol (TCP) + connection used to transmit data with interspersed TELNET control + information. TCP and the connection establishment procedure are + documentented in the ARPA Internet Protocol Handbook. + + The TELNET Protocol is built upon three main ideas: first, the + concept of a "Network Virtual Terminal"; second, the principle of + negotiated options; and third, a symmetric view of terminals and + processes. + + 1. When a TELNET connection is first established, each end is + assumed to originate and terminate at a "Network Virtual Terminal", + or NVT. An NVT is an imaginary device which provides a standard, + network-wide, intermediate representation of a canonical terminal. + This eliminates the need for "server" and "user" Hosts* to keep + information about the characteristics of each other's terminals and + terminal handling conventions. All Hosts, both user and server, map + their local device characteristics and conventions so as to appear to + be dealing with an NVT over the network, and each can assume a + similar mapping by the other party. The NVT is intended to strike a + balance between being overly restricted (not providing Hosts a rich + enough vocabulary for mapping into their local character sets), and + being overly inclusive (penalizing users with modest terminals). + + *NOTE: The "user" Host is the Host to which the physical terminal + is normally attached, and the "server" host is the Host which is + normally providing some service. As an alternate point of view, + applicable even in terminal-to-terminal or process-to-process + communications, the "user" Host is the Host which initiated the + communication. + + + + + + +Postel [Page 1] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + 2. The principle of negotiated options takes cognizance of the fact + that many sites will wish to provide additional services over and + above those available within an NVT, and many users will have + sophisticated terminals and would like to have elegant, rather than + minimal, services. Independent of, but structured within, the TELNET + Protocol various "options" will be sanctioned which can be used with + the "DO, DON'T, WILL, WON'T" structure (discussed below) to allow a + user and server to agree to use a more elaborate (or perhaps just + different) set of conventions for their TELNET connection. Such + options could include changing the character set, the echo mode, the + line width, the page length, etc. + + The basic strategy for setting up the use of options is to have + either party (or both) initiate a request that some option take + effect. The other party may then either accept or reject the + request. If the request is accepted the option immediately takes + effect; if it is rejected the associated aspect of the connection + remains as specified for an NVT. Clearly, a party may always refuse + a request to enable, and must never refuse a request to disable, some + option since all parties must be prepared to support the NVT. + + The syntax of option negotiation has been set up so that if both + parties request an option simultaneously, each will see the other's + request as the positive acknowledgment of its own. + + 3. The symmetry of the negotiation syntax can potentially lead to + nonterminating acknowledgment loops -- each party seeing the incoming + commands not as acknowledgments but as new requests which must be + acknowledged. To prevent such loops, the following rules prevail: + + a. Parties may only request a change in option status; i.e., a + party may not send out a "request" merely to announce what + mode it is in. + + b. If a party receives what appears to be a request to enter some + mode it is already in, the request should not be acknowledged. + + c. Whenever one party sends an option command to a second party, + whether as a request or an acknowledgment, and use of the + option will have any effect on the processing of the data + being sent from the first party to the second, then the + command must be inserted in the data stream at the point where + it is desired that it take effect. (It should be noted that + some time will elapse between the transmission of a request + and the receipt of an acknowledgment, which may be negative. + Thus, a site may wish to buffer data, after requesting an + + + + +[Page 2] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + option, until it learns whether the request is accepted or + rejected, in order to hide the "uncertainty period" from the + user.) + + Option requests are likely to flurry back and forth when a TELNET + connection is first established, as each party attempts to get the + best possible service from the other party. Beyond that, however, + options can be used to dynamically modify the characteristics of the + connection to suit changing local conditions. For example, the NVT, + as will be explained later, uses a transmission discipline well + suited to the many "line at a time" applications such as BASIC, but + poorly suited to the many "character at a time" applications such as + NLS. A server might elect to devote the extra processor overhead + required for a "character at a time" discipline when it was suitable + for the local process and would negotiate an appropriate option. + However, rather than then being permanently burdened with the extra + processing overhead, it could switch (i.e., negotiate) back to NVT + when the more "taut" control was no longer necessary. + + It is possible for requests initiated by processes to stimulate a + nonterminating request loop if the process responds to a rejection by + merely re-requesting the option. To prevent such loops from + occurring, rejected requests should not be repeated until something + changes. Operationally, this can mean the process is running a + different program, or the user has given another command, or whatever + makes sense in the context of the given process and the given option. + A good rule of thumb is that a re-request should only occur as a + result of subsequent information from the other end of the connection + or when demanded by local human intervention. + + Option designers should not feel constrained by the somewhat limited + syntax available for option negotiation. The intent of the simple + syntax is to make it easy to have options--since it is + correspondingly easy to profess ignorance about them. If some + particular option requires a richer negotiation structure than + possible within "DO, DON'T, WILL, WON'T", the proper tack is to use + "DO, DON'T, WILL, WON'T" to establish that both parties understand + the option, and once this is accomplished a more exotic syntax can be + used freely. For example, a party might send a request to alter + (establish) line length. If it is accepted, then a different syntax + can be used for actually negotiating the line length--such a + "sub-negotiation" perhaps including fields for minimum allowable, + maximum allowable and desired line lengths. The important concept is + that such expanded negotiations should never begin until some prior + (standard) negotiation has established that both parties are capable + of parsing the expanded syntax. + + + + +Postel [Page 3] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + In summary, WILL XXX is sent, by either party, to indicate that + party's desire (offer) to begin performing option XXX, DO XXX and + DON'T XXX being its positive and negative acknowledgments; similarly, + DO XXX is sent to indicate a desire (request) that the other party + (i.e., the recipient of the DO) begin performing option XXX, WILL XXX + and WON'T XXX being the positive and negative acknowledgments. Since + the NVT is what is left when no options are enabled, the DON'T and + WON'T responses are guaranteed to leave the connection in a state + which both ends can handle. Thus, all Hosts may implement their + TELNET processes to be totally unaware of options that are not + supported, simply returning a rejection to (i.e., refusing) any + option request that cannot be understood. + + As much as possible, the TELNET protocol has been made server-user + symmetrical so that it easily and naturally covers the user-user + (linking) and server-server (cooperating processes) cases. It is + hoped, but not absolutely required, that options will further this + intent. In any case, it is explicitly acknowledged that symmetry is + an operating principle rather than an ironclad rule. + + A companion document, "TELNET Option Specifications," should be + consulted for information about the procedure for establishing new + options. That document, as well as descriptions of all currently + defined options, is contained in the TELNET section of the ARPA + Internet Protocol Handbook. + +THE NETWORK VIRTUAL TERMINAL + + The Network Virtual Terminal (NVT) is a bi-directional character + device. The NVT has a printer and a keyboard. The printer responds + to incoming data and the keyboard produces outgoing data which is + sent over the TELNET connection and, if "echoes" are desired, to the + NVT's printer as well. "Echoes" will not be expected to traverse the + network (although options exist to enable a "remote" echoing mode of + operation, no Host is required to implement this option). The code + set is seven-bit USASCII in an eight-bit field, except as modified + herein. Any code conversion and timing considerations are local + problems and do not affect the NVT. + + TRANSMISSION OF DATA + + Although a TELNET connection through the network is intrinsically + full duplex, the NVT is to be viewed as a half-duplex device + operating in a line-buffered mode. That is, unless and until + + + + + + +[Page 4] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + options are negotiated to the contrary, the following default + conditions pertain to the transmission of data over the TELNET + connection: + + 1) Insofar as the availability of local buffer space permits, + data should be accumulated in the Host where it is generated + until a complete line of data is ready for transmission, or + until some locally-defined explicit signal to transmit occurs. + This signal could be generated either by a process or by a + human user. + + The motivation for this rule is the high cost, to some Hosts, + of processing network input interrupts, coupled with the + default NVT specification that "echoes" do not traverse the + network. Thus, it is reasonable to buffer some amount of data + at its source. Many systems take some processing action at the + end of each input line (even line printers or card punches + frequently tend to work this way), so the transmission should + be triggered at the end of a line. On the other hand, a user + or process may sometimes find it necessary or desirable to + provide data which does not terminate at the end of a line; + therefore implementers are cautioned to provide methods of + locally signaling that all buffered data should be transmitted + immediately. + + 2) When a process has completed sending data to an NVT printer + and has no queued input from the NVT keyboard for further + processing (i.e., when a process at one end of a TELNET + connection cannot proceed without input from the other end), + the process must transmit the TELNET Go Ahead (GA) command. + + This rule is not intended to require that the TELNET GA command + be sent from a terminal at the end of each line, since server + Hosts do not normally require a special signal (in addition to + end-of-line or other locally-defined characters) in order to + commence processing. Rather, the TELNET GA is designed to help + a user's local Host operate a physically half duplex terminal + which has a "lockable" keyboard such as the IBM 2741. A + description of this type of terminal may help to explain the + proper use of the GA command. + + The terminal-computer connection is always under control of + either the user or the computer. Neither can unilaterally + seize control from the other; rather the controlling end must + relinguish its control explicitly. At the terminal end, the + hardware is constructed so as to relinquish control each time + + + + +Postel [Page 5] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + that a "line" is terminated (i.e., when the "New Line" key is + typed by the user). When this occurs, the attached (local) + computer processes the input data, decides if output should be + generated, and if not returns control to the terminal. If + output should be generated, control is retained by the computer + until all output has been transmitted. + + The difficulties of using this type of terminal through the + network should be obvious. The "local" computer is no longer + able to decide whether to retain control after seeing an + end-of-line signal or not; this decision can only be made by + the "remote" computer which is processing the data. Therefore, + the TELNET GA command provides a mechanism whereby the "remote" + (server) computer can signal the "local" (user) computer that + it is time to pass control to the user of the terminal. It + should be transmitted at those times, and only at those times, + when the user should be given control of the terminal. Note + that premature transmission of the GA command may result in the + blocking of output, since the user is likely to assume that the + transmitting system has paused, and therefore he will fail to + turn the line around manually. + + The foregoing, of course, does not apply to the user-to-server + direction of communication. In this direction, GAs may be sent at + any time, but need not ever be sent. Also, if the TELNET + connection is being used for process-to-process communication, GAs + need not be sent in either direction. Finally, for + terminal-to-terminal communication, GAs may be required in + neither, one, or both directions. If a Host plans to support + terminal-to-terminal communication it is suggested that the Host + provide the user with a means of manually signaling that it is + time for a GA to be sent over the TELNET connection; this, + however, is not a requirement on the implementer of a TELNET + process. + + STANDARD REPRESENTATION OF CONTROL FUNCTIONS + + As stated in the Introduction to this document, the primary goal + of the TELNET protocol is the provision of a standard interfacing + of terminal devices and terminal-oriented processes through the + network. Early experiences with this type of interconnection have + shown that certain functions are implemented by most servers, but + that the methods of invoking these functions differ widely. For a + human user who interacts with several server systems, these + differences are highly frustrating. TELNET, therefore, defines a + standard representation for five of these functions, as described + + + + +[Page 6] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + below. These standard representations have standard, but not + required, meanings (with the exception that the IP function may be + required by other protocols which use TELNET); that is, a system + which does not provide the function to local users need not + provide it to network users and may treat the standard + representation for the function as a No-operation. On the other + hand, a system which does provide the function to local is obliged + to provide the same function as a network user who transmits the + standard representation for the function. + + Interrupt Process (IP) + + Many systems provide a function which suspends, interrupts, + aborts, or terminates the operation of a user process. This + function is frequently used when a user believes his process is + in an unending loop, or when an unwanted process has been + inadvertently activated. IP is the standard representation for + invoking this function. It should be noted by implementers + that IP may be required by other protocols which use TELNET, + and therefore should be implemented if these other protocols + are to be supported. + + Abort Output (AO) + + Many systems provide a function which allows a process, which + is generating output, to run to completion (or to reach the + same stopping point it would reach if running to completion) + but without sending the output to the user's terminal. + Further, this function typically clears any output already + produced but not yet actually printed (or displayed) on the + user's terminal. AO is the standard representation for + invoking this function. For example, some subsystem might + normally accept a user's command, send a long text string to + the user's terminal in response, and finally signal readiness + to accept the next command by sending a "prompt" character + (preceded by <CR><LF>) to the user's terminal. If the AO were + received during the transmission of the text string, a + reasonable implementation would be to suppress the remainder of + the text string, but transmit the prompt character and the + preceding <CR><LF>. (This is possibly in distinction to the + action which might be taken if an IP were received; the IP + might cause suppression of the text string and an exit from the + subsystem.) + + It should be noted, by systems which provide this function, + that there may be buffers external to the system (in the + + + + +Postel [Page 7] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + network and the user's "local" Host) which should be cleared; + the appropriate way to do this is to transmit the "Synch" + signal described below. + + Are You There (AYT) + + Many systems provide a function which provides the user with + some visible (e.g., printable) evidence that the system is + still up and running. This function may be invoked by the user + when the system is unexpectedly "silent" for a long time, + because of the unanticipated (by the user) length of a + computation, an unusually heavy system load, etc. AYT is the + standard representation for invoking this function. + + Erase Character (EC) + + Many systems provide a function which deletes the last + preceding undeleted character or "print position"* from the + stream of data being supplied by the user. This function is + typically used to edit keyboard input when typing mistakes are + made. EC is the standard representation for invoking this + function. + + *NOTE: A "print position" may contain several characters + which are the result of overstrikes, or of sequences such as + <char1> BS <char2>... + + Erase Line (EL) + + Many systems provide a function which deletes all the data in + the current "line" of input. This function is typically used + to edit keyboard input. EL is the standard representation for + invoking this function. + + THE TELNET "SYNCH" SIGNAL + + Most time-sharing systems provide mechanisms which allow a + terminal user to regain control of a "runaway" process; the IP and + AO functions described above are examples of these mechanisms. + Such systems, when used locally, have access to all of the signals + supplied by the user, whether these are normal characters or + special "out of band" signals such as those supplied by the + teletype "BREAK" key or the IBM 2741 "ATTN" key. This is not + necessarily true when terminals are connected to the system + + + + + + +[Page 8] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + through the network; the network's flow control mechanisms may + cause such a signal to be buffered elsewhere, for example in the + user's Host. + + To counter this problem, the TELNET "Synch" mechanism is + introduced. A Synch signal consists of a TCP Urgent notification, + coupled with the TELNET command DATA MARK. The Urgent + notification, which is not subject to the flow control pertaining + to the TELNET connection, is used to invoke special handling of + the data stream by the process which receives it. In this mode, + the data stream is immediately scanned for "interesting" signals + as defined below, discarding intervening data. The TELNET command + DATA MARK (DM) is the synchronizing mark in the data stream which + indicates that any special signal has already occurred and the + recipient can return to normal processing of the data stream. + + The Synch is sent via the TCP send operation with the Urgent + flag set and the DM as the last (or only) data octet. + + When several Synchs are sent in rapid succession, the Urgent + notifications may be merged. It is not possible to count Urgents + since the number received will be less than or equal the number + sent. When in normal mode a DM is a no operation, when in urgent + mode it signals the end of the urgent processing (this should + correspond with the end of Urgent pointer indicated by TCP). + + If TCP indicates the end of Urgent data before the DM is found, + TELNET should continue the special handling of the data stream + until the DM is found. + + "Interesting" signals are defined to be: the TELNET standard + representations of IP, AO, and AYT (but not EC or EL); the local + analogs of these standard representations (if any); all other + TELNET commands; other site-defined signals which can be acted on + without delaying the scan of the data stream. + + Since one effect of the SYNCH mechanism is the discarding of + essentially all characters (except TELNET commands) between the + sender of the Synch and its recipient, this mechanism is specified + as the standard way to clear the data path when that is desired. + For example, if a user at a terminal causes an AO to be + transmitted, the server which receives the AO (if it provides that + function at all) should return a Synch to the user. + + Finally, just as the TCP Urgent notification is needed at the + + + + + +Postel [Page 9] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + TELNET level as an out-of-band signal, so other protocols which + make use of TELNET may require a TELNET command which can be + viewed as an out-of-band signal at a different level. + + By convention the sequence [IP, Synch] is to be used as such a + signal. For example, suppose that some other protocol, which uses + TELNET, defines the character string STOP analogously to the + TELNET command AO. Imagine that a user of this protocol wishes a + server to process the STOP string, but the connection is blocked + because the server is processing other commands. The user should + instruct his system to: + + 1. Send the TELNET IP character; + + 2. Send the TELNET SYNC sequence, that is: + + Send the Data Mark (DM) as the only character + in a TCP urgent mode send operation. + + 3. Send the character string STOP; and + + 4. Send the other protocol's analog of the TELNET DM, if any. + + The user (or process acting on his behalf) must transmit the + TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP + gets through to the server's TELNET interpreter. + + The Urgent should wake up the TELNET process, the IP should + wake up the next higher level process. + + THE NVT PRINTER AND KEYBOARD + + The NVT printer has an unspecified carriage width and page length + and can produce representations of all 95 USASCII graphics (codes + 32 through 126). Of the 33 USASCII control codes (0 through 31 + and 127), and the 128 uncovered codes (128 through 255), the + following have specified meaning to the NVT printer: + + NAME CODE MEANING + + NULL (NUL) 0 A no operation + Line Feed (LF) 10 Moves the printer to the + next print line, keeping the + same horizontal position + Carriage Return (CR) 13 Moves the printer to the left + margin of the current line. + + + + +[Page 10] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + In addition, the following codes shall have defined, but not + required, effects on the NVT printer. Neither end of a TELNET + connection may assume that the other party will take, or will + have taken, any particular action upon receipt or transmission + of these: + + BELL (BEL) 7 Produces an audible or + visible signal (which does + NOT move the print head) + Back Space (BS) 8 Moves the print head one + character position towards + the left margin. + Horizontal Tab (HT) 9 Moves the printer to the + next horizontal tab stop. + It remains unspecified how + either party determines or + establishes where such tab + stops are located. + Vertical Tab (VT) 11 Moves the printer to the + next horizontal tab stop.It + remains unspecified how + either party determines or + establishes where such tab + stops are located. + Form Feed (FF) 12 Moves the printer to the top + of the next page, keeping + the same horizontal position + + All remaining codes do not cause the NVT printer to take any + action. + + The sequence "CR LF", as defined, will cause the NVT to be + positioned at the left margin of the next print line (as would, + for example, the sequence "LF CR"). However, many systems and + terminals do not treat CR and LF independently, and will have to + go to some effort to simulate their effect. (For example, some + terminals do not have a CR independent of the LF, but on such + terminals it may be possible to simulate a CR by backspacing.) + Therefore, the sequence "CR LF" must be treated as a single "new + line" character and used whenever their combined action is + intended; the sequence "CR NUL" must be used where a carriage + return alone is actually desired; and the CR character must be + avoided in other contexts. This rule gives assurance to systems + which must decide whether to perform a "new line" function or a + multiple-backspace that the TELNET stream contains a character + following a CR that will allow a rational decision. + + + + +Postel [Page 11] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + + Note that "CR LF" or "CR NUL" is required in both directions + (in the default ASCII mode), to preserve the symmetry of the + NVT model. Even though it may be known in some situations + (e.g., with remote echo and suppress go ahead options in + effect) that characters are not being sent to an actual + printer, none the less, for the sake of consistency, the + protocol requires that a NUL be inserted following a CR not + followed by a LF in the data stream. The converse of this is + that a NUL received in the data stream after a CR (in the + absence of options negotiations which explicitly specify + otherwise) should be stripped out prior to applying the NVT to + local character set mapping. + + The NVT keyboard has keys, or key combinations, or key sequences, + for generating all 128 USASCII codes. Note that although many + have no effect on the NVT printer, the NVT keyboard is capable of + generating them. + + In addition to these codes, the NVT keyboard shall be capable of + generating the following additional codes which, except as noted, + have defined, but not reguired, meanings. The actual code + assignments for these "characters" are in the TELNET Command + section, because they are viewed as being, in some sense, generic + and should be available even when the data stream is interpreted + as being some other character set. + + Synch + + This key allows the user to clear his data path to the other + party. The activation of this key causes a DM (see command + section) to be sent in the data stream and a TCP Urgent + notification is associated with it. The pair DM-Urgent is to + have required meaning as defined previously. + + Break (BRK) + + This code is provided because it is a signal outside the + USASCII set which is currently given local meaning within many + systems. It is intended to indicate that the Break Key or the + Attention Key was hit. Note, however, that this is intended to + provide a 129th code for systems which require it, not as a + synonym for the IP standard representation. + + + + + + + + +[Page 12] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + Interrupt Process (IP) + + Suspend, interrupt, abort or terminate the process to which the + NVT is connected. Also, part of the out-of-band signal for + other protocols which use TELNET. + + Abort Output (AO) + + Allow the current process to (appear to) run to completion, but + do not send its output to the user. Also, send a Synch to the + user. + + Are You There (AYT) + + Send back to the NVT some visible (i.e., printable) evidence + that the AYT was received. + + Erase Character (EC) + + The recipient should delete the last preceding undeleted + character or "print position" from the data stream. + + Erase Line (EL) + + The recipient should delete characters from the data stream + back to, but not including, the last "CR LF" sequence sent over + the TELNET connection. + + The spirit of these "extra" keys, and also the printer format + effectors, is that they should represent a natural extension of + the mapping that already must be done from "NVT" into "local". + Just as the NVT data byte 104 should be mapped into whatever the + local code for "uppercase D" is, so the EC character should be + mapped into whatever the local "Erase Character" function is. + Further, just as the mapping for 174 is somewhat arbitrary in an + environment that has no "vertical bar" character, the EL character + may have a somewhat arbitrary mapping (or none at all) if there is + no local "Erase Line" facility. Similarly for format effectors: + if the terminal actually does have a "Vertical tab", then the + mapping for VT is obvious, and only when the terminal does not + have a vertical tab should the effect of VT be unpredictable. + + + + + + + + + +Postel [Page 13] + + +June 1980 RFC 764, IEN 148 +Telnet Protocol Specification + + + +TELNET COMMAND STRUCTURE + + All TELNET commands consist of at least a two byte sequence: the + "Interpret as Command" (IAC) escape character followed by the code + for the command. The commands dealing with option negotiation are + three byte sequences, the third byte being the code for the option + referenced. This format was chosen so that as more comprehensive use + of the "data space" is made -- by negotiations from the basic NVT, of + course -- collisions of data bytes with reserved command values will + be minimized, all such collisions requiring the inconvenience, and + inefficiency, of "escaping" the data bytes into the stream. With the + current set-up, only the IAC need be doubled to be sent as data, and + the other 255 codes may be passed transparently. + + The following are the defined TELNET commands. Note that these codes + and code sequences have the indicated meaning only when immediately + preceded by an IAC. + + NAME CODE MEANING + + SE 240 End of subnegotiation parameters + NOP 241 No operation + Data Mark 242 The data stream portion of a Synch + This should always be accompanied + by a TCP Urgent notification. + Break 243 NVT character BRK + Interrupt Process 244 The function IP + Abort output 245 The function AO + Are You There 246 The function AYT + Erase character 247 The function EC + Erase Line 248 The function EL + Go ahead 249 The GA signal + SB 250 Indicates that what follows is + subnegotiation of the indicated + option + WILL (option code) 251 Indicates the desire to begin + performing, or confirmation that + you are now performing, the + indicated option + WON't (option code) 252 Indicates the refusal to perform, + or continue performing, the + indicated option. + DO (option code) 253 Indicates the request that the + other party perform, or + confirmation that you are expecting + the other party to perform, the + + + + +[Page 14] Postel + + +RFC 764, IEN 148 June 1980 + Telnet Protocol Specification + + + + indicated option. + DON'T (option code) 254 Indicates the demand that the + other party stop performing, + or confirmation that you are no + longer expecting the other party + to perform, the indicated option. + IAC 255 Data Byte 255. + +CONNECTION ESTABLISHMENT + + The TELNET TCP connection is established between the user's port U + and the server's port L. The server listens on its well known port L + for such connections. Since a TCP connection is full duplex and + identified by the pair of ports, the server can engage in many + simultaneous connections involving it's port L and different user + ports U. + + Port Assignment + + When used for remote user access to service hosts (i.e., remote + terminal access) this protocol is assigned server port 23 (27 + octal). That is L=23. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 15] |