diff options
Diffstat (limited to 'doc/rfc/rfc158.txt')
-rw-r--r-- | doc/rfc/rfc158.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc158.txt b/doc/rfc/rfc158.txt new file mode 100644 index 0000000..fb79628 --- /dev/null +++ b/doc/rfc/rfc158.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group T. O'Sullivan +Request for Comments: 158 Raytheon +NIC: 6768 19 May 1971 + + + TELNET Protocol + + This request for comment is being circulated by the TELNET committee + to solicit comments, evaluation, and requests for modification of the + proposed protocol presented here. Unless comments are received by + the writer within two weeks of the date of this RFC, they will not be + considered in the preparation of official TELNET PROTOCOL document. + + The proposed document is the result of the work of the committee. It + represents a TELNET protocol felt to be adequate for initial + implementation. + + Readers are referenced to the following previous releases of + information: + + 1. Conventions for Using an IBM 2741 Terminal or a User Console + for Access to Network Server HOSTS + Joel Winett, RFC 110 (NIC #5809) + + 2. Response to RFD 110 + Wayne Hathaway, RFC 135 (NIC #6712) + + 3. Level III Server Protocol for the Lincoln Laboratory 360/67 + HOST + Joel Winett, RFC 109 (NIC #5808) + + 4. First Cut at a Proposed TELNET Protocol + J. Melvin, D. Watson, RFC 97 (NIC #5740) + + 5. ASCII Format for Network Interchange + V. Cerf, RFC 20 (NIC #4722) + + 6. Discussion of TELNET PROTOCOL + Tom O' Sullivan, RFC 139 (NIC 6717) + (Although relevant to the obsoleted RFC 137 (NIC 6714) many of + the examples still hold. A replacement discussion document RFC + 159 (NIC 6769) will be forthcoming in the near future). + + + + + + + + + +T. O'Sullivan [Page 1] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + TELNET PROTOCOL + + + + A Proposed Document + + T. O'Sullivan for the TELNET Committee + + Will Crowther BBN + Bob Long SDC + John Melvin SRI-ARC + Bob Metcalfe Harvard + Ed Meyer MAC + Tom O'Sullivan (Chairman) Raytheon + Joel Winett MIT-LL + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +T. O'Sullivan [Page 2] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + +Telnet Protocol + + TELNET is a third-level protocol, the function of which is to make a + terminal (or process) at a using site appear to the system or a + process at a serving site as logically equivalent to a terminal + "directly" connected to the serving site. In performing this + function, the protocol attempts to minimize the amount of information + each HOST must keep about the characteristics of other HOSTS. + + Definitions + + Protocol Levels (see Figure 1) + + Level 1 + HOST-IMP protocol specified by BBN in NIC 5735, Specifications + for the Interconnection of a HOST and an IMP (BBN Report 1822) + + Level 2 + HOST-HOST protocol performed by NCPs as described in Document + Number 1 (NIC 5413) and subsequent amendments, see RFC 107 (NIC + #5806) + + One view of the NCP's function is that it takes information + from the net and routes it to receiving processes via + mechanisms internal to each HOST; conversely, processes use + the NCP, via internal system calls, to have information + routed to other processes in the net (via the other + processes' NCPs). + + Level 3 (see Figure 2) + Level 3 is, by definition, the place to which and from which + the NCP communicates internally in its own host. + + This level may be equivalent to the user process level in + some systems, but this may not be the case in all systems. + In using sites, the TELNET process operates at this level. + In serving sites, the TELNET server operates at this level. + + Initial Connection Protocol (ICP) + + An agreed-upon sequence of level 3 exchanges between two processes + which is, in general, used to synchronize the connection dialogue + between the processes, e.g., RFC 80 (NIC #5608) #1, as revised by + subsequent information. + + + + + + + +T. O'Sullivan [Page 3] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + Serving Site + + The HOST into which the TELNET process is directing the user's + keyboard input and from which the TELNET process is receiving + control information and data effecting the user's terminal. At + the serving site, a TELNET server is executing. + + Using Site + + The HOST in which the TELNET process is executing. + + Sending Site + + The HOST transmitting data, could be either using site or serving + site. + + Receiving Site + + Converse of sending site. + + User + + The person or process "driving" the TELNET process. + + In providing services the TELNET protocol will use established + network conventions, specifically the Network Control Program, and + Initial Connection Protocol referenced in the above definitions, + using a byte size of 8 bits on the permanent connection. + + The TELNET protocol provides for a Network Virtual Terminal (NVT) + through which users may transmit and receive data over connections + between the using site and the serving site. + + The code of the NVT will be full 7 bit ASCII. The seven-bit code + will be transmitted in eight-bit bytes, the high order bit set to + zero. + + It will be the responsibility of the using site to provide its users + with a means of producing all 128 ASCII codes, as well as a selected + set of special TELNET control signals (see Figure 3). + + The ASCII character ESC will be employed by the user as an escape + signal indicating that the next character(s) has special meaning. + The meaning assigned to escape code will be serving site defined and + therefore may not be consistant across the network. + + + + + + +T. O'Sullivan [Page 4] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + It will be the responsibility of the serving site to specify for + users how the NVT code will be used to represent the codes normally + generated by a local terminal. The serving sites specification of + this representation is expected, where reasonable, to map on a one- + for-one basis for ASCII graphics and controls that are provided + through local terminals. The serving site will also specify how the + escape conventions will be interpreted by the system. + + The end of a line will be represented in the NVT as carriage return + (X'0D') followed by line feed. (X'0A') + + The protocol assumes that initially the serving site will not provide + any echo to the using site. + + Each TELNET control signal for which code must be sent over the + connection will be represented in the NVT by an eight-bit code, with + the high order bit set to one. Following are the special codes + established to date. (U) indicates that in most implementations the + user would be expected to have the ability to signal the TELNET + process from his terminal to initiate the code. + + Code X'A0' + + Source: Both Sites (U) + Meaning: A DATA TYPE[1] signal indicating that code will be + transmitted by NVT, i.e., using the seven-bit ASCII + conventions. + + Code X'80' + + Source: Using Site (U) + Meaning: Order using site NCP to send an INS and insert X'80' in + data stream. + + Code X'81' + + Source: Using Site (U) + Meaning: Break or Attention, and reverse break. + + Code X'82' + + Source: Both Sites + Meaning: No op + + Code X'83' + + Source: Both Sites + Meaning: Don't Echo + + + +T. O'Sullivan [Page 5] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + Code X'84' + + Source: Both Sites + Meaning: You Echo + + Code X'85' + + Source: Serving Site + Meaning: Hide your input [2] + + Some special TELNET control signals are required to permit the user + on some systems to send control information to the using site TELNET + process[3]. These do not require a corresponding control code for + transmission. The local TELNET control signals are: + + 1. Transmit all data to this point. + 2. Suppress transmission of end of line, send all other data. + + Data is to be forwarded to the NCP for transmission as convenient, + but at least at the end of line, end of line suppression, and + transmit signals. If the normal line length of the sending site is + greater than the allocation given by the receiving site, the sending + sites NCP, TELNET process, or TELNET server must be prepared to send + line segments in convenient lengths until the full line has been + sent. + + A minimum implementation for TELNET for both using site and serving + site follows: + + Using Site + + 1.) Provide User (human or process) with ability to cause all + 128 ASCII codes to be transmitted in the required 8 bit + field to the serving site. + + 2.) Ignore (and strip) all TELNET control characters received + from the serving site. + + 3.) Provide echo or local print capability to local user + terminals. + + 4.) Provide for CR-LF end of line convention. + + 5.) Implement local TELNET controls (See discussion above of + local TELNET control signals) for transmit or suppress + end of line. + + + + + +T. O'Sullivan [Page 6] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + Serving Site + + 1.) Provide (and announce) one for one mapping between ASCII + and Serving Site character and control set (or if Serving + Site set greater than 128, a sub set.) + + 2.) Ignore (and strip) all TELNET control characters received + from the Using Site. + + 3.) Assume Using Site will provide local terminal echo or + print capability. + + 4.) Provide for CR-LF end of line convention. + +This document will be revised as necessary to provide conventions for +data types in addition to the NVT ASCII type. + + + + + +|<------- 32 ------->|<-8->|<-8->|<-- 16 -->|<-8->|<--- ++--------------------+-----+-----+----------+-----+------------------ +| leader | x |size | count | x | TEXT ++--------------------+-----+-----+----------+-----+------------------ +|<---- level 1 ---->| + message leader + +|<------------------ level 2 ------------------>| + message preamble + + level 3 + |<- message text..--> + + Figure 1. Network Message on Link 2-31 + Indicating Portions of Interest to Various Levels + + + + + + + + + + + + + + + +T. O'Sullivan [Page 7] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + + USING HOST Serving HOST + -----------------------+ +---------------------- + | | + \ | | / +Sub- \ -----------------| +-+ +-+ |-----------------/ +Sys- \ | |I| |I| | NCP / + tems+---> <--->|M|---NETWORK--|M|<---> ^ / + | \ NCP | |P| |P| | +-----|-----/ + | \ | +-+ +-+ | | v / + | \ | | | TELNET / USER + TELNET )___________| |--|Protocol( PROCESS + | ) | | |Server <--->Sub + | / | | | ^^ \Systems + | / TTY | | +----||-----\ETC +User +---> HANDLER <---> Local | TTY vv \ +Pro- / | Terminals | Handles \ +cesses/-----------------| |-----------------\ + / | | \ + | | + -----------------------+ +---------------------- + +<---> TELNET path path + + Figure 2. Current and Candidate Future TELNET Paths + + + + + + + + + + + + + + + + + + + + + + + + + + + +T. O'Sullivan [Page 8] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + ++---------------------------+----+----+----+----+----+----+----+----+ +|\ b8 -> | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +| \ b7 -> | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | +| \ b6 -> | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | +|B \ b5 -> | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | +| I +---+---+---+---+------+----+----+----+----+----+----+----+----+ ++ T | b | b | b | b |\COL->| | | | | | | | | +\ S| 4 | 3 | 2 | 1 | \ | | | | | | | | | + \ | | | | | |\ | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | + \ | | | | | | | | | v \ | | | | | | | | | + \ | v | v | v | v |ROW \ | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 0 | 0 | 0 |NUL |DLE | SP | 0 | @ | P | \ | p | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 0 | 1 | 1 |SOH |DC1 | ! | 1 | A | Q | a | q | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 1 | 0 | 2 |STX |DC2 | " | 2 | B | R | b | r | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 1 | 1 | 3 |ETX |DC3 | # | 3 | C | S | c | s | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 0 | 0 | 4 |EOT |DC4 | $ | 4 | D | T | d | t | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 0 | 1 | 5 |ENO |NAC | % | 5 | E | U | e | u | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 1 | 0 | 6 |ACK |SYN | & | 6 | F | V | f | v | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 1 | 1 | 7 |BEL |ETB | ' | 7 | G | W | g | w | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 0 | 0 | 8 | BS |CAN | ( | 8 | H | X | h | x | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 0 | 1 | 9 | HT | EM | ) | 9 | I | Y | i | y | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 1 | 0 | 10 | LF |SUB | * | : | J | Z | j | z | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 1 | 1 | 11 | VT |ESC | + | ; | K | [ | k | { | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 0 | 0 | 12 | FF | FS | , | < | L | \ | l | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 0 | 1 | 13 | CR | GS | - | = | M | ] | m | } | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 1 | 0 | 14 | S0 | RS | . | > | N | ^ | n | ~ | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 1 | 1 | 15 | S1 | US | / | ? | O | _ | o |DEL | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + Code Structure 8 7 6 5 4 3 2 1 + --- --- --- --- --- --- --- --- --- --- + + + + + +T. O'Sullivan [Page 9] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + ++---------------------------+----+----+----+----+----+----+----+----+ +|\ b8 -> | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | +| \ b7 -> | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | +| \ b6 -> | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | +|B \ b5 -> | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | +| I +---+---+---+---+------+----+----+----+----+----+----+----+----+ ++ T | b | b | b | b |\COL->| | | | | | | | | +\ S| 4 | 3 | 2 | 1 | \ | | | | | | | | | + \ | | | | | |\ | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | + \ | | | | | | | | | v \ | | | | | | | | | + \ | v | v | v | v |ROW \ | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 0 | 0 | 0 |'80'| |'A0'| | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 0 | 1 | 1 |'81'| | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 1 | 0 | 2 |'82'| | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 0 | 1 | 1 | 3 |'83'| | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 0 | 0 | 4 |'84'| | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 0 | 1 | 5 |'85'| | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 1 | 0 | 6 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 0 | 1 | 1 | 1 | 7 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 0 | 0 | 8 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 0 | 1 | 9 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 1 | 0 | 10 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 0 | 1 | 1 | 11 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 0 | 0 | 12 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 0 | 1 | 13 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 1 | 0 | 14 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + | 1 | 1 | 1 | 1 | 15 | | | | | | | | | + +---+---+---+---+------+----+----+----+----+----+----+----+----+ + + 'XX' = HEX designation for codes assigned to TELNET Control Signals. + + Figure 3. Official Network Virtual Terminal Code + + + +T. O'Sullivan [Page 10] + +RFC 158 TELNET PROTOCOL 19 May 1971 + + +Endnotes + + [1] A one-byte DATA TYPE signal is sent as the first byte of data + over a connection. A default is employed if the first byte over a + connection has the high order bit set to zero, and it is assumed that + the seven-bit ASCII NVT convention will be employed. Most + implementations and applications may expect the DATA TYPES to be + symmetrical at any point in time. (i.e. both using a serving site + using the same DATA TYPE.) Other data types for which codes are + currently assigned are: + + X'A1' Transparency + X'A2' EBCDIC + X'A3' Special String to TELNET (I'll use your code) + X'A4' End Special String to TELNET (I'll use my code) + + [2] i.e. suppress printing of password. + + [3] In some cases, for prolonged [periods of special treatment, local + implementation may dictate permitting the user to set a "mode" to + prevail until explicitly discarded. + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Lorrie Shiota 2/02] + + + + + + + + + + + + + + + + + + + + + + + + + + +T. O'Sullivan [Page 11] + |