jas@MONK.PROTEON.COM (John A. Shriver) (07/21/87)
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
<CR><LF> newline go to first column of next line
<CR><NUL> carriage- go to first column of this line
return
<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
stream.
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
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 <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 softwareejnorman@uwmacc.UUCP (Eric Norman) (07/21/87)
John A. Shriver explains: > 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 What has always bothered me about RFC 854, et al. is that there is a clear statement of the physical effect that CR's and LF's have on the printer of a NVT. However, I can see no clear statement that the sequence CR-LF means "it's your turn now". This is muddied by the fact that there is a "go ahead" signal, but it's not necessary. I look at it this way, which seems to agree with what John suggests. I have a keyboard here that I push keys on. When I push a key, one or more characters are sent off to some computer over some wires. When I push the key labelled "return", something happens so that I get a response from the computer on the other end. If back-to-back NVT's are spliced into the wire between my keyboard and that computer, I would hope that that behavior doesn't change. Eric Norman Internet: ejnorman@unix2.macc.wisc.edu UUCP: ...{allegra,ihnp4,seismo}!uwvax!ejnorman Life: Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde "Forest fires prevent bears." -- bumper sticker --
pogran@CCQ.BBN.COM (Ken Pogran) (07/22/87)
John, Your elucidation of the handling of line-termination characters in TELNET is the best I've seen in a long time; congratulations! On the other hand, it's unfortunate that after so many years it still needs to be explained! TELNET's careful handling of the various line-termination possibilities is one of the "great compromises" of the relatively early days of the ARPANET (the bit-serial 1822 interface, accomodating computers with the bewildering array of word sizes found in late '60s - early '70s machines, being another). It arose through the efforts of the IBM EBCDIC-newline-physical- half-duplex, Multics LF-is-newline (from which UNIX got its idea of newline) and various DEC (and other) you-CR-and-I'll-echo-the-LF camps to develop something that would work for everyone and that was easily converted at each end of the connection. That different systems STILL have different conventions (UNIX vs VMS, for example) after all this time underscores the importance of the TELNET ASCII compromise -- as well as the importance of implementing it correctly. Thanks, John, for your explanation. Regards, Ken Pogran
wayne@ultra.UUCP (Wayne Hathaway) (07/23/87)
Apropos of not much more than "Nothing new under the sun," a small war
story about TELNET end-of-lines. Back about 15ish years ago I had the
dubious pleasure of trying to shoehorn an IBM system into the ARPANET
world. In particular, we used the IBM 2741, a half-duplex Selectric
typewriter ("Mother of the TELNET go-ahead"*). Among the 2741's
endearing qualities was that it had no <CR> key. It had "INDEX,"
which did a <LF>, and it had "RETURN," which did a combined <CR><LF>
(actually the EBCDIC "newline" character); the only way to output a
naked <CR> was to backspace all the way to the beginning of the line!
In actual operation, this caused no real problem, because of course my
user TELNET was smart enough to translate TELNET end-of-line
(<CR><LF>) into EBCDIC "newline," and naked <CR>s were pretty rare.
Except in one case: good old Multics (or at least one generation of
Multics TELNET), which for some unknown reason insisted on ending
every line with <CR><NUL><LF>. Decidedly nonconforming for sure, but
completely transparent to almost every other ARPANET host, so why
change? Anyway, whenever I logged into Multics from a 2741 I got the
following behavior:
typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
typey-typey-typey-typey-backspace-backspace-backspace-backspace-index
Ad nauseum. But the most interesting thing was that in spite of
everything taking more than twice as long (plus shaking everything off
the typing table), the output ended up being exactly correct! Amazing
what can pass for "interoperability" ...
Wayne Hathaway ultra!wayne@Ames.ARPA
Ultra Corporation
2140 Bering drive with a domain server:
San Jose, CA 95131 wayne@Ultra.COM
408-922-0100
* There was at least one other name for the 2741 that also started
with "Mother." Fun gadget ...