Browse Prior Art Database

TELNET CHARSET Option (RFC2066)

IP.com Disclosure Number: IPCOM000002617D
Original Publication Date: 1997-Jan-01
Included in the Prior Art Database: 2019-Feb-16
Document File: 12 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Gellens: AUTHOR

Related Documents

10.17487/RFC2066: DOI

Abstract

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 15% of the total text.

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

Processing...
Loading...