Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!VENERA.ISI.EDU!CASNER From: CASNER@VENERA.ISI.EDU (Stephen Casner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <555127536.0.CASNER@VENERA.ISI.EDU> Date: Tue, 4-Aug-87 22:05:36 EDT Article-I.D.: VENERA.555127536.0.CASNER Posted: Tue Aug 4 22:05:36 1987 Date-Received: Fri, 7-Aug-87 01:18:19 EDT References: <8707311950.AA12026@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 95 (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 contexts. 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 maximizing interoperability". 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 alone? 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 -------