[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

Tweet
This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC559
Ad

UNKNOWN
Network Working Group                                 Abhay K. Bushan
Request For Comments #559                             MIT Project MAC
NIC # 18482                                           August 15, 1973
Comments on the new TELNET Protocol and its Implementation


We at MIT-DN have implemented the new TELNET protocol (both server
and user). This RFC describes our experience with the implementation (particularly the use of GO AHEAD) and in bringing the new User and Server TELNET's in operation (the new TELNET is not compatible with the old). We have a few suggestions here which should help other implementors and lead to a smoother transition to the new protocol.
I. OUR TELNET SERVER IMPLEMENTATION
Our new server TELNET accepts both the "old" and the "new" TELNET
"control sequences". Currently we have the ECHO and the "Suppress Go Ahead" options implemented and do the "right thing" to varying degrees with the Interrupt Process (IP), Erase Character (EC), Abort Output (AO), Are You There (AYT), Break, and Synch character sequences.

A. The ECHO Option

The TELNET server comes up in the default local echo mode and
accepts both the old and the new TELNET control sequences. The server starts the negotiation for remote echo (server echoing) by sending the sequence "IAC WILL ECHO" but changes the echo mode only when an affirmative "IAC DO ECHO" is received. After the cutoff date for old protocol we will stop "honoring" the old TELNET control sequences.

B. The Go Ahead and Suppress GA option

The server comes up in the send GA mode and transmits the required
"IAC GA" sequence whenever the server detects that it needs to send a GA. It should be noted that our scheme for sending GA's works most but not all of the time.

There is really no reliable way for our server TELNET to find out
when a process is actually waiting for network input. On our system, the server TELNET does not "control" user's process, it only acts as a terminal handler at the TTY level.
Bushan                                                          [Page 1]

RFC 559                    Comments on TELNET                August 1973
A quick investigation revealed that the above problem (of sending
GA's reliably) is not confined to the ITS operating system alone. In fact TENEX (ref. conversation with Ray Tomlinson) and DEC-10 (ref. conversation with Ed Taft at Harvard) systems will encounter similar problems.

Our solution to the GA sending problem was to have the server wait
2.5 seconds after sending output to see if there is more output to be
sent. If the server has been "idle" for more than 2.5 seconds in the "output-sent" state it sends a GA and goes in an I/O wait state (looking for input or output). This scheme works most (but not guaranteed all) of the time and doesn't cause any noticeable delay. It is possible for the server to send an extra GA. Our experimentation revealed that 1-5 seconds was a good range for this "idling time constant".

We do implement the "suppress GA" option and will not send GA to
hosts who agree to negotiate out of it. Our server tries to negotiate these suppress GA option.

C. Other Options and TELNET Control Sequences

Our server will refuse all other options by sending the appropriate
DONTs and WONTs. In addition to the ECHO and Suppress GA options we recognize the following TELNET "control sequences".
1. Interrupt Process (IP) - The server substitutes the system wide
interrupt character <control-Z> (ACII SUB) which immediately interrupts the process, moving control to the immediately superior process. If the user is several levels down his process tree he may have to send several IP's to reach top level. It should be noted that the IP does not interrupt the running process in the sense a <control-G> interrupts muddle but only passes control to the superior.
2. Erase Character (EC) - The server substitutes the system wide
standard erase character <rubout> (ACII DEL). The deletion however is done not by the server but by the receiving process. It is conceivable that some process (such as a user TELNET) take no action on receiving EC. Most processes will echo the deleted character(s). Several EC's will delete the several previous characters. (If the console is declared to be an IMLAC, the deleted character is removed from the screen).
3. Abort Output (AO) - The server substitutes the character <control-S>
(ACII DC3). The control-S convention is followed by many but not all of our programs. The action taken on receiving AO varies with the program. A normal occurrence is that output and the current command are aborted (without necessarily going to completion). In many programs there is no way to stop output except by sending an IP and "killing" the inferior process.
Bushan                                                          [Page 2]

RFC 559                    Comments on TELNET                August 1973

4. Are You There (AYT) - The server will print the message
"****connections still open*****" preceded and followed by CRLF's upon receiving an AYT. At some later time we may report on the state of the user's job as well.
5. Erase Line (EL) - since we are a character-at-a-time system, the EL
has little meaning on our system and we throw it (and the preceding IAC) away.
6. Break (BRK) - We substitute three NUL's upon receiving BRK.  This
convention is consistent with what happens when the "Break" key is hit on local teletypes. The programs generally do nothing useful when break is received (except echo "|@|@|@") but sending BRK may cause strange program reactions, so beware.
7. Synch - Whenever the server receives the synch INS, it flushes all
except the interesting (control sequences) characters till the receipt of a DM. We also cause an implicit IP on receipt of SYNCH.
8. We follow the CRLF and CRNUL convention for transmitting EOL and CR
respectively.

II. OUR USER-TELNET IMPLEMENTATION

The new user-TELNET (implemented in CALICO NETWORK by using a new
"TELCOM" subroutine), accepts negotiation for the ECHO and suppress GA options. The program tries to negotiate out of receiving GA's and tries the ECHO negotiation if the settings file for the host indicate remote echo. Special characters and symbols are defined for EC, EL, AO, AYT, BRK, SYNCH, IP, and the ESCAPE character to command level. These symbols have a default character value which the user can change by typing the symbol followed by the new character value at NETWRK command level. To send EC, EL, etc, the user only has to type the special character for the function. In addition the user can send these characters by using the send.special command at NETWRK command level. In "line mode", EC and EL do a "local" character and line erase rather than send the EC and EL to the remote host. The following are the default values for the "special" characters in TELNET :

ESCAPE - backslash EC - <DEL> EL - <CAN> or |X AO - |S IP - |R AYT - |T Synch - |Y Break - no preassigned value.
Bushan                                                          [Page 3]

RFC 559                    Comments on TELNET                August 1973
The user can change his echo mode by escaping to NETWRK command level and using the commands "echo.local" or "echo.remote". Note that the modes are changed only when the negotiation for mode change is successful. In either event the user is notified of the results of the negotiation.

III. INSTALLING THE NEW TELNETS

On Monday July 2, we brought up the user and server TELNETs briefly to find that most of the hosts did not "recognize" IAC's and did not honor the new protocol. Much to our dismay usage of both our server and user TELNET's was chaotic. Consequently, we did not install the new user and server TELNETs, and the old TELNETs remain operational.

The new and the old TELNETs are definitely not compatible. The
server tries to (and should try to) negotiate out of sending GA's and also to send echo. This negotiation causes problems with the "old-style" user TELNETs. Also if the negotiation for Suppress GA is unsuccessfully (which is the case with "old" user-TELNETs) the server will keep sending IAC GA's when appropriate. One solution we found to making our "new" server compatible with "old" user TELNETs was to come up in a mode that does not start any option negotiation and does not send GA's unless requested to do so (ie default is to suppress GA"s). As mentioned earlier the server also accepts the old "TELNET control" sequences. This solution makes the server compatible with both the old and the new user TELNETs (except it violates protocol by not sending GA's). We propose to install this server on our socket 1.

To promote experimentation with the new TELNET protocol, we have
installed the new server TELNET on socket 60 (octal 105). This new server follows the new protocol (ie it sends GA's) and starts spontaneous negotiation for remote echo and suppress GA. The implementors on other Hosts are encouraged to use this service to debug their user TELNETs (and our server). We feel that transition to the new protocol will be smoother if new TELNET servers are brought up on experimental sockets. We are also willing to help debug other servers from our User TELNET.

Finally we would like to lobby for making suppress GA the default
(as our present server on socket 1). It appears that only a few Hosts require the GA's (AMES-67 and UCLA-CON). It seems to me that the reason why sending GA is default in the current specification of protocol is that representatives from the concerned Hosts wanted the GA to be implemented. It doesn't matter to them if sending GA or suppress GA is default, as long as they can get a remote server to send a GA. The protocol can be so specified as to require every one to implement a "send GA option". Making "suppress GA" the default will have the advantage that it will obviate unnecessary negotiation in a great majority of cases. Another advantage is that not sending GA's makes the new server compatible with both old and new user TELNETs.
Bushan                                                          [Page 4]

RFC 559                    Comments on TELNET                August 1973
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Serge Hallyn 9/97 ]








































Bushan [Page 5]

Ad
Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.
inserted by FC2 system