phil@uxg.cso.uiuc.edu (02/16/89)
I have the following situation:
- A host that REQUIRES use of the TELNET IP (Interrupt Process) and
TELNET AO (Abort Output) commands (prefixed by IAC) in order to
properly conduct a terminal session. Without the ability to send
these commands to that host's TELNET server, it is impossible to
escape for runaway execution or runaway output.
- A terminal server that provides no configurable way to transmit
either the TELNET IP or TELNET AO commands.
Clearly, these two are not going to work well together. Conceivably,
a modification to either of these could correct the problem.
Are the TELNET IP and AO commands a requirement? Is it valid TELNET to
require use of them? Which of the above two would it be more appropriate
to make modifications to?
A change to the host increases the level of compatibility and workability
whereas a change to the terminal server increases the flexibility and
functionality. I am asking the above questions to get a better insight
on what the TELNET protocol expects of its implementations.
--philhedrick@geneva.rutgers.edu (Charles Hedrick) (02/17/89)
I would demand that *both* vendors change. IP and AO are part of the standard. They're not a part I am enthusiastic about, but they should be implemented. On the other hand, something should also be done by the host implementation to let it work with telnet's that don't implement IP and AO. TELNET BREAK should both stop the process and abort output. Either that, or you should emulate the multiple types of break by saying that the first break stops output, and if you do a second break witin 1/2 sec of the first, it aborts output, or some hack like that. An IBM implementation that ignores break is crazy. However I believe they should even try to coexist with systems that can't do any of the telnet special commands, and thus they should pick two control characters to do IP and AO on the host end.
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (02/17/89)
> ... TELNET BREAK should both stop the process and abort output. Either > that, or you should emulate the multiple types of break by saying that > the first break stops output, and if you do a second break witin 1/2 sec > of the first, it aborts output, or some hack like that. ... Charles: When was the new RFC published that changed the TELNET definition for BRK? RFC 854 indicates that the TELNET BRK has no meaning except to those systems that implement support for a BREAK key. In those systems, its function is to perform the same function that it would perform when the BREAK key is pressed at a local terminal. The RFC explicitly states that BRK is not a substitute for IP and/or AO. Merton
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (02/17/89)
Phil: RFC 854 which defines the TELNET Protocol defines both IP and AO as required commands. A User TELNET which does not provide the capability to generate an IP or AO command has not been implemented correctly. In your case, the User TELNET is the one that needs to be fixed. To fully support the AO command, the TELNET "synch" function needs to be implemented. The "synch" function is required to indicate to the User TELNET when it can stop discarding data received from the Server TELNET. Merton
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (02/19/89)
The design intent of Telnet IP and AO (about which it happens I can speak with complete confidence) was certainly that USER Telnets must have the ability to convey the user's desire to invoke the respective functions to Server Telnets. (Explicit note was taken that not all Servers offer AO, and that we weren't demanding more of them than they would offer in their native states. This also applied to not expecting the output to stop immediately, since some systems would have no way of getting at data already in the "lowest" output buffers. For that matter, I expect the same principle ought to apply to the issue of whether User Telnets need to get into the act at all on stanching the flow, but let that ride.) Therefore, the onus in the case you cite should be on the User Telnet to give the user a way to cause the Generic Function Codes in question to be sent to the Server. Nor should the corresponding onus on ALL Servers to recognize the GFCs be overlooked, by the way-- for, at any rate, each of the Generic Functions they have specific native versions of (i.e., let's not forget Erase, Kill, and Are You There either). Of course, User Telnets are traditionally deficient; that it's traditional doesn't make it right, however: As it says in The Book, the first time I (and Multics) ever was approached by a User Telnet, it couldn't even send lower-case--which Multics needed (and I wanted)--and nearly 18 years (by now) haven't dimmed the indignation (much, anyway). cheers, map -------