Stephen Casner (CASNER@venera.isi.edu)
Tue 4 Aug 87 19:05:36-PDT
(Another LONG MESSAGE)
Greg Minshall -
You are correct, the Telnet spec does NOT make it clear whether the
client program should send CR-LF or CR-NUL when the user hits the
"return" key. The discussion is clear for characters flowing in the
opposite direction to the NVT printer, and we are left to infer a choice
for the NVT keyboard to server direction from statements about symmetry.
The following sentence is the one that I think causes trouble; you have
undoubtedly read it before, but I'll quote it here for discussion:
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is intended;
the sequence "CR NUL" must be used where a carriage return alone is
actually desired; and the CR character must be avoided in other
What is intended when the user hits the "return" or "enter" key? Those
who believe the return key means the user is finished with the current
line and wants a new line might quote the first part of the sentence to
show that CR-LF "must be ... used". Those who believe that carriage
return alone is desired, because on many (most?) terminals the "return"
key generates a single CR character, might quote the second part of the
sentence to show that CR-NUL "must be used".
NEITHER group can "prove" its case from the spec, but this is not a
legal contest. As Mark Crispin says, "we all have a shared interest in
I believe the Telnet spec should say exactly which of these two choices
should be used, just to avoid the present confusion of interpretation.
In any case, by the "robustness principle", EITHER sequence (CR-LF or
CR-NUL) should be accepted by the Telnet server to mean that the
"return" / "enter" key was pushed because we know there are some systems
that send one and some systems that send the other.
So, for the moment at least, my complaint was and is not that the 4.3BSD
telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF
to '\n' instead of '\r'.
You say that you could have mapped CR-LF to '\r', but that it would have
violated the philosophy of Unix that '\n' is the newline character. I
disagree, because the philosophy of Unix does not require that terminals
send '\n' to the tty driver; instead the tty driver receives '\r' from
the terminal and maps it to '\n' WHEN APPROPRIATE. Since telnetd does
not feed the application program directly, but rather feeds a pty, I
claim telnetd should map CR-LF to '\r' and let the pty driver map to
'\n' when appropriate. This is the same argument that Kevin Carosso
wrote. This change was also posted to comp.bugs.4bsd on 29-Jan-87 by
J. Robert Ward.
You gave a second reason that anyone unfortunate enough to be connecting
from a client unwilling to send a LF alone would face a problem getting
a '\n' sent towards their program. Again I disagree, because the pty
will map '\r' to '\n' for those programs that don't distinguish between
the two characters and expect only '\n'. To fully utilize a program
that uses cbreak or raw mode and does distinguish between '\r' and '\n',
the telnet client must be able to send two distinct codes: CR-LF or
CR-NUL when the "return" key is pushed, and LF alone when the "linefeed"
key is pushed. Some keyboards don't have "linefeed", but they probably
do have "control" and "J" keys. Is there any client that won't send LF
There are many clients that don't provide any mechanism to send CR-NUL
instead of CR-LF. They are NOT violating the spec either! Dave Borman,
Kevin Carosso and Dan Hoey suggest the Bridge box may be in error
because it doesn't or can't send CR-NUL. While it might be more robust
to have an option to send either CR-LF or CR-NUL, it's certainly not a
bug to send CR-LF. As you point out, many of the old hands in the
Telnet business, participants in the "let's define and bring up TELNET
meetings", believe CR-LF to be the correct choice over CR-NUL.
Bob Braden refreshed my memory that at the "TCP Bakeoffs" when the first
implementations of TCP/TELNET were being tested against each other, only
Charles Lynn's TENEX implementation sent CR-NUL and everyone else sent
CR-LF. It was subsequently agreed that CR-LF was the correct choice,
but obviously that choice wasn't clearly stated in the spec. BSD Unix
chooses CR-NUL and that causes trouble for some of the older server
implementations (cf John G. Ata's message). My personal choice would be
for BSD Unix to change to send CR-LF, but I recognize that this would
cause trouble when connecting to telnetd's that map CR-LF to '\n'.
Perhaps it would be wise to enhance the BSD telnet program so the user
can select whether CR-LF or CR-NUL will be sent. Our goal should be to
clarify this issue in the spec so that eventually all machines can
interoperate naturally without the need for such inconveniences.
You have stated your case well for the choices made in the 4.3 BSD
implementation. But given the additional information put forth by
several people since then, do you still believe telnetd should map CR-LF
to '\n' and not to '\r'? What will 4.4 BSD do?
-- Steve Casner
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:48 GMT