modes.  It is generally the server that determines the
              preferred mode, so the server needs to initiate the
              negotiation; since the negotiation is symmetric, the user
              can also initiate it.

         A client (User Telnet) SHOULD provide a means for users to
         enable and disable the initiation of option negotiation.

         DISCUSSION:
              A user sometimes needs to connect to an application
              service (e.g., FTP or SMTP) that uses Telnet for its




 



RFC1123                  REMOTE LOGIN -- TELNET             October 1989


              control stream but does not support Telnet options.  User
              Telnet may be used for this purpose if initiation of
              option negotiation is  disabled.

      3.3.5  Telnet Linemode Option

         DISCUSSION:
              An important new Telnet option, LINEMODE [TELNET:12], has
              been proposed.  The LINEMODE option provides a standard
              way for a User Telnet and a Server Telnet to agree that
              the client rather than the server will perform terminal
              character processing.  When the client has prepared a
              complete line of text, it will send it to the server in
              (usually) one TCP packet.  This option will greatly
              decrease the packet cost of Telnet sessions and will also
              give much better user response over congested or long-
              delay networks.

              The LINEMODE option allows dynamic switching between local
              and remote character processing.  For example, the Telnet
              connection will automatically negotiate into single-
              character mode while a full screen editor is running, and
              then return to linemode when the editor is finished.

              We expect that when this RFC is released, hosts should
              implement the client side of this option, and may
              implement the server side of this option.  To properly
              implement the server side, the server needs to be able to
              tell the local system not to do any input character
              processing, but to remember its current terminal state and
              notify the Server Telnet process whenever the state
              changes.  This will allow password echoing and full screen
              editors to be handled properly, for example.

   3.4  TELNET/USER INTERFACE

      3.4.1  Character Set Transparency

         User Telnet implementations SHOULD be able to send or receive
         any 7-bit ASCII character.  Where possible, any special
         character interpretations by the user host's operating system
         SHOULD be bypassed so that these characters can conveniently be
         sent and received on the connection.

         Some character value MUST be reserved as "escape to command
         mode"; conventionally, doubling this character allows it to be
         entered as data.  The specific character used SHOULD be user
         selectable.




 



RFC1123                  REMOTE LOGIN -- TELNET             October 1989


         On binary-mode connections, a User Telnet program MAY provide
         an escape mechanism for entering arbitrary 8-bit values, if the
         host operating system doesn't allow them to be entered directly
         from the keyboard.

         IMPLEMENTATION:
              The transparency issues are less pressing on servers, but
              implementors should take care in dealing with issues like:
              masking off parity bits (sent by an older, non-conforming
              client) before they reach programs that expect only NVT
              ASCII, and properly handling programs that request 8-bit
              data streams.

      3.4.2  Telnet Commands

         A User Telnet program MUST provide a user the capability of
         entering any of the Telnet control functions IP, AO, or AYT,
         and SHOULD provide the capability of entering EC, EL, and
         Break.