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
chracters

	newline		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