John,
I don't think it would of been fun designing and testing a text-based
hosting protocol manually with your terminal/telecommunication/telnet
client "New Line Mode" (add LF to CR) option disabled or server text
responses only issue CR or LF.
It would of been very hard or confusing to do this stuff visually. :)
Most, if not all of our text based protocols borrow the same
ASCII/ANSI/VT100/TELNET framework and there are even considerations
for different terminators in the area of timeouts and also learning
via the initial handshakes.
--
HLS
On 8/30/2013 2:53 PM, John C Klensin wrote:
--On Friday, August 30, 2013 09:56 -0700 Bob Braden
<braden(_at_)isi(_dot_)edu> wrote:
CR LF was first adopted for the Telnet NVT (Network Virtual
Terminal). I think it was Jon
Postel's choice, and no one disagreed.
A tad more complicated, IIR. It turns out that, with some
systems interpreting LF as "same position next line" and some as
"first position, next line", some interpreting CR as "same
position, this line" and some as "first position next line", CR
LF was the only safe universal choice. At least one of those
four interpretations was a clear violation of the early versions
of the ASCII standard but the relevant vendor didn't care or was
too ignorant to notice. That particular bit of analysis was
known pre-ARPANET' I wouldn't be surprised to find it on some
earlier Teletype documentation.
I have no idea who make the decision for Telnet and friends, but
I wouldn't be at all surprised if it were Jon. The decision
was, however, pretty constrained.
Similarly, it was an important design constraint for FTP and
later for SMTP, WHIS, FINGer, and a bunch of other things that
they (the control connection for the form) be able to run over
Telnet connections (on a different port). I don't know whether
that was cause or effect wrt the CRLF choices for those
protocols, but it probably figured in. I've suspected whether
that was part of what drove the port mode in preference to some
fancy service-selection handshaking at the beginning of the
connection but I have no idea how that set of decisions were
made.
Then when FTP was
defined, it seemed most economical
to use the same. In fact, doesn't the FTP spec explicitly say
that the conventions on the control
connection should be those of Telnet?
Yep. RFC 959, Page 34 (snicker) and RFC 1123 Section 4.1.2.10.
There were even some discussions about the interactions between
Telnet option negotiation and FTP (Section 4.1.2.12 of RFC 1123
was, I think, intended to definitively settle those).
Later, when Jon defined
SMTP, I am sure that
Jon would not have dreamed of using different end-of-line
conventions in different protocols.
I would hope that you would not dream of it, either.
Indeed.
john