RFC2066 日本語訳

2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: TXT=26088 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

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

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

                         TELNET CHARSET Option

TELNET CHARSET Option

Status of this Memo

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.

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

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.

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.

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

1.   Command Names and Codes

1. Command Names and Codes

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

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

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

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]):

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.

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

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

      NAME          CODE  MEANING

NAME CODE MEANING

      SE            240   End of subnegotiation parameters.

SE 240 End of subnegotiation parameters.

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

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.

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.

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.

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.

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.

IAC 255 Data Byte 255.

2.   Command Meanings

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.

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 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.

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

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 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 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

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

      Char set list:

Char set list:

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

<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).

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.

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.

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.

<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).

<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.

<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

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.

<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].

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:

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 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 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 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).

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.

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.

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

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.

<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.

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 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.

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.

<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:

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> <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.

<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

<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

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>.

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 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.

<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.

<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.]

[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.

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]

RFC 2066                 TELNET CHARSET Option              January 1997

Gellens Experimental [Page 6] 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-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.

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.

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

3. Default

   WON'T CHARSET

WON'T CHARSET

   DON'T CHARSET

DON'T CHARSET

4.   Motivation for the Option

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 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.

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

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.

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.

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.)

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

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.

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.

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.

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

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 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.

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.

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.

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.)

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.

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).

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

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].

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.

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.)

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

CLIENT SERVER

             WILL CHARSET                   WILL CHARSET

WILL CHARSET WILL CHARSET

             DO CHARSET                     DO CHARSET

DO CHARSET DO CHARSET

             CHARSET REQUEST Cyrillic
                 EBCDIC-Cyrillic

CHARSET REQUEST Cyrillic EBCDIC-Cyrillic

                                            CHARSET ACCEPTED EBCDIC-
                                               Cyrillic

CHARSET ACCEPTED EBCDIC- Cyrillic

Gellens                       Experimental                     [Page 10]

RFC 2066                 TELNET CHARSET Option              January 1997

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:

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

                 CLIENT                        SERVER

CLIENT SERVER

              WILL CHARSET                   WILL CHARSET

WILL CHARSET WILL CHARSET

              DO CHARSET                     DO CHARSET

DO CHARSET DO CHARSET

              CHARSET REQUEST [TTABLE] 1
                 Cyrillic

CHARSET REQUEST [TTABLE] 1 Cyrillic

                                             CHARSET TTABLE-IS 1 Cyrillic
                                               EBCDIC-Cyrillic

CHARSET TTABLE-IS 1 Cyrillic EBCDIC-Cyrillic

              CHARSET TTABLE-ACK

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:

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

CLIENT SERVER

              WILL CHARSET                   WILL CHARSET

WILL CHARSET WILL CHARSET

              DO CHARSET                     DO CHARSET

DO CHARSET DO CHARSET

              CHARSET REQUEST [TTABLE] 1
                 Cyrillic EBCDIC-INT

CHARSET REQUEST [TTABLE] 1 Cyrillic EBCDIC-INT

                                             CHARSET TTABLE-IS 1 Cyrillic
                                               EBCDIC-Cyrillic

CHARSET TTABLE存在、1つのキリル文字のEBCDIC-キリール文字

              CHARSET TTABLE-ACK

CHARSET TTABLE-ACK

              . . .                          . . .

. . . . . .

                                             CHARSET REQUEST EBCDIC-INT

CHARSETはEBCDIC-INTを要求します。

              CHARSET ACCEPTED EBCDIC-INT

CHARSETはEBCDIC-INTを受け入れました。

Gellens                       Experimental                     [Page 11]

RFC 2066                 TELNET CHARSET Option              January 1997

[11ページ]RFC2066telnet CHARSETオプション1997年1月に実験的なGellens

6.   Security Considerations

6. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

7.   References

7. 参照

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

[1] ポステル(J.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、ISI)は1983がそうするかもしれません。

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

[2] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、ISI、1994年10月。

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

[3] ポステル、J.、およびJ.レイノルズ(「telnetオプション仕様」、STD8、RFC855、ISI)は1983がそうするかもしれません。

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

[4] ポステル、J.、およびJ.レイノルズ(「telnetバイナリー送信」、STD27、RFC856、ISI)は1983がそうするかもしれません。

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

[5] ポステル、J.、「telnet記録の終わりのオプション」、RFC885、ISI、1983年12月。

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

[6] ポステル、J.、「インターネット公式プロトコル標準」、STD1、RFC1920、IAB、1996年3月。

8.   Author's Address

8. 作者のアドレス

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

ランドルGellensユニシス社25725のJeronimo道路メール停止237任務Viejo、カリフォルニア92691米国

   Phone:  +1.714.380.6350
   Fax:    +1.714.380.5912
   EMail:  Randy@MV.Unisys.Com

以下に電話をしてください。 +1.714 .380.6350Fax: +1.714 .380 .5912 メール: Randy@MV.Unisys.Com

Gellens                       Experimental                     [Page 12]

Gellens実験的です。[12ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

-moz-opacity 不透明度を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る