doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1091.txt b/doc/rfc/rfc1091.txt
new file mode 100644
index 0000000..011056f
--- /dev/null
+++ b/doc/rfc/rfc1091.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                  J. VanBokkelen
+Request for Comments: 1091                         FTP Software, Inc.
+Obsoletes: RFC 930                                      February 1989
+
+
+                      Telnet Terminal-Type Option
+
+Status of This Memo
+
+   This RFC specifies a standard for the Internet community.  Hosts on
+   the Internet that exchange terminal type information within the
+   Telnet protocol are expected to adopt and implement this standard.
+
+   This standard supersedes RFC 930.  A change is made to permit cycling
+   through a list of possible terminal types and selecting the most
+   appropriate.
+
+   Distribution of this memo is unlimited.
+
+1. Command Name and Code
+
+      TERMINAL-TYPE   24
+
+2. Command Meanings
+
+      IAC WILL TERMINAL-TYPE
+
+         Sender is willing to send terminal type information in a
+         subsequent sub-negotiation.
+
+      IAC WON'T TERMINAL-TYPE
+
+         Sender refuses to send terminal type information.
+
+      IAC DO TERMINAL-TYPE
+
+         Sender is willing to receive terminal type information in a
+         subsequent sub-negotiation.
+
+      IAC DON'T TERMINAL-TYPE
+
+         Sender refuses to accept terminal type information.
+
+
+
+
+
+
+
+
+
+VanBokkelen                                                     [Page 1]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+      IAC SB TERMINAL-TYPE SEND IAC SE
+
+         Server requests client to transmit his (the client's) next
+         terminal type, and switch emulation modes (if more than one
+         terminal type is supported).  The code for SEND is 1. (See
+         below.)
+
+      IAC SB TERMINAL-TYPE IS ... IAC SE
+
+         Client is stating the name of his current (or only) terminal
+         type.  The code for IS is 0.  (See below.)
+
+3. Default
+
+      WON'T TERMINAL-TYPE
+
+         Terminal type information will not be exchanged.
+
+      DON'T TERMINAL-TYPE
+
+         Terminal type information will not be exchanged.
+
+4. Motivation for the Option
+
+   On most machines with bit-mapped displays (e.g., PCs and graphics
+   workstations) a client terminal emulation program is used to simulate
+   a conventional ASCII terminal.  Most of these programs have multiple
+   emulation modes, frequently with widely varying characteristics.
+   Likewise, modern host system software and applications can deal with
+   a variety of terminal types.  What is needed is a means for the
+   client to present a list of available terminal emulation modes to the
+   server, from which the server can select the one it prefers (for
+   arbitrary reasons).  There is also need for a mechanism to change
+   emulation modes during the course of a session, perhaps according to
+   the needs of applications programs.
+
+   Existing terminal-type passing mechanisms within Telnet were not
+   designed with multiple emulation modes in mind.  While multiple names
+   are allowed, they are assumed to be synonyms.  Emulation mode changes
+   are not defined, and the list of modes can only be scanned once.
+
+   This document defines a simple extension to the existing mechanisms,
+   which meets both of the above criteria.  It makes one assumption
+   about the behaviour of implementations coded to the previous standard
+   in order to obtain full backwards-compatibility.
+
+
+
+
+
+
+VanBokkelen                                                     [Page 2]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+5. Description of the Option
+
+   Willingness to exchange terminal-type information is agreed upon via
+   conventional Telnet option negotiation.  WILL and DO are used only to
+   obtain and grant permission for future discussion.  The actual
+   exchange of status information occurs within option subcommands (IAC
+   SB TERMINAL-TYPE...).
+
+   Once the two hosts have exchanged a WILL and a DO, the sender of the
+   DO TERMINAL-TYPE (the server) is free to request type information.
+   Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
+   and only the client may transmit actual type information (within an
+   IAC SB TERMINAL-TYPE IS ... IAC SE command).  Terminal type
+   information may not be sent spontaneously, but only in response to a
+   request.
+
+   The terminal type information is an NVT ASCII string.  Within this
+   string, upper and lower case are considered equivalent.  The complete
+   list of valid terminal type names can be found in the latest
+   "Assigned Numbers" RFC [4].
+
+   The transmission of terminal type information by the Telnet client in
+   response to a query from the Telnet server implies that the client
+   must simultaneously change emulation mode, unless the terminal type
+   sent is a synonym of the preceding terminal type, or there are other
+   prerequisites for entering the new regime (e.g., having agreed upon
+   the Telnet binary option).  The receipt of such information by the
+   Telnet server does not imply any immediate change of processing.
+   However, the information may be passed to a process, which may alter
+   the data it sends to suit the particular characteristics of the
+   terminal.  For example, some operating systems have a terminal driver
+   that accepts a code indicating the type of terminal being driven.
+   Using the TERMINAL TYPE and BINARY options, a telnet server program
+   on such a system could arrange to have terminals driven as if they
+   were directly connected, including special functions not available to
+   a standard Network Virtual Terminal.
+
+   Note that this specification is deliberately asymmetric.  It is
+   assumed that server operating systems and applications in general
+   cannot change terminal types at arbitrary points in a session.  Thus,
+   the client may only send a new type (and potentially change emulation
+   modes) when the server requests that it do so.
+
+6.  Implementation Issues
+
+   The "terminal type" information may be any NVT ASCII string
+   meaningful to both ends of the negotiation.  The list of terminal
+   type names in "Assigned Numbers" is intended to minimize confusion
+
+
+
+VanBokkelen                                                     [Page 3]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+   caused by alternative "spellings" of the terminal type.  For example,
+   confusion would arise if one party were to call a terminal "IBM3278-
+   2" while the other called it "IBM-3278/2".  There is no negative
+   acknowledgement for a terminal type that is not understood, but
+   certain other options (such as switching to BINARY mode) may be
+   refused if a valid terminal type name has not been specified.
+
+   In some cases, either a particular terminal may be known by more than
+   one name, for example a specific type and a more generic type, or the
+   client may be a workstation with integrated display capable of
+   emulating more than one kind of terminal.  In such cases, the sender
+   of the TERMINAL-TYPE IS command should reply to successive TERMINAL-
+   TYPE SEND commands with the various names.  In this way, a telnet
+   server that does not understand the first response can prompt for
+   alternatives.  If different terminal emulations are supported by the
+   client, the mode of the emulator must be changed to match the last
+   type sent, unless the particular emulation has other Telnet options
+   (e.g., BINARY) as prerequisites (in which case, the emulation will
+   switch to the last type sent when the prerequisite is fulfilled).
+   When types are synonyms, they should be sent in order from most to
+   least specific.
+
+   When the server (the receiver of the TERMINAL-TYPE IS) receives the
+   same response two consecutive times, this indicates the end of the
+   list of available types.  Similarly, the client should indicate it
+   has sent all available names by repeating the last one sent.  If an
+   additional request is received, this indicates that the server (the
+   sender of the IS) wishes to return to the top of the list of
+   available types (probably to select the least of N evils).
+
+   Server implementations conforming to the previous standard will cease
+   sending TERMINAL-TYPE SEND commands after receiving the same response
+   two consecutive times, which will work according to the old standard.
+   It is assumed that client implementations conforming to the previous
+   standard will send the last type on the list in response to a third
+   query (as well as the second).  New-style servers must recognize this
+   and not send more queries.
+
+   The type "UNKNOWN" should be used if the type of the terminal is
+   unknown or unlikely to be recognized by the other party.
+
+   The complete and up-to-date list of terminal type names will be
+   maintained in the "Assigned Numbers".  The maximum length of a
+   terminal type name is 40 characters.
+
+7. User Interfaces
+
+   Telnet clients and servers conforming to this specification should
+
+
+
+VanBokkelen                                                     [Page 4]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+   provide the following functions in their user interfaces:
+
+   Clients supporting multiple emulation modes should allow the user to
+   specify which of the modes is preferred (which name is sent first),
+   prior to connection establishment.  The order of the names sent
+   cannot be changed after the negotiation has begun.  This initial mode
+   will also become the default with servers which do not support
+   TERMINAL TYPE.
+
+   Servers should store the current terminal type name and the list of
+   available names in a manner such that they are accessible to both the
+   user (via a keyboard command) and any applications which need the
+   information.  In addition, there should be a corresponding mechanism
+   to request a change of terminal types, by initiating a series of
+   SEND/IS sub-negotiations.
+
+8. Examples
+
+   In this example, the server finds the first type acceptable.
+
+      Server: IAC DO TERMINAL-TYPE
+
+      Client: IAC WILL TERMINAL-TYPE
+
+         (Server may now request a terminal type at any time.)
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
+
+   In this example, the server requests additional terminal types, and
+   accepts the second (and last on the client's list) type sent (RFC 930
+   compatible):
+
+      Server: IAC DO TERMINAL-TYPE
+
+      Client: IAC WILL TERMINAL-TYPE
+
+         (Server may now request a terminal type at any time.)
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS ZENITH-H19 IAC SE
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
+
+
+
+
+VanBokkelen                                                     [Page 5]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
+
+   In this example, the server requests additional terminal types, and
+   proceeds beyond the end-of-list, to select the first type offered by
+   the client (new-type client and server):
+
+      Server: IAC DO TERMINAL-TYPE
+
+      Client: IAC WILL TERMINAL-TYPE
+
+         (Server may now request a terminal type at any time.)
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS DEC-VT100 IAC SE
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
+
+      Server: IAC SB TERMINAL-TYPE SEND IAC SE
+
+      Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
+
+9. References:
+
+     [1]  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
+          RFC 854, USC Information Sciences Institute, May 1983.
+
+     [2]  Postel, J., and J. Reynolds, "Telnet Option Specification",
+          RFC 855, USC Information Sciences Institute, May 1983.
+
+     [3]  Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
+          RFC 930, University of Wisconsin - Madison, January 1985.
+
+     [4]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1010,
+          USC Information Sciences Institute, May 1987.
+
+
+
+
+VanBokkelen                                                     [Page 6]
+
+RFC 1091              Telnet Terminal-Type Option          February 1989
+
+
+Reviser's note:
+
+   I owe much of this text to RFCs 884 and 930, by Marvin Solomon and
+   Edward Wimmers of the University of Wisconsin - Madison, and I owe
+   the idea of the extension to discussions on the "tn3270" mailing list
+   in the Summer of 1987.
+
+Author's Address
+
+   James VanBokkelen
+   FTP Software, Inc.
+   26 Princess Street
+   Wakefield, MA 01880-3004
+
+   Phone: (617) 246-0900
+
+   Email: jbvb@ftp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+VanBokkelen                                                     [Page 7]
+
\ No newline at end of file