Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!rutgers!ames!ucbcad!ucbvax!PANDA.COM!MRC From: MRC@PANDA.COM (Mark Crispin) Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet, , etc. Message-ID: <12323076988.8.MRC@PANDA> Date: Sat, 1-Aug-87 15:23:39 EDT Article-I.D.: PANDA.12323076988.8.MRC Posted: Sat Aug 1 15:23:39 1987 Date-Received: Sun, 2-Aug-87 10:04:52 EDT References: <8707311950.AA12026@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 47 Greg Minshall - The last time I used a hardwired terminal connected to a Unix system, I found that the RETURN key on the terminal's keyboard would cause the Unix system to believe that it had received a newline. While it is possible that the terminal had been modified so that the RETURN key sent a linefeed, there was a separate LINE FEED key. I forget whether or not I tried using the LINE FEED key as an alternative newline. What your Telnet implement has, in effect, done is eliminate transparency. Most implementors of Telnet programs across the network have been very careful to make sure that transparency is preserved, since the ARPANET was traditionally a heterogenous network. Now, it may be true that today's Internet is a mostly homogenous Unix network, but there are still some non-Unix boxes out there. I cannot help but get the impression from the tone of your message that you have no real justification for your implementation's behavior other than a possible interpretation of admittedly ambiguous standards. You haven't offered any operational explanation as to why your implementation must behave in the way it does. Is there something particularly special about 4.3 that demands this behavior that other versions of Unix did not have? Please don't get me wrong; I have been a frequent critic of the explanations in the Telnet standards as they are presently reflected in the RFC's. I have periodically pontificated about various finer operational details that are glossed over in the standards or are inadequately explained; during a recent TCP/IP conference I had a presentation on these details (I'm also supposed to write an article about this for Connexions...). We're not out to criticize you or make your life difficult. Your mistake is only one of many that have come up in various Telnet implementations over the years. Please accept our judgement not as a criticism of your basically fine work, but rather as a source of information on what you must do to get your implementation interoperating correctly with the rest of the network. We all have a shared interest in maximizing interoperability, and the folklore we have developed over the years is based on long, hard experience and much compromise. Thank you. -- Mark -- -------