Berkeley (not Wollongong) telnet and new line processing

John A. Shriver (
Mon, 20 Jul 87 19:21:51 EDT

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

<CR><LF> newline go to first column of next line

<CR><NUL> carriage- go to first column of this line

<LF> 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 <CR><LF> when the user types whatever
the "doit!" key is on that system. On a VMS system, that would be
when the user types <CR>. On a UNIX system with "stty -nl", that
would be when the user types <CR>, although the input stream may have
returned <LF> ('\n'), depending on how raw the terminal is. On a UNIX
system in "stty nl" state (native Teletype model 37), the <CR><LF>
gets sent when <LF> is typed.

For the VMS and UNIX "stty -nl" cases, when the user types <LF>, you
send <LF>. Note that there is no simple way for that user to send
<CR><NUL>. In the UNIX "stty nl" case, when the user typed <CR>, then
you would send <CR><NUL>.

Now for server Telnet. On the VMS system, the server should type <CR>
when it sees <CR><LF> from Telnet. It should also do so when it sees
<CR><NUL>. (To be gracious of goofs like 4.2BSD, it should also
accept naked <CR>.) 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 <NL> when they saw <NL> on the Telnet

Similar conventions apply to output operations. On UNIX, printf("\n")
should send <CR><LF>, and printf("\r") should send <CR><NUL>. On VMS,
you just take the VT100 terminal stream, and stuff a <NUL> after any
naked <CR>. (VMS allows naked <CR> or <LF> from an application

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 <NUL>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 <CR><LF>

3. Accept all three netascii sequences on input from Telnet streams

4. Accept degenerate netascii (<CR> not folloed by <NUL> or <LF>) to
cope with broken software

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:47 GMT