"Cini, Richard" <RCini_at_congressfinancial.com> wrote:
> Does anyone know if there is CR/LF translation across the telnet
> channel? For example, if I hit <ENTER> in the telnet client, does that
> produce <CR> or <CR><LF>? Is it dependent on the client settings? The simple
> Windows telnet client provides only VT52 and VT100 emulation.
This is one of those things that is poorly understood and apt to be
implemented incorrectly and/or differently by different people.
Telnet tries to provide a "network virtual terminal" abstraction, and
one of the bits of that abstraction is encoding a "newline" across the
Telnet connection. This was important way back when a terminal or
host might send CR, LF, CR LF, or some other character sequence to
indicate newline; and there was some thought being given to how to
make it so you could use any terminal+host as a network virtual
terminal to another host.
The Telnet RFC provides two encodings: CR NUL and CR LF. When I
worked on WIN/TCP for MPE/V I tried to make the Telnet server use CR
NUL to mean "return the carriage to the left margin" and CR LF to mean
"return the carriage to the left margin and advance to the next line"
(there were MPE FWRITE carriage-controls that needed to be mapped to
these). What I can't remember right now is whether that worked or
whether I later changed the server to send CR NUL LF in some cases to
appease clients that turned CR LF back into "return the carriage to
the left margin".
If a Telnet negotiates binary mode (sends IAC WILL BINARY and receives
IAC DO BINARY) then it is saying that it will send raw 8-bit data and
not do this NVT stuff.
And of course some Telnet clients just do whatever, so just send CR
when the user presses RETURN or ENTER. This is Wrong, but "be liberal
in what you accept", so what you need to do for the NVT (non-binary)
case is to run received data through a state machine: when you receive
CR you enter a state for the next character where a NUL or LF is
discarded but other characters are treated as received data.
-Frank McConnell
Received on Tue Jan 08 2002 - 13:32:41 GMT
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:34:53 BST