From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc97.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc97.txt (limited to 'doc/rfc/rfc97.txt') diff --git a/doc/rfc/rfc97.txt b/doc/rfc/rfc97.txt new file mode 100644 index 0000000..79f0a6c --- /dev/null +++ b/doc/rfc/rfc97.txt @@ -0,0 +1,619 @@ + + + + + + +NETWORK WORKING GROUP NIC 5740 +Request for Comments #97 John T. Melvin + Richard W. Watson + SRI-ARC + 15 February 1971 + + + A FIRST CUT AT A PROPOSED TELNET PROTOCOL + +1 Introduction + + This paper describes a first cut at a proposed Telnet protocol. + _Telnet_ is a process which runs at a _user's_ _site_ and allows him + to utilize a typewriter-like terminal to gain interactive service + from a remote _server_ _site over the ARPA Network. This paper was + motivated by our need to set specifications for a protocol which + would allow online access to the Network Information Center (NIC). + The Online System running at the Network Information Center we will + refer to as NLS(NIC). On thinking about the problem of setting + specifications for access to the NIC, we have tried to generalize our + ideas so that they would apply to other systems with characteristics + similar to ours. We realize that there are other terminal hardware- + software disciplines which might find it difficult to conform to all + the requirements stated here and, therefore, the final Telnet + protocol will differ from the one stated in this NWG/RFC. One + conclusion that we may all have to come to is that connection with + the network may force us toward a more standard way of handling + terminals and their character streams in our monitors and terminal + control hardware. In the meantime, we hope that this paper and + others on the same subject that may be in process, coupled with a + survey of hardware-software requirements at each site by a NWG + subgroup, can result in an initial standard network Telnet protocol + being agreed upon quickly, as it is important to get users onto the + network as soon as possible so that interactive network usage can + indicate further directions for network protocol evolution. Next we + outline some design problems, then propose some conventions to solve + these problems for access to systems such as the NLS(NIC) and + indicate some problems needing further study. The proposed + conventions for access to the NLS(NIC) are summarized in Appendix A. + +2 Some Design Problems + + 2A. Basic Assumption + + The function of the Telnet process is to make a terminal at a + user site appear over the network as logically equivalent to a + terminal "directly" connected to the server site. There are a number + of implications of this basic function. + + + +Melvin & Watson [Page 1] + +RFC 97 Proposed Telnet Protocol February 1971 + + + i) The user should be able to cause generation of all codes which + a server system terminal can generate. With respect to the + Network Information Center and some other sites it would seem a + reasonable requirement to have keying conventions so that the user + can generate all 128 ASCII character codes as input to the + network. Other sites with different character codes may require a + Telnet process to provide those codes to the network. + + ii) The user should be able to escape back to his local system or + escape from the server process to the server system. + + iii) The Telnets of line-at-a-time systems should be able to work + with character-at-a-time systems and line-at-a-time systems and + Telnets of character-at-a-time systems should be able to work + with line-at-a-time and character-at-a-time systems. + + 2B Echo Control + + We use the term echo control rather than the terms half duplex + or full duplex because the Telnet connection is in reality full + duplex with respect to network transmissions. Three terminal cases + need to be considered. + + Case 1 - Character-at-a-time serving site echoed + + Case 2 - Character-at-a-time user site echoed + + Case 3 - Line-at-a-time user site echoed + + Some serving sites may be able to operate with all three cases and + some convention is required to set the mode. Strictly speaking, what + characters are echoed for what keys struck is of no concern to the + serving site, although one would like to try to minimize differences + in typescript as it appears to the user. + + 2C Format Control Characters + + The format control characters of horizontal tab (HT), vertical + tab (VT), form feed (FF), line feed (LF), and carriage return (CR), + need to be handled in a consistent way for Cases 2 and 3 above. With + Case 1 above, the situation is simplified. + + 2D Network Message Boundaries + + The NCP to NCP protocol was specified with the goal of having + the network message boundaries being invisible to the user processes. + It would be good if this goal could be maintained, but it may be + difficult with some line-at-a-time systems. + + + +Melvin & Watson [Page 2] + +RFC 97 Proposed Telnet Protocol February 1971 + + + 2E An Implementation Convention + + ConVentions to solve the above problems are most simply + established if we assume that the character stream received from a + Telnet process by the server site is entered into that point in the + server monitor where character input from "direct1y" connected + terminals is entered and output from the server process is entered + into the monitor point where normal character output is entered. The + server NCP receives its input at the point where normal monitor + character output is obtained. In other words, the server process + would obtain its input from the server monitor character buffers and + send its output to these buffers rather than obtainIng input directly + from NCP buffers or outputting to NCP buffers. + + The Telnet process, on the other hand, would obtain and send + character streams directly from or to its local NCP. + + Other situations exist where the user processes at both ends + communicate directly with the NCP. Therefore, we would recommend + that both modes of connection (user process-monitor-NCP, or user + process-NCP) be available for communication between the NCP and a + user process. These modes would be set under program control by the + user process. The initial network convention during the login + procedure and until changed by the server process would be to obtain + characters from and send characters to the monitor. The server NCP + communicates with the monitor also. The scheme is illustrated in + Figure 1. + + The motivation for such flexibility may be clearer from the + discussion below. + +3 Proposed Telnet Conventions + + 3A The server site is to assume initially that echoing is performed + by a user site process until explict1y commanded otherwise. If the + user site can send character-at-a-time, then after connection and + login have been established, tne user could switch Lo server-site- + echo by command to the server site and then command (invisible to the + server site) his local Telnet to change its echo mode also. + + 3B The server process is to assume it will receive the same + character set which terminals "directly" connected to it can + generate. (We recommend at least 128 character ASCII.) The user's + Telnet may have to recognize two-character sequences to enable + generation of both upper and lower-case codes and the control codes. + We recommend that the user be able to set either upper or lower case + as the default case for single case terminals and be able to specify + a case shift character. The user should also be able to specify a + + + +Melvin & Watson [Page 3] + +RFC 97 Proposed Telnet Protocol February 1971 + + + character to indicate that the next character struck is to be + converted to the appropriate control character code. This latter + convention enables control codes directly generated at the terminal + to be recognized by the user's system thus enabling escape to the + user system. Creating a convention allowing all control codes to + enter the network and allowing output of the network to feed into the + server monitor before entering the server process, gives a simple + mechanism for generating an escape to many existing systems. + (The problem is more complicated than this for some systems and we + discuss it further below.) + + 3C We recommend that network standards be established for the + meaning of local echoes of HT, VT, and FF or a convention to be + established for sending the meaning of these characters to the server + process. The NLS(NIC), for example, needs to keep track of the + position of the print head and in the absence of such conventions + will convert these character codes to spaces and line feeds. This + means that the appearance of the page on output may differ from the + appearance on input. It would be helpful to the user if his page on + output could be formatted as it appeared on input. + + 3D LF characters would be handled as if they were generated by + hitting the line feed key on a terminal "directly" connected to the + server system. + + 3E The carriage return (CR) character can be the source of + considerable difficulty. For example, on input, different systems + and the same system at different times, can echo and transmit + different codes to the terminal and the user process. Some monitor + systems echo nothing, just a CR, or a CRLF. Some systems transmit a + CR, CRLF, or end of line code (EOL) to the user process. The user + process may control the echo or add to it. Given the combinations + which can exist at each end of the network connection and with + respect to each other, confusion can exist unless we assume the + definition of 2A and the implementation convention of 2E. These + assumptions imply that when a CR is struck, a CR gets sent over the + network. If the user monitor system or terminal control hardware + converts a CR to a CRLF or EOL, then the Telnet program must convert + it back to a CR. When the CR reaches the server monitor it will + handle it properly for the server process. + + When echoing is handled by the server system, the proper code or + codes will be echoed. The user Telnet on receiving a CRLF can pad it + with the proper nulls to handle carriage movement timing for a + particular terminal. + + When echoing is handled by the user system it would be ideal if + the user's Telnet or system used the same echo convention as the + + + +Melvin & Watson [Page 4] + +RFC 97 Proposed Telnet Protocol February 1971 + + + server system would. This means that either the Telnet must have a + table of echo conventions for the various systems to which it can + connect, or that it can obtain this information from the server + system or process, or vice versa. + + For an initial Telnet protocol this is probably not necessary. + The user system can default and echo a CRLF on each CR received. + This default should be satisfactory for all the situations we are + familiar with and for the NIC. + + 3F For communication from character- and line-at-a-time systems, + the Telnet process may need to recognize a character (user + assignable) which we call end of stream (EOS). This character is to + have the function defined in the following discussion. The important + point is to distinguish end-of-stream as a network function and end- + of-line as a user or server system function. Consider line-at-a-time + systems first. We have not had much experience with line-at-a-time + systems, so what follows will need further study and clarification. + As we understand it, line-at-a-time systems recognize a character + such as CR or a break signal as the code to wake up the user process + and cause transmission to it of the line of text. From the point of + view of NLS(NIC) it is important that the user be able to enter lines + of text each terminated by a CR where appropriate and at other times + to be able to enter text not terminated with a CR. (A statement for + NLS(NIC) is a string of text of "arbitrary" length and need not have + CRs in it; on output the line is folded for the user at his (user + definable) page boundary.) + + As an example of what is required, consider the case where the + user's system recognizes CR as end-of-line. In this case the Telnet + would be awakened when a CR is received. We would recommend that in + this case the CR code be literally entered into the Telnet output + buffer. If a CR is preceded by an EOS character, then the CR should + not be placed in the Telnet output buffer. Transmission through the + network can take place either when an EOS is received or + automatically when the Telnet output buffer fills. Transmission to + character-at-a-time systems from line-at-a-time systems could require + the awkward striking of three keys to get one character through the + network. + + Now consider transmission for a character-at-a-time system to a + server line-at-a-time system. A similar problem to the one to be + described also exists between line-at-a-time systems. Given the + definition of an EOS character different from CR, a line can be + buffered up until the EOS is received and then sent without the EOS. + How is the serving system to know that a line has been sent? One way + would be for the serving NCP to recognize message boundaries. This + convention would violate a design goal. Another way would be for the + + + +Melvin & Watson [Page 5] + +RFC 97 Proposed Telnet Protocol February 1971 + + + user Telnet to request its NCI to send an INS command. The sending + of INS type of control commands might introduce race conditions in + the network and should be investigated before their use with a Telnet + process is established. Since some of the line-at-a-time systems we + know have special hardware that recognizes the end-of-line signal, we + need some way to be compatible with this hardware using software + control signals. We leave this problem for further NWG subgroup + study. + + 3G We now come back to the problem of interrupting or escaping in + the remote server system. In systems which do not lock out the input + keyboard when output is going on, the mechanisms and conventions + outlined above would seem adequate unless a special break signal is + the escape signal. This latter case requires more study. In systems + which allow no input while output is occurring, one may have to live + with the consequences of such a terminal discipline and be prepared + to wait until output stops before an escape code can be sent. If the + keyboard is locked and an escape break signal can be sent to the + user's system, it can prevent output from going to the terminal, but + must be prepared to continue receiving it from the server site until + the user can inform his Telnet process to send an interrupt or escape + signal to the server site. Again this is a problem for further + study. + + The Online System of the Network Information Center operates on + a character-at-a-time monitor system and the conventions established + in this paper are adequate for access to it. These conventions are + summarized in Appendix A. + + + + + + + + + + + + + + + + + + + + + + + +Melvin & Watson [Page 6] + +RFC 97 Proposed Telnet Protocol February 1971 + + +APPENDIX A + + NETWORK CONNECTION PROTOCOL TO SRI-NETWORK INFORMATION CENTER + + 1 Initial Connection Protocol + + Connection establishment to NIC is identical to that presented in + Section II of NWG/RFC 80 NIC (5608,); it is reproduced here: + + Telnet contacts NIC + + NIC <- user site + + RTS

