Network Working Group R. Gellens
Request for Comments: 2066 Unisys
Category: Experimental January 1997
TELNET CHARSET Option
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
This document specifies a mechanism for passing character set and
translation information between a TELNET client and server. Use of
this mechanism enables an application used by a TELNET user to send
and receive data in the correct character set.
Either side can (subject to option negotiation) at any time request
that a (new) character set be used.
1. Command Names and Codes
CHARSET.......................42
REQUEST ....................01
ACCEPTED ...................02
REJECTED ...................03
TTABLE-IS ..................04
TTABLE-REJECTED ............05
TTABLE-ACK .................06
TTABLE-NAK .................07
As a convenience, standard TELNET text and codes for commands used in
this document are reproduced here (excerpted from [1]):
All TELNET commands consist of at least a two byte sequence: the
"Interpret as Command" (IAC) escape character followed by the code
for the command. The commands dealing with option negotiation are
three byte sequences, the third byte being the code for the option
referenced. ... [O]nly the IAC need be doubled to be sent as data,
and the other 255 codes may be passed transparently. The
following are [some of] the defined TELNET commands. Note that
these codes and code sequences have the indicated meaning only
when immediately preceded by an IAC.
Gellens Experimental [Page 1]
RFC 2066 TELNET CHARSET Option January 1997
NAME CODE MEANING
SE 240 End of subnegotiation parameters.
SB 250 Indicates that what follows is
subnegotiation of the indicated
option.
WILL 251 Indicates the desire to begin
performing, or confirmation that
you are now performing, the
indicated option.
WON'T 252 Indicates the refusal to perform,
or continue performing, the
indicated option.
DO 253 Indicates the request that the
other party perform, or
confirmation that you are expecting
the other party to perform, the
indicated option.
DON'T 254 Indicates the demand that the other
party stop performing, or
confirmation that you are no longer
expecting the other party to
perform, the indicated option.
IAC 255 Data Byte 255.
2. Command Meanings
A very simple meta-syntax is used, where most tokens represent
previously defined items (such as IAC); angle-brackets ("<>") are
used for items to be further defined; curly-braces ("{}") are used
around optional items; ellipses represent repeated sequences of
items; and quotes are used for literal strings.
IAC WILL CHARSET
The sender REQUESTS permission to, or AGREES to, use
CHARSET option subnegotiation to choose a character set.
IAC WON'T CHARSET
The sender REFUSES to use CHARSET option subnegotiation
to choose a character set.
Gellens Experimental [Page 2]
RFC 2066 TELNET CHARSET Option January 1997
IAC DO CHARSET
The sender REQUESTS that, or AGREES to have, the other
side use CHARSET option subnegotiation to choose a
character set.
IAC DON'T CHARSET
The sender DEMANDS that the other side not use the
CHARSET option subnegotiation.
IAC SB CHARSET REQUEST { "[TTABLE ]" } IAC SE
Char set list:
{ ... }
This message initiates a new CHARSET subnegotiation. It can only be
sent by a side that has received a DO CHARSET message and sent a WILL
CHARSET message (in either order).
The sender requests that all text sent to and by it be encoded in one
of the specified character sets.
If the string [TTABLE] appears, the sender is willing to accept a
mapping (translation table) between any character set listed in and any character set desired by the receiver.
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.
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).
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
is a sequence of 7-BIT ASCII printable characters.
Case is not significant.
If a requested character set name does not start with "X-" or "x-",
it MUST be registered with the Internet Assigned Number Authority
(IANA) [2].
The receiver responds in one of four ways:
If the receiver is already sending text to and expecting text from
the sender to be encoded in one of the specified character sets, it
sends a positive acknowledgment (CHARSET ACCEPTED); it MUST NOT
ignore the message. (Although ignoring the message is perhaps
suggested by some interpretations of the relevant RFCs ([1], [3]), in
the interests of determinacy it is not permitted. This ensures that
the issuer does not need to time out and infer a response, while
avoiding (because there is no response to a positive acknowledgment)
the non-terminating subnegotiation which is the rationale in the RFCs
for the non-response behavior.)
If the receiver is capable of handling at least one of the specified
character sets, it can respond with a positive acknowledgment for one
of the requested character sets. Normally, it should pick the first
set it is capable of handling but may choose one based on its own
preferences. After doing so, each side MUST encode subsequent text
in the specified character set.
If the string [TTABLE] is present, and the receiver prefers to use a
character set not included in , and is capable of
doing so, it can send a translate table (TTABLE-IS) response.
If the receiver is not capable of handling any of the specified
character sets, it sends a negative acknowledgment (CHARSET
REJECTED).
Because it is not valid to reply to a CHARSET REQUEST message with
another CHARSET REQUEST message, if a CHARSET REQUEST message is
received after sending one, it means that both sides have sent them
simultaneously. In this case, the server side MUST issue a negative
acknowledgment. The client side MUST respond to the one from the
server.
IAC SB CHARSET ACCEPTED 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
is a character sequence identical to one of the
character sets in the CHARSET REQUEST message. It is terminated
by the IAC SE sequence.
Text messages which follow this response must now be coded in the
indicated character set. This message terminates the current
CHARSET subnegotiation.
IAC SB CHARSET REJECTED IAC SE
This is a negative acknowledgment response to a CHARSET REQUEST
message; the receiver of the CHARSET REQUEST message acknowledges
its receipt but refuses to use any of the requested character
sets. Messages can not be sent in any of the indicated character
sets. This message can also be sent by the sender of a TTABLE-IS
message, if multiple TTABLE-NAK messages were sent in response.
This message terminates the current CHARSET subnegotiation.
IAC SB CHARSET TTABLE-IS 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.
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:
< char size 1> < char count 1>