--On Friday, August 30, 2013 09:56 -0700 Bob Braden <braden@xxxxxxx> 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