+ + NIC logger is socket 1 + + user site <- NIC + + STR CLS + + if accepted + + CLS + + if rejected + + assuming NIC accepts + + user site <- NIC + + STR + + RTS + + NIC receives text thru local socket ss from remote + socket us+l via link q + + assuming user site accepts + + NIC <- user site + + STR + + RTS + + NIC sends text to remote socket us thru local socket + ss+l via link r + + + +Melvin & Watson [Page 7] + +RFC 97 Proposed Telnet Protocol February 1971 + + + . + . + . + + user site <- NIC + + ALL + + . + . + . + + NIC <- user site + + ALL + + 2 Connection Breaking Protocol + + A CLS trade is made between the NCPs for each of the two + connections as per Document #1 NIC (5143,). + + We may decide to put a time-out into the NIC connections such + that no interaction for some (as yet unspecified) "reasonable" + length of time will result in a CLS-out of the connections being + initiated by NIC. + + 3 Third Level Protocol + + The first 8 bits received by NIC thru socket ss should be the + message data type designating that an 8-bit ASCII stream follows, as + per NWG/RFC #63, NIC (4963,). + + I.e., the first 8 bits are 00000001 + + The first 8 bits received by Telnet thru socket us will also + indicate a message data type of l. Each network message should have + an integral multiple of 8 bits. If a network standard is established + different from the suggestion of NWG/RFC #63, NIC (4963,), then we + would change this protocol to conform. + + NIC will have NCP-generated interrupts disabled, i.e., + + INR will be ignored + + INS will not be sent to the remote host + + + + + + +Melvin & Watson [Page 8] + +RFC 97 Proposed Telnet Protocol February 1971 + + + 4 NLS(NIC) Character Conventions of Interest to Telnet + + Echoing can either be under control of NIS(NIC) or under control + of the user site. When we refer to echoing below, we mean under + control of NLS(NIC). When echoing is handled by the user site we + would expect the user to set the NLS(NIC) output conventions to + conform to the echoing conventions at his site. NLS(NIC) assumes + echoing is handled by the user site unless explicitly commanded + otherwise. + + Format affecting control characters + + horizontal tab + + spaces to next (user definable) stop on both echoing + and output. + + if during literal input, enters file as ASCII '11. + + form feed + + carriage return and (user definable) appropriate number + of line feeds on echo and output. + + If during literal input, enters file as ASCII '14 + + vertical tab + + carriage return and (user definable) appropriate number + of line feeds on echo and output + + if during literal input, enters file as ASCII '13 + + carriage return + + carriage return followed by line feed on echo and + output + + if during literal input, enters file as EOL (see below) + + line feed + + line feed on echo and output + + enters file as ASCII '12 on literal input + + EOL (end of line) + + + + +Melvin & Watson [Page 9] + +RFC 97 Proposed Telnet Protocol February 1971 + + + presently ASCII code '37 + + carriage return followed by line feed on echo and + output + + if during literal input, enters file as ASCII '37 + + If the user's system automatically appends a LF to a CR + before sending it to Telnet or converts CR to some EOL code + not ASCII '37, we would expect Telnet to send NLS(NIC) just + a CR or ASCII '37. If we receive CRLF, then on output we + will send CRLFLF. + + 5 NLS(NIC) Interrupt Attention Convention + + A (user definable) ASCII code in the text input stream is used to + abort the executing process and return control to the main NLS(NIC) + command processor. + + This code is presently DEL (ASCII '177). + + Escape to the NIC monitor: No escape is required as all + operations needed for use of the NIC can be performed within + NLS(NIC). + + Character Set: We strongly recommend that the Telnet process + be able to generate by some set of keying conventions all 128 + ASCII codes. Use of NLS(NIC) will probably feel most comfortable + from a device with upper and lower case graphics, although we can + provide service to single case devices. We can provide a useful + service if the full ASCII set cannot be sent, but would like to + minimize the special cases we have to handle. Sites which cannot + provide the full ASCII set should contact us. + + +----+ | + | | Server | + | | Program | + | | | + +----+ | + ^ | | + | v | + +----+ Terminal | + | | control | + | | software | SERVER + | | and | SITE + +----+ possibly | + ^ | hardware | + | v | + + + +Melvin & Watson [Page 10] + +RFC 97 Proposed Telnet Protocol February 1971 + + + +----+ | + | | | + | | NCP | + | | | + +----+ | + ^ | | + | v | + + . . + . . Figure 1 - + . . + . . Telnet Connection + + ^ | + | v + +----+ | + | | | + | | NCP | + | | | + +----+ | + ^ | | + | v | + +----+ | + | | | + | | Telnet | + | | | + +----+ | + ^ | | USER + | v | SITE + +----+ Terminal | + | | control | + | | hardware- | + | | software | + +----+ | + ^ | | + | v | + +----+ | + | | User | + \ | terminal | + \--+ | + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Tony Hansen 08/08 ] + + + + + + + +Melvin & Watson [Page 11] + -- cgit v1.2.3