rfc2066.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 2066                 TELNET CHARSET Option              January 1997


   IAC SB CHARSET TTABLE-NAK IAC SE
      The sender reports the unsuccessful receipt of the translate table
      and requests that it be resent.  If subsequent transmission
      attempts also fail, a TTABLE-REJECTED or CHARSET REJECTED message
      (depending on which side sends it) should be sent instead of
      additional futile TTABLE-IS and TTABLE-NAK messages.

   IAC SB CHARSET TTABLE-REJECTED IAC SE
      In response to a TTABLE-IS message, the receiver of the TTABLE-IS
      message acknowledges its receipt and indicates it is unable to
      handle it.  This message terminates the current CHARSET
      subnegotiation.

      Any system which supports the CHARSET option MUST fully support
      the CHARSET REQUEST, ACCEPTED, REJECTED, and TTABLE-REJECTED
      subnegotiation messages.  It MAY optionally fully support the
      TTABLE-IS, TTABLE-ACK, and TTABLE-NAK messages.  If it does fully
      support the TTABLE-IS message, it MUST also fully support the
      TTABLE-ACK and TTABLE-NAK messages.

3.   Default

   WON'T CHARSET

   DON'T CHARSET

4.   Motivation for the Option

   Many TELNET sessions need to transmit data which is not in 7-bit
   ASCII.  This is usually done by negotiating BINARY, and using local
   conventions (or terminal type kluges) to determine the character set
   of the data.  However, such methods tend not to interoperate well,
   and have difficulties when multiple character sets need to be
   supported by different sessions.

   Many computer systems now utilize a variety of character sets.
   Increasingly, a server computer needs to document character sets or
   translate transmissions and receptions using different pairs of
   character sets on a per-application or per-connection basis.  This is
   becoming more common as client and server computers become more
   geographically disperse.  (And as servers are consolidated into
   ever-larger hubs, serving ever-wider areas.)  In order for files,
   databases, etc. to contain correct data, the server must determine
   the character set in which the user is sending, and the character set
   in which the application expects to receive.






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


   In some cases, it is sufficient to determine the character set of the
   end user (because every application on the server expects to use the
   same character set, or because applications can handle the user's
   character set), but in other cases different server applications
   expect to use different character sets.  In the former case, an
   initial CHARSET subnegotiation suffices.  In the latter case, the
   server may need to initiate additional CHARSET subnegotiations as the
   user switches between applications.

   At a minimum, the option described in this memo allows both sides to
   be clear as to which character set is being used.  A minimal
   implementation would have the server send DO CHARSET, and the client
   send WILL CHARSET and CHARSET REQUEST.  The server could then
   communicate the client's character set to applications using whatever
   means are appropriate.  Such a server might refuse subsequent CHARSET
   REQUEST messages from the client (if it lacked the ability to
   communicate changed character set information to applications, for
   example).  Another system might have a method whereby various
   applications could communicate to the TELNET server their character
   set needs and abilities, which the server would handle by initiating
   new CHARSET REQUEST negotiations as appropriate.

   In some cases, servers may have a large set of clients which tend to
   connect often (such as daily) and over a long period of time (such as
   years).  The server administrators may strongly prefer that the
   servers not do character set translation (to save CPU cycles when
   serving very large numbers of users).  To avoid manually configuring
   each copy of the user TELNET software, the administrators might
   prefer that the software supports translate tables.  (If the client
   software received a translate table from the server and stored it,
   the table would only need to be sent once.)

