Telnet Options and Option Negotiation
(Page 1 of 4)
The basic Telnet Network Virtual Terminal (NVT) specification solves the problem of compatibility between different terminal and computer types by defining a common representation for data and commands that every Telnet client and server uses. The price for this universal representation, however, is very high: all of the advanced or special capabilities of terminals and hosts is stripped off. The result is a language that everyone can speak, but that is not capable of much more than basic conversation.
The creators of Telnet recognized that while it was important to define NVT as a common base to ensure cross-device compatibility, it was also essential that some means be provided by which clients and servers could agree to use more advanced means of communication. They defined a set of Telnet options, and a mechanism by which a Telnet client and server can negotiate which options they want to use.
Most Telnet options are used for the purpose of improving the efficiency of how data is transferred between devices. For example, by default the NVT assumes half-duplex operation with each device needing to use the Go Ahead command after each transmission. However, virtually all hardware now supports full-duplex communication, so devices will usually agree to use the Suppress Go Ahead option to eliminate the need to send this character. Similarly, it is possible for devices to negotiate the sending of 8-bit binary data instead of the standard 7-bit ASCII of the Telnet NVT.
The process of Telnet option negotiation is described in the main Telnet standard document, RFC 854, as well as a companion document, RFC 855 (Telnet Option Specifications). The options themselves are described in a separate set of Internet standards. Several of these were published at the same time as RFCs 854 and 855; others were defined earlier as part of previous versions of Telnet, and still others have been added over the years. There are now several dozen different Telnet options in existence; a master list is maintained by IANA (like all other TCP/IP parameters).
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.