home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2066 < prev    next >
Text File  |  1996-12-31  |  26KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         R. Gellens
  8. Request for Comments: 2066                                        Unisys
  9. Category: Experimental                                      January 1997
  10.  
  11.  
  12.                          TELNET CHARSET Option
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This document specifies a mechanism for passing character set and
  24.    translation information between a TELNET client and server.  Use of
  25.    this mechanism enables an application used by a TELNET user to send
  26.    and receive data in the correct character set.
  27.  
  28.    Either side can (subject to option negotiation) at any time request
  29.    that a (new) character set be used.
  30.  
  31. 1.   Command Names and Codes
  32.  
  33.    CHARSET.......................42
  34.  
  35.       REQUEST ....................01
  36.       ACCEPTED ...................02
  37.       REJECTED ...................03
  38.       TTABLE-IS ..................04
  39.       TTABLE-REJECTED ............05
  40.       TTABLE-ACK .................06
  41.       TTABLE-NAK .................07
  42.  
  43.    As a convenience, standard TELNET text and codes for commands used in
  44.    this document are reproduced here (excerpted from [1]):
  45.  
  46.       All TELNET commands consist of at least a two byte sequence:  the
  47.       "Interpret as Command" (IAC) escape character followed by the code
  48.       for the command.  The commands dealing with option negotiation are
  49.       three byte sequences, the third byte being the code for the option
  50.       referenced. ... [O]nly the IAC need be doubled to be sent as data,
  51.       and the other 255 codes may be passed transparently.  The
  52.       following are [some of] the defined TELNET commands.  Note that
  53.       these codes and code sequences have the indicated meaning only
  54.       when immediately preceded by an IAC.
  55.  
  56.  
  57.  
  58. Gellens                       Experimental                      [Page 1]
  59.  
  60. RFC 2066                 TELNET CHARSET Option              January 1997
  61.  
  62.  
  63.       NAME          CODE  MEANING
  64.  
  65.       SE            240   End of subnegotiation parameters.
  66.  
  67.       SB            250   Indicates that what follows is
  68.                           subnegotiation of the indicated
  69.                           option.
  70.  
  71.       WILL          251   Indicates the desire to begin
  72.                           performing, or confirmation that
  73.                           you are now performing, the
  74.                           indicated option.
  75.  
  76.       WON'T         252   Indicates the refusal to perform,
  77.                           or continue performing, the
  78.                           indicated option.
  79.  
  80.       DO            253   Indicates the request that the
  81.                           other party perform, or
  82.                           confirmation that you are expecting
  83.                           the other party to perform, the
  84.                           indicated option.
  85.  
  86.       DON'T         254   Indicates the demand that the other
  87.                           party stop performing, or
  88.                           confirmation that you are no longer
  89.                           expecting the other party to
  90.                           perform, the indicated option.
  91.  
  92.       IAC          255    Data Byte 255.
  93.  
  94. 2.   Command Meanings
  95.  
  96.    A very simple meta-syntax is used, where most tokens represent
  97.    previously defined items (such as IAC); angle-brackets ("<>") are
  98.    used for items to be further defined; curly-braces ("{}") are used
  99.    around optional items; ellipses represent repeated sequences of
  100.    items; and quotes are used for literal strings.
  101.  
  102.    IAC WILL CHARSET
  103.      The sender REQUESTS permission to, or AGREES to, use
  104.      CHARSET option subnegotiation to choose a character set.
  105.  
  106.  
  107.    IAC WON'T CHARSET
  108.       The sender REFUSES to use CHARSET option subnegotiation
  109.       to choose a character set.
  110.  
  111.  
  112.  
  113.  
  114. Gellens                       Experimental                      [Page 2]
  115.  
  116. RFC 2066                 TELNET CHARSET Option              January 1997
  117.  
  118.  
  119.     IAC DO CHARSET
  120.       The sender REQUESTS that, or AGREES to have, the other
  121.       side use CHARSET option subnegotiation to choose a
  122.       character set.
  123.  
  124.  
  125.    IAC DON'T CHARSET
  126.       The sender DEMANDS that the other side not use the
  127.       CHARSET option subnegotiation.
  128.  
  129.  
  130.    IAC SB CHARSET REQUEST { "[TTABLE ]" <Version> } <char set
  131.    list> IAC SE
  132.  
  133.       Char set list:
  134.  
  135.       <sep> <character set> { ... <sep> <character set> }
  136.  
  137.    This message initiates a new CHARSET subnegotiation.  It can only be
  138.    sent by a side that has received a DO CHARSET message and sent a WILL
  139.    CHARSET message (in either order).
  140.  
  141.    The sender requests that all text sent to and by it be encoded in one
  142.    of the specified character sets.
  143.  
  144.    If the string [TTABLE] appears, the sender is willing to accept a
  145.    mapping (translation table) between any character set listed in <char
  146.    set list> and any character set desired by the receiver.
  147.  
  148.    <Version>  is an octet whose binary value is the highest version
  149.    level of the TTABLE-IS message which can be sent in response.  This
  150.    field must not be zero.  See the TTABLE-IS message for the permitted
  151.    version values.
  152.  
  153.    <Char set list>  is a sequence of 7-BIT ASCII printable characters.
  154.    The first octet defines the separator character (which must not
  155.    appear within any character set).  It is terminated by the IAC SE
  156.    sequence.  Case is not significant.  It consists of one or more
  157.    character sets.  The character sets should appear in order of
  158.    preference (most preferred first).
  159.  
  160.    <Sep>  is a separator octet, the value of which is chosen by the
  161.    sender.  Examples include a space or a semicolon.  Any value other
  162.    than IAC is allowed.  The obvious choice is a space or any other
  163.    punctuation symbol which does not appear in any of the character set
  164.    names.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Gellens                       Experimental                      [Page 3]
  171.  
  172. RFC 2066                 TELNET CHARSET Option              January 1997
  173.  
  174.  
  175.    <Character set>  is a sequence of 7-BIT ASCII printable characters.
  176.    Case is not significant.
  177.  
  178.    If a requested character set name does not start with "X-" or "x-",
  179.    it MUST be registered with the Internet Assigned Number Authority
  180.    (IANA) [2].
  181.  
  182.    The receiver responds in one of four ways:
  183.  
  184.    If the receiver is already sending text to and expecting text from
  185.    the sender to be encoded in one of the specified character sets, it
  186.    sends a positive acknowledgment (CHARSET ACCEPTED); it MUST NOT
  187.    ignore the message.  (Although ignoring the message is perhaps
  188.    suggested by some interpretations of the relevant RFCs ([1], [3]), in
  189.    the interests of determinacy it is not permitted.  This ensures that
  190.    the issuer does not need to time out and infer a response, while
  191.    avoiding (because there is no response to a positive acknowledgment)
  192.    the non-terminating subnegotiation which is the rationale in the RFCs
  193.    for the non-response behavior.)
  194.  
  195.    If the receiver is capable of handling at least one of the specified
  196.    character sets, it can respond with a positive acknowledgment for one
  197.    of the requested character sets.  Normally, it should pick the first
  198.    set it is capable of handling but may choose one based on its own
  199.    preferences.  After doing so, each side MUST encode subsequent text
  200.    in the specified character set.
  201.  
  202.    If the string [TTABLE] is present, and the receiver prefers to use a
  203.    character set not included in <char set list>, and is capable of
  204.    doing so, it can send a translate table (TTABLE-IS) response.
  205.  
  206.    If the receiver is not capable of handling any of the specified
  207.    character sets, it sends a negative acknowledgment (CHARSET
  208.    REJECTED).
  209.  
  210.    Because it is not valid to reply to a CHARSET REQUEST message with
  211.    another CHARSET REQUEST message, if a CHARSET REQUEST message is
  212.    received after sending one, it means that both sides have sent them
  213.    simultaneously.  In this case, the server side MUST issue a negative
  214.    acknowledgment.  The client side MUST respond to the one from the
  215.    server.
  216.  
  217.    IAC SB CHARSET ACCEPTED <Charset> IAC SE
  218.       This is a positive acknowledgment response to a CHARSET REQUEST
  219.       message; the receiver of the CHARSET REQUEST message acknowledges
  220.       its receipt and accepts the indicated character set.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gellens                       Experimental                      [Page 4]
  227.  
  228. RFC 2066                 TELNET CHARSET Option              January 1997
  229.  
  230.  
  231.       <Charset> is a character sequence identical to one of the
  232.       character sets in the CHARSET REQUEST message.  It is terminated
  233.       by the IAC SE sequence.
  234.  
  235.       Text messages which follow this response must now be coded in the
  236.       indicated character set.  This message terminates the current
  237.       CHARSET subnegotiation.
  238.  
  239.    IAC SB CHARSET REJECTED IAC SE
  240.       This is a negative acknowledgment response to a CHARSET REQUEST
  241.       message; the receiver of the CHARSET REQUEST message acknowledges
  242.       its receipt but refuses to use any of the requested character
  243.       sets.  Messages can not be sent in any of the indicated character
  244.       sets.  This message can also be sent by the sender of a TTABLE-IS
  245.       message, if multiple TTABLE-NAK messages were sent in response.
  246.       This message terminates the current CHARSET subnegotiation.
  247.  
  248.    IAC SB CHARSET TTABLE-IS <version> <syntax for version> IAC SE
  249.       In response to a CHARSET REQUEST message in which [TTABLE] was
  250.       specified, the receiver of the CHARSET REQUEST message
  251.       acknowledges its receipt and is transmitting a pair of tables
  252.       which define the mapping between specified character sets.
  253.  
  254.       <Version> is an octet whose binary value is the version level of
  255.       this TTABLE-IS message.  Different versions have different syntax.
  256.       The lowest version level is one (zero is not valid).  The current
  257.       highest version level is also one.  This field is provided so that
  258.       future versions of the TTABLE-SEND message can be specified, for
  259.       example, to handle character sets for which there is no simple
  260.       one-to-one character-for-character translation.  This might
  261.       include some forms of multi-octet character sets for which
  262.       translation algorithms or subsets need to be sent.
  263.  
  264.    Syntax for Version 1:
  265.  
  266.       <sep> <char set name 1> <sep> < char size 1> < char count 1> <char
  267.       set name 2> <sep> <char size 2> <char count 2> <map 1> <map 2>
  268.  
  269.       <Sep>  is a separator octet, the value of which is chosen by the
  270.       sender.  Examples include a space or a semicolon.  Any value other
  271.       than IAC is allowed.  The obvious choice is a space or any other
  272.       punctuation symbol which does not appear in either of the
  273.       character set names.
  274.  
  275.       <Char set name 1> and <Char set name 2>  are sequences of 7-BIT
  276.       ASCII printable characters which identify the two character sets
  277.       for which a mapping is being specified.  Each is terminated by
  278.       <sep>.  Case is not significant.  If a character set name does not
  279.  
  280.  
  281.  
  282. Gellens                       Experimental                      [Page 5]
  283.  
  284. RFC 2066                 TELNET CHARSET Option              January 1997
  285.  
  286.  
  287.       start with "X-" or "x-", it MUST be registered with IANA.  <Char
  288.       set name 1> MUST be chosen from the <char set list> in the CHARSET
  289.       REQUEST message.  <Char set name 2> can be arbitrarily chosen.
  290.       Text on the wire MUST be encoded using <char set name 2>.
  291.  
  292.       <Char size 1>  and <char size 2>  are single octets each.  The
  293.       binary value of the  octet is the number of bits nominally
  294.       required for each character in the corresponding table.  It SHOULD
  295.       be a multiple of eight.
  296.  
  297.       <Char count 1> and <char count 2>  are each three-octet binary
  298.       fields in Network Byte Order [6].  Each specifies how many
  299.       characters (of the maximum 2**<char size>) are being transmitted
  300.       in the corresponding map.
  301.  
  302.       <Map1> and <Map 2>  each consist of the corresponding <char count>
  303.       number of characters.  These characters form a mapping from all or
  304.       part of the characters in one of the specified character sets to
  305.       the correct characters in the other character set.  If the
  306.       indicated <char count> is less than  2**<char size>, the first
  307.       <char count> characters are being mapped, and the remaining
  308.       characters are assumed to not be changed (and thus map to
  309.       themselves).  That is, each map contains characters 0 through
  310.       <char count> -1.  <Map 1> maps from <char set name 1> to <char set
  311.       name 2>.  <Map 2> maps from <char set name 2> to <char set name
  312.       1>.  Translation between the character sets is thus an obvious
  313.       process of using the binary value of a character as an index into
  314.       the appropriate map.  The character at that index replaces the
  315.       original character.  If the index exceeds the <char count> for the
  316.       map, no translation is performed for the character.
  317.  
  318.       [Note to implementers: since TELNET works in octets, it is
  319.       possible for octets of value 255 to appear "spontaneously" when
  320.       using multi-octet or non-8-bit characters.  All octets of value
  321.       255 (other than IAC) MUST be quoted to conform with TELNET
  322.       requirements.  This applies even to octets within a table, or text
  323.       in a multi-octet character set.]
  324.  
  325.    IAC SB CHARSET TTABLE-ACK IAC SE
  326.       The sender acknowledges the successful receipt of the translate
  327.       table.  Text messages which follow this response must now be coded
  328.       in the character set specified as <char set name 2> of the
  329.       TTABLE-IS message.  This message terminates the current CHARSET
  330.       subnegotiation.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Gellens                       Experimental                      [Page 6]
  339.  
  340. RFC 2066                 TELNET CHARSET Option              January 1997
  341.  
  342.  
  343.    IAC SB CHARSET TTABLE-NAK IAC SE
  344.       The sender reports the unsuccessful receipt of the translate table
  345.       and requests that it be resent.  If subsequent transmission
  346.       attempts also fail, a TTABLE-REJECTED or CHARSET REJECTED message
  347.       (depending on which side sends it) should be sent instead of
  348.       additional futile TTABLE-IS and TTABLE-NAK messages.
  349.  
  350.    IAC SB CHARSET TTABLE-REJECTED IAC SE
  351.       In response to a TTABLE-IS message, the receiver of the TTABLE-IS
  352.       message acknowledges its receipt and indicates it is unable to
  353.       handle it.  This message terminates the current CHARSET
  354.       subnegotiation.
  355.  
  356.       Any system which supports the CHARSET option MUST fully support
  357.       the CHARSET REQUEST, ACCEPTED, REJECTED, and TTABLE-REJECTED
  358.       subnegotiation messages.  It MAY optionally fully support the
  359.       TTABLE-IS, TTABLE-ACK, and TTABLE-NAK messages.  If it does fully
  360.       support the TTABLE-IS message, it MUST also fully support the
  361.       TTABLE-ACK and TTABLE-NAK messages.
  362.  
  363. 3.   Default
  364.  
  365.    WON'T CHARSET
  366.  
  367.    DON'T CHARSET
  368.  
  369. 4.   Motivation for the Option
  370.  
  371.    Many TELNET sessions need to transmit data which is not in 7-bit
  372.    ASCII.  This is usually done by negotiating BINARY, and using local
  373.    conventions (or terminal type kluges) to determine the character set
  374.    of the data.  However, such methods tend not to interoperate well,
  375.    and have difficulties when multiple character sets need to be
  376.    supported by different sessions.
  377.  
  378.    Many computer systems now utilize a variety of character sets.
  379.    Increasingly, a server computer needs to document character sets or
  380.    translate transmissions and receptions using different pairs of
  381.    character sets on a per-application or per-connection basis.  This is
  382.    becoming more common as client and server computers become more
  383.    geographically disperse.  (And as servers are consolidated into
  384.    ever-larger hubs, serving ever-wider areas.)  In order for files,
  385.    databases, etc. to contain correct data, the server must determine
  386.    the character set in which the user is sending, and the character set
  387.    in which the application expects to receive.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Gellens                       Experimental                      [Page 7]
  395.  
  396. RFC 2066                 TELNET CHARSET Option              January 1997
  397.  
  398.  
  399.    In some cases, it is sufficient to determine the character set of the
  400.    end user (because every application on the server expects to use the
  401.    same character set, or because applications can handle the user's
  402.    character set), but in other cases different server applications
  403.    expect to use different character sets.  In the former case, an
  404.    initial CHARSET subnegotiation suffices.  In the latter case, the
  405.    server may need to initiate additional CHARSET subnegotiations as the
  406.    user switches between applications.
  407.  
  408.    At a minimum, the option described in this memo allows both sides to
  409.    be clear as to which character set is being used.  A minimal
  410.    implementation would have the server send DO CHARSET, and the client
  411.    send WILL CHARSET and CHARSET REQUEST.  The server could then
  412.    communicate the client's character set to applications using whatever
  413.    means are appropriate.  Such a server might refuse subsequent CHARSET
  414.    REQUEST messages from the client (if it lacked the ability to
  415.    communicate changed character set information to applications, for
  416.    example).  Another system might have a method whereby various
  417.    applications could communicate to the TELNET server their character
  418.    set needs and abilities, which the server would handle by initiating
  419.    new CHARSET REQUEST negotiations as appropriate.
  420.  
  421.    In some cases, servers may have a large set of clients which tend to
  422.    connect often (such as daily) and over a long period of time (such as
  423.    years).  The server administrators may strongly prefer that the
  424.    servers not do character set translation (to save CPU cycles when
  425.    serving very large numbers of users).  To avoid manually configuring
  426.    each copy of the user TELNET software, the administrators might
  427.    prefer that the software supports translate tables.  (If the client
  428.    software received a translate table from the server and stored it,
  429.    the table would only need to be sent once.)
  430.  
  431. 5.   Description of the Option
  432.  
  433.    When the client TELNET program is able to determine the user's
  434.    character set it should offer to specify the character set by sending
  435.    IAC WILL CHARSET.
  436.  
  437.    If the server system is able to make use of this information, it
  438.    replies with IAC DO CHARSET.  The client TELNET is then free to
  439.    request a character set in a subnegotiation at any time.
  440.  
  441.    Likewise, when the server is able to determine the expected character
  442.    set(s) of the user's application(s), it should send  IAC DO CHARSET
  443.    to request that the client system specify the character set it is
  444.    using.  Or the server could send IAC WILL CHARSET to offer to specify
  445.    the character sets.
  446.  
  447.  
  448.  
  449.  
  450. Gellens                       Experimental                      [Page 8]
  451.  
  452. RFC 2066                 TELNET CHARSET Option              January 1997
  453.  
  454.  
  455.    Once a character set has been determined, the server can either
  456.    perform the translation between the user and application character
  457.    sets itself, or request by additional CHARSET subnegotiations that
  458.    the client system do so.
  459.  
  460.    Once it has been established that both sides are capable of character
  461.    set negotiation (that is, each side has received either a WILL
  462.    CHARSET or a DO CHARSET message, and has also sent either a DO
  463.    CHARSET or a WILL CHARSET message), subnegotiations can be requested
  464.    at any time by whichever side has sent a WILL CHARSET message and
  465.    also received a DO CHARSET message (this may be either or both
  466.    sides).  Once a CHARSET subnegotiation has started, it must be
  467.    completed before additional CHARSET subnegotiations can be started
  468.    (there must never be more than one CHARSET subnegotiation active at
  469.    any given time).  When a subnegotiation has completed, additional
  470.    subnegotiations can be started at any time.
  471.  
  472.    If either side violates this rule and attempts to start a CHARSET
  473.    subnegotiation while one is already active, the other side MUST
  474.    reject the new subnegotiation by sending a CHARSET REJECTED message.
  475.  
  476.    Receipt of a CHARSET REJECTED or TTABLE-REJECTED message terminates
  477.    the subnegotiation, leaving the character set unchanged.  Receipt of
  478.    a CHARSET ACCEPTED or TTABLE-ACK message terminates the
  479.    subnegotiation, with the new character set in force.
  480.  
  481.    In some cases, both the server and the client systems are able to
  482.    perform translations and to send and receive in the character set(s)
  483.    expected by the other side.  In such cases, either side can request
  484.    that the other use the character set it prefers.  When both sides
  485.    simultaneously make such a request (send CHARSET REQUEST messages),
  486.    the server MUST reject the client's request by sending a CHARSET
  487.    REJECTED message.  The client system MUST respond to the server's
  488.    request.  (See the CHARSET REQUEST description, above.)
  489.  
  490.    When the client system makes the request first, and the server is
  491.    able to handle the requested character set(s), but prefers that the
  492.    client system instead use the server's (user application) character
  493.    set, it may reject the request, and issue a CHARSET REQUEST of its
  494.    own.  If the client system is unable to comply with the server's
  495.    preference and issues a CHARSET REJECTED message, the server can
  496.    issue a new CHARSET REQUEST message for one of the previous character
  497.    sets (one of those which the client system originally requested).
  498.    The client system would obviously accept this character set.
  499.  
  500.    While a CHARSET subnegotiation is in progress, data SHOULD be queued.
  501.    Once the CHARSET subnegotiation has terminated, the data can be sent
  502.    (in the correct character set).
  503.  
  504.  
  505.  
  506. Gellens                       Experimental                      [Page 9]
  507.  
  508. RFC 2066                 TELNET CHARSET Option              January 1997
  509.  
  510.  
  511.    Note that regardless of CHARSET negotiation, translation only applies
  512.    to text (not commands), and only occurs when in BINARY mode [4].  If
  513.    not in BINARY mode, all data is assumed to be in NVT ASCII [1].
  514.  
  515.    Also note that the CHARSET option should be used with the END OF
  516.    RECORD option [5] for block-mode terminals in order to be clear on
  517.    what character represents the end of each record.
  518.  
  519.    As an example of character set negotiation, consider a user on a
  520.    workstation using TELNET to communicate with a server.  In this
  521.    example, the workstation normally uses the Cyrillic (ASCII) character
  522.    set [2] but is capable of using EBCDIC-Cyrillic [2], and the server
  523.    normally uses EBCDIC-Cyrillic.  The server could handle the (ASCII)
  524.    Cyrillic character set, but prefers that instead the client system
  525.    uses the EBCDIC-Cyrillic character set.  (This and the following
  526.    examples do not show the full syntax of the subnegotiation messages.)
  527.  
  528.  
  529.                  CLIENT                        SERVER
  530.  
  531.              WILL CHARSET                   WILL CHARSET
  532.  
  533.              DO CHARSET                     DO CHARSET
  534.  
  535.              CHARSET REQUEST Cyrillic
  536.                  EBCDIC-Cyrillic
  537.  
  538.                                             CHARSET ACCEPTED EBCDIC-
  539.                                                Cyrillic
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Gellens                       Experimental                     [Page 10]
  563.  
  564. RFC 2066                 TELNET CHARSET Option              January 1997
  565.  
  566.  
  567.    Now consider a case where the workstation can't handle EBCDIC-
  568.    Cyrillic, but can accept a translate table:
  569.  
  570.                  CLIENT                        SERVER
  571.  
  572.               WILL CHARSET                   WILL CHARSET
  573.  
  574.               DO CHARSET                     DO CHARSET
  575.  
  576.               CHARSET REQUEST [TTABLE] 1
  577.                  Cyrillic
  578.  
  579.                                              CHARSET TTABLE-IS 1 Cyrillic
  580.                                                EBCDIC-Cyrillic
  581.  
  582.               CHARSET TTABLE-ACK
  583.  
  584.  
  585.    For another example, consider a case similar to the previous case,
  586.    but now the user switches server applications in the middle of the
  587.    session (denoted by ellipses), and the new application requires a
  588.    different character set:
  589.  
  590.                 CLIENT                        SERVER
  591.  
  592.               WILL CHARSET                   WILL CHARSET
  593.  
  594.               DO CHARSET                     DO CHARSET
  595.  
  596.               CHARSET REQUEST [TTABLE] 1
  597.                  Cyrillic EBCDIC-INT
  598.  
  599.                                              CHARSET TTABLE-IS 1 Cyrillic
  600.                                                EBCDIC-Cyrillic
  601.  
  602.               CHARSET TTABLE-ACK
  603.  
  604.               . . .                          . . .
  605.  
  606.  
  607.                                              CHARSET REQUEST EBCDIC-INT
  608.  
  609.               CHARSET ACCEPTED EBCDIC-INT
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Gellens                       Experimental                     [Page 11]
  619.  
  620. RFC 2066                 TELNET CHARSET Option              January 1997
  621.  
  622.  
  623. 6.   Security Considerations
  624.  
  625.    Security issues are not discussed in this memo.
  626.  
  627. 7.   References
  628.  
  629.    [1] Postel, J. and J. Reynolds, "Telnet Protocol
  630.        Specification", STD 8, RFC 854, ISI, May 1983.
  631.  
  632.    [2] Reynolds, J., and J. Postel, "Assigned Numbers",
  633.        STD 2, RFC 1700, ISI, October 1994.
  634.  
  635.    [3] Postel, J. and J. Reynolds, "Telnet Option
  636.        Specifications", STD 8, RFC 855, ISI, May 1983.
  637.  
  638.    [4] Postel, J. and J. Reynolds, "Telnet Binary
  639.        Transmission", STD 27, RFC 856, ISI, May 1983.
  640.  
  641.    [5] Postel, J., "Telnet End-Of-Record Option", RFC 885,
  642.        ISI, December 1983.
  643.  
  644.    [6] Postel, J., "Internet Official Protocol Standards",
  645.        STD 1, RFC 1920, IAB, March 1996.
  646.  
  647. 8.   Author's Address
  648.  
  649.    Randall Gellens
  650.    Unisys Corporation
  651.    25725 Jeronimo Road
  652.    Mail Stop 237
  653.    Mission Viejo, CA  92691
  654.    USA
  655.  
  656.    Phone:  +1.714.380.6350
  657.    Fax:    +1.714.380.5912
  658.    EMail:  Randy@MV.Unisys.Com
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Gellens                       Experimental                     [Page 12]
  675.  
  676.