Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!sdcsvax!ucbvax!OPAL.BERKELEY.EDU!minshall From: minshall@OPAL.BERKELEY.EDU Newsgroups: comp.protocols.tcp-ip Subject: Telnet, , etc. Message-ID: <8707311950.AA12026@opal.berkeley.edu> Date: Fri, 31-Jul-87 15:49:58 EDT Article-I.D.: opal.8707311950.AA12026 Posted: Fri Jul 31 15:49:58 1987 Date-Received: Sun, 2-Aug-87 04:28:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 129 (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 , 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 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 verse! Alas.). But, honest to god, it isn't in the spec. The spec talks a lot about what , , 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 be inserted following a not followed by a in the data stream." (And, yes, the 4.3 implementations do that.) So, I do not believe that 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 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 . If local echoing is going on, and the user types '\r', we ECHO '\r\n', and send . NOTE: I think that 4.3 telnet (and I know that 4.3 telnetd) is broken in binary mode, sending when it should send just . 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 , we send '\r' towards the application program. When we receive , we send '\n' towards the application program. What do we do when we receive ? 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 , 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 . If the client side has no way of sending , 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 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 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 -> '\n' or '\r' is a Unix discussion). Or, to a general discussion of "when should a client send , when should it send , when should it send ?" (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 , we sometimes send , and we sometimes send by itself. In server mode, we always pad a standalone with a ; in server mode, we map incoming to '\r', incoming to '\n', and 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). Greg Minshall ps - Dan Hoey feels it is laughable that "if the is split across whatever buffer boundary telnetd is using, the code turns it into instead of ". 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 when the user types carriage return. pps - 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].