rfc2066.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 676 行 · 第 1/2 页

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
   set list> and any character set desired by the receiver.

   <Version>  is an octet whose binary value is the highest version
   level of the TTABLE-IS message which can be sent in response.  This
   field must not be zero.  See the TTABLE-IS message for the permitted
   version values.

   <Char set list>  is a sequence of 7-BIT ASCII printable characters.
   The first octet defines the separator character (which must not
   appear within any character set).  It is terminated by the IAC SE
   sequence.  Case is not significant.  It consists of one or more
   character sets.  The character sets should appear in order of
   preference (most preferred first).

   <Sep>  is a separator octet, the value of which is chosen by the
   sender.  Examples include a space or a semicolon.  Any value other
   than IAC is allowed.  The obvious choice is a space or any other
   punctuation symbol which does not appear in any of the character set
   names.





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


   <Character set>  is a sequence of 7-BIT ASCII printable characters.
   Case is not significant.

   If a requested character set name does not start with "X-" or "x-",
   it MUST be registered with the Internet Assigned Number Authority
   (IANA) [2].

   The receiver responds in one of four ways:

   If the receiver is already sending text to and expecting text from
   the sender to be encoded in one of the specified character sets, it
   sends a positive acknowledgment (CHARSET ACCEPTED); it MUST NOT
   ignore the message.  (Although ignoring the message is perhaps
   suggested by some interpretations of the relevant RFCs ([1], [3]), in
   the interests of determinacy it is not permitted.  This ensures that
   the issuer does not need to time out and infer a response, while
   avoiding (because there is no response to a positive acknowledgment)
   the non-terminating subnegotiation which is the rationale in the RFCs
   for the non-response behavior.)

   If the receiver is capable of handling at least one of the specified
   character sets, it can respond with a positive acknowledgment for one
   of the requested character sets.  Normally, it should pick the first
   set it is capable of handling but may choose one based on its own
   preferences.  After doing so, each side MUST encode subsequent text
   in the specified character set.

   If the string [TTABLE] is present, and the receiver prefers to use a
   character set not included in <char set list>, and is capable of
   doing so, it can send a translate table (TTABLE-IS) response.

   If the receiver is not capable of handling any of the specified
   character sets, it sends a negative acknowledgment (CHARSET
   REJECTED).

   Because it is not valid to reply to a CHARSET REQUEST message with
   another CHARSET REQUEST message, if a CHARSET REQUEST message is
   received after sending one, it means that both sides have sent them
   simultaneously.  In this case, the server side MUST issue a negative
   acknowledgment.  The client side MUST respond to the one from the
   server.

   IAC SB CHARSET ACCEPTED <Charset> IAC SE
      This is a positive acknowledgment response to a CHARSET REQUEST
      message; the receiver of the CHARSET REQUEST message acknowledges
      its receipt and accepts the indicated character set.





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


      <Charset> is a character sequence identical to one of the
      character sets in the CHARSET REQUEST message.  It is terminated
      by the IAC SE sequence.

      Text messages which follow this response must now be coded in the
      indicated character set.  This message terminates the current
      CHARSET subnegotiation.

   IAC SB CHARSET REJECTED IAC SE
      This is a negative acknowledgment response to a CHARSET REQUEST
      message; the receiver of the CHARSET REQUEST message acknowledges
      its receipt but refuses to use any of the requested character
      sets.  Messages can not be sent in any of the indicated character
      sets.  This message can also be sent by the sender of a TTABLE-IS
      message, if multiple TTABLE-NAK messages were sent in response.
      This message terminates the current CHARSET subnegotiation.

   IAC SB CHARSET TTABLE-IS <version> <syntax for version> IAC SE
      In response to a CHARSET REQUEST message in which [TTABLE] was
      specified, the receiver of the CHARSET REQUEST message
      acknowledges its receipt and is transmitting a pair of tables
      which define the mapping between specified character sets.

      <Version> is an octet whose binary value is the version level of
      this TTABLE-IS message.  Different versions have different syntax.
      The lowest version level is one (zero is not valid).  The current
      highest version level is also one.  This field is provided so that
      future versions of the TTABLE-SEND message can be specified, for
      example, to handle character sets for which there is no simple
      one-to-one character-for-character translation.  This might
      include some forms of multi-octet character sets for which
      translation algorithms or subsets need to be sent.

   Syntax for Version 1:

      <sep> <char set name 1> <sep> < char size 1> < char count 1> <char
      set name 2> <sep> <char size 2> <char count 2> <map 1> <map 2>

      <Sep>  is a separator octet, the value of which is chosen by the
      sender.  Examples include a space or a semicolon.  Any value other
      than IAC is allowed.  The obvious choice is a space or any other
      punctuation symbol which does not appear in either of the
      character set names.

      <Char set name 1> and <Char set name 2>  are sequences of 7-BIT
      ASCII printable characters which identify the two character sets
      for which a mapping is being specified.  Each is terminated by
      <sep>.  Case is not significant.  If a character set name does not



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


      start with "X-" or "x-", it MUST be registered with IANA.  <Char
      set name 1> MUST be chosen from the <char set list> in the CHARSET
      REQUEST message.  <Char set name 2> can be arbitrarily chosen.
      Text on the wire MUST be encoded using <char set name 2>.

      <Char size 1>  and <char size 2>  are single octets each.  The
      binary value of the  octet is the number of bits nominally
      required for each character in the corresponding table.  It SHOULD
      be a multiple of eight.

      <Char count 1> and <char count 2>  are each three-octet binary
      fields in Network Byte Order [6].  Each specifies how many
      characters (of the maximum 2**<char size>) are being transmitted
      in the corresponding map.

      <Map1> and <Map 2>  each consist of the corresponding <char count>
      number of characters.  These characters form a mapping from all or
      part of the characters in one of the specified character sets to
      the correct characters in the other character set.  If the
      indicated <char count> is less than  2**<char size>, the first
      <char count> characters are being mapped, and the remaining
      characters are assumed to not be changed (and thus map to
      themselves).  That is, each map contains characters 0 through
      <char count> -1.  <Map 1> maps from <char set name 1> to <char set
      name 2>.  <Map 2> maps from <char set name 2> to <char set name
      1>.  Translation between the character sets is thus an obvious
      process of using the binary value of a character as an index into
      the appropriate map.  The character at that index replaces the
      original character.  If the index exceeds the <char count> for the
      map, no translation is performed for the character.

      [Note to implementers: since TELNET works in octets, it is
      possible for octets of value 255 to appear "spontaneously" when
      using multi-octet or non-8-bit characters.  All octets of value
      255 (other than IAC) MUST be quoted to conform with TELNET
      requirements.  This applies even to octets within a table, or text
      in a multi-octet character set.]

   IAC SB CHARSET TTABLE-ACK IAC SE
      The sender acknowledges the successful receipt of the translate
      table.  Text messages which follow this response must now be coded
      in the character set specified as <char set name 2> of the
      TTABLE-IS message.  This message terminates the current CHARSET
      subnegotiation.







Gellens                       Experimental                      [Page 6]