Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!dcatla!dnwcv From: dnwcv@dcatla.UUCP (William C. VerSteeg) Newsgroups: comp.protocols.tcp-ip Subject: Re: TELNET and 8-bit ascii codes Message-ID: <14414@dcatla.UUCP> Date: 20 Feb 89 16:32:20 GMT References: <8902161007.AA05006@indigo.stl.stc.co.uk> Reply-To: dnwcv@dcatla.UUCP (William C. VerSteeg) Organization: DCA Inc., Alpharetta, GA Lines: 27 One important thing to note about this discussion is its impact on user transparency. Ideally, a user wants to not know what underlying mechanism is used to connect him to his host. It should appear to be a direct cable link while in data transfer. Telnet, as implemented under many Un*x systems, causes problems in this respect. For instance, take a user who is using his PC as an ASCII terminal (YECH) and connecting to a number of hosts using a multiplexer that uses a number of protocols. This user is going to expect to be able to do file transfers over his async connection. If this user gets a real async hookup to his UN*X box, this works fine. If, however he happens to be sent to a Telnet session, this doesn't work. In the days when a user knew that his connection was going to be via Telnet, this may have been acceptable. But, in these days of heterogeneous networks, a non-technical user doesn't want to hear about the details of implementations. This is a call to end the days of "Well, UN*X is supposed to have these quirks. It is a programmers' environment." I think we need to re-think our attitudes and implement our systems with the non-technical end user in mind. The days of saying that UN*X bugs are part of the deal should be over. Lets face it, UN*X should not say that it will send 8 bit data when asked to do so, and then send 7 bit data. (NOTE- this is what SUN 3.5 does). Wishfully speaking Bill VerSteeg