This non-response is essential to prevent endless loops in the
      negotiation.  It is required that a response be sent to requests
      for a change of mode -- even if the mode is not changed.

      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



 


RFC 854                                                         May 1983


      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 host may wish to
      buffer data, after requesting an 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 detailed 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" might include fields for minimum allowable, maximum
   allowable and desired line lengths.  The important concept is that





 


RFC 854                                                         May 1983


   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