Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!sdcsvax!ucbvax!MONK.PROTEON.COM!jas From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Berkeley (not Wollongong) telnet and new line processing Message-ID: <8707202321.AA19800@monk.proteon.com> Date: Mon, 20-Jul-87 19:21:51 EDT Article-I.D.: monk.8707202321.AA19800 Posted: Mon Jul 20 19:21:51 1987 Date-Received: Wed, 22-Jul-87 02:13:09 EDT References: <25@abvax.icd.ab.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 73 That one is completely Berkeley's fault! The explanation of new line processing is presented with excruciating clarity on pages 11-12 of RFC 854, "Telnet". For reasons unknown to god or man, instead of fixing new line processing between 4.2BSD and 4.3BSD, it got broken worse. (I hope the reason was ignorance, not independence!) There are three "characters" which the Telnet Network Virtual Terminal can encode: netascii function what it means chractersnewline go to first column of next line carriage- go to first column of this line return line-feed go to same column in next line Note that most systems only conceive of two of these, since there are only two keys on the keyboard. In user Telnet, you should send when the user types whatever the "doit!" key is on that system. On a VMS system, that would be when the user types . On a UNIX system with "stty -nl", that would be when the user types , although the input stream may have returned ('\n'), depending on how raw the terminal is. On a UNIX system in "stty nl" state (native Teletype model 37), the gets sent when is typed. For the VMS and UNIX "stty -nl" cases, when the user types , you send . Note that there is no simple way for that user to send . In the UNIX "stty nl" case, when the user typed , then you would send . Now for server Telnet. On the VMS system, the server should type when it sees from Telnet. It should also do so when it sees . (To be gracious of goofs like 4.2BSD, it should also accept naked .) Presuming that a UNIX server Telnet would probably always have the psuedo-tty in "stty -nl" mode, it would behave the same. Both of these systems would type when they saw on the Telnet stream. Similar conventions apply to output operations. On UNIX, printf("\n") should send , and printf("\r") should send . On VMS, you just take the VT100 terminal stream, and stuff a after any naked . (VMS allows naked or from an application program.) The user telnet has to sort out the incoming netascii and do the right thing to the terminal. (If the terminal doesn't mind a few s, you can probably send straight netascii.) As always, follow the robustness principle (p.13 RFC 793, "TCP"): be conservative in what you do, be liberal in what you accept from others In Telnet, this poses several corollaries: 1. Generate only legal netascii on a Telnet stream 2. The noraml netascii sequence should be 3. Accept all three netascii sequences on input from Telnet streams 4. Accept degenerate netascii ( not folloed by or ) to cope with broken software