5.   Description of the Option

   When the client TELNET program is able to determine the user's
   character set it should offer to specify the character set by sending
   IAC WILL CHARSET.

   If the server system is able to make use of this information, it
   replies with IAC DO CHARSET.  The client TELNET is then free to
   request a character set in a subnegotiation at any time.

   Likewise, when the server is able to determine the expected character
   set(s) of the user's application(s), it should send  IAC DO CHARSET
   to request that the client system specify the character set it is
   using.  Or the server could send IAC WILL CHARSET to offer to specify
   the character sets.




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


   Once a character set has been determined, the server can either
   perform the translation between the user and application character
   sets itself, or request by additional CHARSET subnegotiations that
   the client system do so.

   Once it has been established that both sides are capable of character
   set negotiation (that is, each side has received either a WILL
   CHARSET or a DO CHARSET message, and has also sent either a DO
   CHARSET or a WILL CHARSET message), subnegotiations can be requested
   at any time by whichever side has sent a WILL CHARSET message and
   also received a DO CHARSET message (this may be either or both
   sides).  Once a CHARSET subnegotiation has started, it must be
   completed before additional CHARSET subnegotiations can be started
   (there must never be more than one CHARSET subnegotiation active at
   any given time).  When a subnegotiation has completed, additional
   subnegotiations can be started at any time.

   If either side violates this rule and attempts to start a CHARSET
   subnegotiation while one is already active, the other side MUST
   reject the new subnegotiation by sending a CHARSET REJECTED message.

   Receipt of a CHARSET REJECTED or TTABLE-REJECTED message terminates
   the subnegotiation, leaving the character set unchanged.  Receipt of
   a CHARSET ACCEPTED or TTABLE-ACK message terminates the
   subnegotiation, with the new character set in force.

   In some cases, both the server and the client systems are able to
   perform translations and to send and receive in the character set(s)
   expected by the other side.  In such cases, either side can request
   that the other use the character set it prefers.  When both sides
   simultaneously make such a request (send CHARSET REQUEST messages),
   the server MUST reject the client's request by sending a CHARSET
   REJECTED message.  The client system MUST respond to the server's
   request.  (See the CHARSET REQUEST description, above.)

   When the client system makes the request first, and the server is
   able to handle the requested character set(s), but prefers that the
   client system instead use the server's (user application) character
   set, it may reject the request, and issue a CHARSET REQUEST of its
   own.  If the client system is unable to comply with the server's
   preference and issues a CHARSET REJECTED message, the server can
   issue a new CHARSET REQUEST message for one of the previous character
   sets (one of those which the client system originally requested).
   The client system would obviously accept this character set.

   While a CHARSET subnegotiation is in progress, data SHOULD be queued.
   Once the CHARSET subnegotiation has terminated, the data can be sent
   (in the correct character set).



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


   Note that regardless of CHARSET negotiation, translation only applies
   to text (not commands), and only occurs when in BINARY mode [4].  If
   not in BINARY mode, all data is assumed to be in NVT ASCII [1].

   Also note that the CHARSET option should be used with the END OF
   RECORD option [5] for block-mode terminals in order to be clear on
   what character represents the end of each record.

   As an example of character set negotiation, consider a user on a
   workstation using TELNET to communicate with a server.  In this
   example, the workstation normally uses the Cyrillic (ASCII) character
   set [2] but is capable of using EBCDIC-Cyrillic [2], and the server
   normally uses EBCDIC-Cyrillic.  The server could handle the (ASCII)
   Cyrillic character set, but prefers that instead the client system
   uses the EBCDIC-Cyrillic character set.  (This and the following
   examples do not show the full syntax of the subnegotiation messages.)


                 CLIENT                        SERVER

             WILL CHARSET                   WILL CHARSET

             DO CHARSET                     DO CHARSET

             CHARSET REQUEST Cyrillic
                 EBCDIC-Cyrillic

                                            CHARSET ACCEPTED EBCDIC-
                                               Cyrillic






















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


   Now consider a case where the workstation can't handle EBCDIC-
   Cyrillic, but can accept a translate table:

                 CLIENT                        SERVER

              WILL CHARSET                   WILL CHARSET

              DO CHARSET                     DO CHARSET

              CHARSET REQUEST [TTABLE] 1
                 Cyrillic

                                             CHARSET TTABLE-IS 1 Cyrillic
                                               EBCDIC-Cyrillic

              CHARSET TTABLE-ACK


   For another example, consider a case similar to the previous case,
   but now the user switches server applications in the middle of the
   session (denoted by ellipses), and the new application requires a
   different character set:

                CLIENT                        SERVER

              WILL CHARSET                   WILL CHARSET

              DO CHARSET                     DO CHARSET

              CHARSET REQUEST [TTABLE] 1
                 Cyrillic EBCDIC-INT

                                             CHARSET TTABLE-IS 1 Cyrillic
                                               EBCDIC-Cyrillic

              CHARSET TTABLE-ACK

              . . .                          . . .


                                             CHARSET REQUEST EBCDIC-INT

              CHARSET ACCEPTED EBCDIC-INT








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


6.   Security Considerations

   Security issues are not discussed in this memo.

7.   References

   [1] Postel, J. and J. Reynolds, "Telnet Protocol
       Specification", STD 8, RFC 854, ISI, May 1983.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers",
       STD 2, RFC 1700, ISI, October 1994.

   [3] Postel, J. and J. Reynolds, "Telnet Option
       Specifications", STD 8, RFC 855, ISI, May 1983.

   [4] Postel, J. and J. Reynolds, "Telnet Binary
       Transmission", STD 27, RFC 856, ISI, May 1983.

   [5] Postel, J., "Telnet End-Of-Record Option", RFC 885,
       ISI, December 1983.

   [6] Postel, J., "Internet Official Protocol Standards",
       STD 1, RFC 1920, IAB, March 1996.

8.   Author's Address

   Randall Gellens
   Unisys Corporation
   25725 Jeronimo Road
   Mail Stop 237
   Mission Viejo, CA  92691
   USA

   Phone:  [phone]
   Fax:    [phone]
   EMail:  [e-mail]















Gellens                       Experimental                     [Page 12]