Discussion of Telnet Protocol(5)

　　Since the TELNET server at the serving site is at the mercy of the　NCP with respect to controlling the bunching, and therefor,　arrival at the TELNET of bursts of characters, TELNET　implementations might be expected to choke off flow to the buffers　until they are ready to accept characters without throwing them　away.

　　Under this condition, the serving process might be outputting to the　using terminal, the input buffers fill up, and a control C get stuck　in the data stream that has been choked off.

　　A similar problem could occur with the Multics or some IBM system as　a server. The user at a using site gets into an output loop at the　serving site and wants to break the process without having to release　his TELNET connection. The buffers clog the connection, transmission　is choked off, and the control C break, or other user control signal　gets stuck in the pipeline.

　　_Example - Solution_

　　The user at the using site knows he is entering a special control　signal (break, ATTN, control C, etc.) and follows it with an X'80'.

　　(The local instructions at using sites for accomplishing this may　differ from site to site.)

　　Using Site TELNET to Serving Site

        Insert X'80' in Data Stream

　　Using Site TELNET to Using Site NCP

　　Send an INS

　　Sending Site NCP to TELNET Server

　　Look out, here she come

　　Serving Site TELNET

　　Does its special thing until it sees X'80' then resumes　normal handling

　　Thus, depending on the server's local implementation to provide　adequate service, a special handling of the data stream can be　invoked whenever an INS is received in order to get the special　character. When it sees X'80', it recognizes it as a SYNC character　and knowing that the special character has been passed on, strips the　X'80' from the data stream and returns to normal mode.

　　If the X'80' arrives before the INS, a counting scheme can keep the　activity appropriate to the serving site conditions.

　　This approach to handling selected special characters or signals　relieves the using TELNET processes from having to recognize the　special serving site characters, as well as from having to know how　the serving site wants to handle them. At the same time, the　procedure requires only a minimum level of user understanding of the　serving site. This seems appropriate, since the TELNET ASCII　conventions are providing a Network Virtual Terminal, not a Network

　　Virtual User.

　　The ability of the user to cause the using site TELNET to send any　combination of ASCII characters in a string, and only that　combination, is viewed as important to the user utility of the TELNET　ASCII conventions. Because of this, some user sites may find it　necessary to provide special local TELNET control signalling from the　user to the using site.

　　_Examples_

　　A user on a line at a time system (Multics, System 360, GECOS,　etc.) is working through the Network on a serving site that　operates a character at a time. The application is a debugging　aid that permits the user to type in a memory location = to which　it will respond with n where n represents the current contents of　that location. The serving site process does not expect to see　the location = followed by a carriage return line feed sequence.

　　The user at the using site should be able to type in the location,　follow it with a signal to suppress the end of a line convention,　followed by a new line or return, and expect the location number =　to be transmitted immediately without an end of line sequence.

　　In another case, a using site has decided that it is convenient to　accumulate four characters at a time and transmit them to the　serving site, unless an end of line is observed, in which case the　end of line sequence is sent preceded by whatever number of　characters have been accumulated, (presumably three or less). In　the same debugging application, the address is such that the end　does not correspond with the four character buffer demarcation.

　　The user should have the ability to enter a code for "transmit　immediately" in place of the Carriage Return in order to preserve　neat formatting, and expect the address to be sent to the serving　site.

　　TELNET controls have been discussed and those introduced to date　are probably sufficient for an early implementation of TELNET　ASCII convention. There will be a need to establish a mechanism　for the controlled assignment (on request by Network Sites), and　announcement of DATA TYPE and CONTROL codes.