TELNET CHARSET Option
RFC 2066

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

• Versions
• 03

Network Working Group                                         R. Gellens
Request for Comments: 2066                                        Unisys
Category: Experimental                                      January 1997

                         TELNET CHARSET Option

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document specifies a mechanism for passing character set and
   translation information between a TELNET client and server.  Use of
   this mechanism enables an application used by a TELNET user to send
   and receive data in the correct character set.

   Either side can (subject to option negotiation) at any time request
   that a (new) character set be used.

1.   Command Names and Codes

   CHARSET.......................42

      REQUEST ....................01
      ACCEPTED ...................02
      REJECTED ...................03
      TTABLE-IS ..................04
      TTABLE-REJECTED ............05
      TTABLE-ACK .................06
      TTABLE-NAK .................07

   As a convenience, standard TELNET text and codes for commands used in
   this document are reproduced here (excerpted from [1]):

      All TELNET commands consist of at least a two byte sequence:  the
      "Interpret as Command" (IAC) escape character followed by the code
      for the command.  The commands dealing with option negotiation are
      three byte sequences, the third byte being the code for the option
      referenced. ... [O]nly the IAC need be doubled to be sent as data,
      and the other 255 codes may be passed transparently.  The
      following are [some of] the defined TELNET commands.  Note that
      these codes and code sequences have the indicated meaning only
      when immediately preceded by an IAC.

Gellens                       Experimental                      [Page 1]
RFC 2066                 TELNET CHARSET Option              January 1997

      NAME          CODE  MEANING

      SE            240   End of subnegotiation parameters.

      SB            250   Indicates that what follows is
                          subnegotiation of the indicated
                          option.

      WILL          251   Indicates the desire to begin
                          performing, or confirmation that
                          you are now performing, the
                          indicated option.

      WON'T         252   Indicates the refusal to perform,
                          or continue performing, the
                          indicated option.

      DO            253   Indicates the request that the
                          other party perform, or
                          confirmation that you are expecting
                          the other party to perform, the
                          indicated option.

      DON'T         254   Indicates the demand that the other
                          party stop performing, or
                          confirmation that you are no longer
                          expecting the other party to
                          perform, the indicated option.

      IAC          255    Data Byte 255.

2.   Command Meanings

   A very simple meta-syntax is used, where most tokens represent
   previously defined items (such as IAC); angle-brackets ("<>") are
   used for items to be further defined; curly-braces ("{}") are used
   around optional items; ellipses represent repeated sequences of
   items; and quotes are used for literal strings.

   IAC WILL CHARSET
     The sender REQUESTS permission to, or AGREES to, use
     CHARSET option subnegotiation to choose a character set.

   IAC WON'T CHARSET
      The sender REFUSES to use CHARSET option subnegotiation
      to choose a character set.

Gellens                       Experimental                      [Page 2]
RFC 2066                 TELNET CHARSET Option              January 1997

    IAC DO CHARSET
      The sender REQUESTS that, or AGREES to have, the other
      side use CHARSET option subnegotiation to choose a
      character set.

   IAC DON'T CHARSET
      The sender DEMANDS that the other side not use the
      CHARSET option subnegotiation.

   IAC SB CHARSET REQUEST { "[TTABLE ]" <Version> } <char set
   list> IAC SE

      Char set list:

      <sep> <character set> { ... <sep> <character set> }

   This message initiates a new CHARSET subnegotiation.  It can only be
   sent by a side that has received a DO CHARSET message and sent a WILL
   CHARSET message (in either order).

   The sender requests that all text sent to and by it be encoded in one
   of the specified character sets.

   If the string [TTABLE] appears, the sender is willing to accept a
   mapping (translation table) between any character set listed in <char