RFC 764 (rfc764) - Page 2 of 15

Telnet Protocol specification

                                                                        
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