Telnet Protocol specification(2)

　　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.

  　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.