The Q Method of Implementing TELNET Option Negotiation
RFC 1143

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                       D. Bernstein
Request for Comments: 1143                                           NYU
                                                           February 1990

         The Q Method of Implementing TELNET Option Negotiation

Status of This Memo

   This is RFC discusses an implementation approach to option
   negotiation in the Telnet protocol (RFC 854).  It does not propose
   any changes to the TELNET protocol.  Rather, it discusses the
   implementation of the protocol of one feature, only.  This is not a
   protocol specification.  This is an experimental method of
   implementing a protocol.  This memo is not a recommendation of the
   Telnet Working Group of the Internet Engineering Task Force (IETF).
   This RFC is Copyright 1990, Daniel J. Bernstein.  However,
   distribution of this memo in original form is unlimited.

1. Introduction

   This RFC amplifies, supplements, and extends the RFC 854 [7] option
   negotiation rules and guidelines, which are insufficient to prevent
   all option negotiation loops.  This RFC also presents an example of
   correct implementation.

   DISCUSSION:

   The two items in this RFC of the most interest to implementors are
   1. the examples of option negotiation loops given below; and 2. the
   example of a TELNET state machine preventing loops.

      1. Implementors of TELNET should read the examples of option
         negotiation loops and beware that preventing such loops is a
         nontrivial task.

      2. Section 7 of this RFC shows by example a working method
         of avoiding loops.  It prescribes the state information that
         you must keep about each side of each option; it shows what
         to do in each state when you receive WILL/WONT/DO/DONT from
         the network, and when the user or process requests that an
         option be enabled or disabled.  An implementor who uses the
         procedures given in that example need not worry about
         compliance with this RFC or with a large chunk of RFC 854.

   In short, all implementors should be familiar with TELNET loops, and
   some implementors may wish to use the pre-written example here in

Bernstein                                                       [Page 1]
RFC 1143                        Q Method                   February 1990

   writing a new TELNET implementation.

   NOTE: Reading This Document

      A TELNET implementation is not compliant with this RFC if it fails
      to satisfy all rules marked MUST.  It is compliant if it satisfies
      all rules marked MUST.  If it is compliant, it is unconditionally
      compliant if it also satisfies all rules marked SHOULD and
      conditionally compliant otherwise.  Rules marked MAY are optional.

      Options are in almost all cases negotiated separately for each
      side of the connection.  The option on one side is separate from
      the option on the other side. In this document, "the" option
      referred to by a DONT/WONT or DO/WILL is really two options,
      combined only for semantic convenience.  Each sentence could be
      split into two, one with the words before the slash and one with
      the words after the slash.

      An implementor should be able to determine whether or not an
      implementation complies with this RFC without reading any text
      marked DISCUSSION.  An implementor should be able to implement
      option negotiation machinery compliant with both this RFC and RFC
      854 using just the information in Section 7.

2. RFC 854 Option Negotiation Requirements

   As specified by RFC 854: A TELNET implementation MUST obey a refusal
   to enable an option; i.e., if it receives a DONT/WONT in response to
   a WILL/DO, it MUST NOT enable the option.

   DISCUSSION:

      Where RFC 854 implies that the other side may reject a request to
      enable an option, it means that you must accept such a rejection.

   It MUST therefore remember that it is negotiating a WILL/DO, and this
   negotiation state MUST be separate from the enabled state and from
   the disabled state.  During the negotiation state, any effects of
   having the option enabled MUST NOT be used.

   If it receives WONT/DONT and the option is enabled, it MUST respond
   DONT/WONT repectively and disable the option.  It MUST NOT initiate a
   DO/WILL negotiation for an already enabled option or a DONT/WONT
   negotiation for a disabled option.  It MUST NOT respond to receipt of
   such a negotiation.  It MUST respond to receipt of a negotiation that
   does propose to change the status quo.

Bernstein                                                       [Page 2]
RFC 1143                        Q Method                   February 1990

   DISCUSSION:

      Many existing implementations respond to rejection by confirming
      the rejection; i.e., if they send WILL and receive DONT, they send
      WONT.  This has been construed as acceptable behavior under a