Fri, 31 Jul 87 12:49:58 PDT
(LONG MESSAGE - print and read at your leisure.)
I have the pleasure of being the gongfermer (aka nightman) for
4.3 telnet and telnetd. One of my joys is replying to the recent
discussion of same. Another of my joys is admitting that everything
wrong with 4.3 telnet and telnetd is my fault.
William R. King started out the discussion asserting that
4.3 telnet was sending \n when the user typed carriage return. Dave Borman,
from Cray, (who, by the way, spent a LOT of time helping to improve 4.3
telnet/d over the 4.2 versions) suggested that this was unlikely to
be the case. This is, indeed, unlikely to be the case.
The "problem", as Steve Alexander (and various others in both
the public discussion, and in private comments) has mentioned, is that
the 4.3 telnetd (the server telnet), on receiving a TELNET <CR><LF>, sends
in a \n towards the application program.
Now, Mr. John Shriver (jas) has a bit of a flame. I, personally,
don't agree with the emotion of his flame, but I'm willing to talk
about the philosophy. If I seem to be a bit derisive, please bear
with me (this is a very sore subject).
Jas states "In user Telnet, you should send <CR><LF> when the
user types the 'doit!' key." Now, I would very much like to see
a reference in the RFC (854) to that effect; I won't, though. I've
looked many times. Jas, of course, is not the only person who
believes this to be the case. I don't know jas, but I know and trust
Bob Braden at ISI, and he is as emphatic as jas is about this. Ken
Pogran also agrees. So does Stephen Casner (and he quotes chapter and
But, honest to god, it isn't in the spec. The spec talks a lot
about what <CR><LF>, <LF>, <CR><NUL> will do to the printer head. The spec
does say: "Even though it may be known in some situations (e.g., with
remote echo and suppress go ahead options in effect) that characters are
not being sent to an actual printer, nonetheless, for the sake of
consistency, the protocol requires that a <NUL> be inserted following a
<CR> not followed by a <LF> in the data stream." (And, yes, the 4.3
implementations do that.)
So, I do not believe that <CR><LF> is NECESSARILY what should be
sent when the user hits the "Enter", "Return", whatever, key.
What I DO believe is that the group of people who believe <CR><LF>
is the way to go are relying on, in many cases, their participation in
"let's define and bring up TELNET" meetings, projects, etc., back when
"everything" was starting. I really wish these people, all of whom have
much more experience than I in this business, would realize this point.
So, how does 4.3 telnet (the client side) work? If remote echoing
is going on, and the user types '\r', we send <CR><NUL>. If local echoing
is going on, and the user types '\r', we ECHO '\r\n', and send <CR><LF>.
NOTE: I think that 4.3 telnet (and I know that 4.3 telnetd)
is broken in binary mode, sending <CR><NUL> when it
should send just <CR>. Null stuffing isn't valid
in binary mode.
That is how 4.3 telnet works.
Now, we slip over to 4.3 telnetd (the server).
Again, the 4.3 server conforms to the protocol (not out of
ignorance, not out of independence, but out of thought and some
consultation). When we receive <CR><NUL>, we send '\r' towards
the application program. When we receive <LF>, we send '\n' towards
the application program. What do we do when we receive <CR><LF>?
Well, what should we do? Clearly the user has typed something. What
they are sending is an "end of line function" sequence (cf the note
from Merton Campbell Crockett to this list); they are signalling
"newline" if you will (and we would). The Unix "newline" character
is '\n' (NOT '\r'). If the 4.3 server receives a <CR><LF>, we send
a '\n' (newline) towards the application program.
This is a problem if the user on the client side has no way
of sending <CR><NUL>. If the client side has no way of sending
<CR><NUL>, then the application program is not going to see what
it would have seen had a '\r' been sent its way (if it could have
noticed a difference; most Unix applications would not notice the
difference [but some do]).
We could, it is true, have mapped the <CR><LF> to '\r'.
That would also have been within the spec. It would violate,
somewhat, the philosophy of Unix (that '\n', not '\r', is the newline
character). If would also mean that anyone unfortunate enough to be
connecting from a client unwilling to send a <LF> alone would face
a problem getting a '\n' send towards their program.
I hope I haven't offended anyone overly. I AM pissed off (and
what's wrong with being pissed off?).
I hope that we can move from "Berkeley is violating the
protocol" (which, except in the case of binary mode mentioned above,
we aren't), to a Unix discussion of "how best could it work interface
to Unix" (since I believe that the discussion of <CR><LF> -> '\n' or
'\r' is a Unix discussion). Or, to a general discussion of "when
should a client send <CR><LF>, when should it send <CR><NUL>, when
should it send <LF>?" (recently there was some talk about defining
line and character mode; there may be some interaction here).
In summary: In client mode, we sometimes send <CR><LF>,
we sometimes send <CR><NUL>, and we sometimes
send <LF> by itself. In server mode, we
always pad a standalone <CR> with a <NUL>; in server
mode, we map incoming <CR><NUL> to '\r', incoming
<CR><LF> to '\n', and <LF> to '\n'. None of these
actions violate the letter (or, to my mind, the spirit)
of the RFC (or the Boland amendment, for that matter).
Dan Hoey feels it is laughable that "if the <CR><LF> is split
across whatever buffer boundary telnetd is using, the code turns it
into <CR> instead of <LF>". This is not laughable, but IS
embarassing. The intent of this was to continue to support brain-damaged
4.2 implementations, which (as has been noted time-after-time) send
<CR> when the user types carriage return.
Those of you who are accepting of this missive may believe I come from
any part of Berkeley you want; however, for the benefit of those who
would use this letter to criticize the "Berkeley clique", I feel you
should know that I have nothing whatsoever to do with the Computer
Systems Research Group [home of Berkeley Unix].
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:48 GMT