Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucbvax!AI.AI.MIT.EDU!JBVB From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Telnet binary mode Message-ID: <216009.870618.JBVB@AI.AI.MIT.EDU> Date: Thu, 18-Jun-87 02:14:46 EDT Article-I.D.: AI.216009.870618.JBVB Posted: Thu Jun 18 02:14:46 1987 Date-Received: Sat, 20-Jun-87 01:03:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 101 Mark: There is obviously some history I am not familiar with here. I look at the Telnet specification, and I see a perfectly good 8-bit transport. I see global definitions for slightly more than half of the possible characters. I see a 'binary' option defined as 'escape to mutually agreed-upon 8-bit datastream'. I know of one fairly well-defined use of 'binary' (TN3270, with 5 different server implementations and 6 or 7 clients). You indicate there are other uses, but I have no details. You cite your TOPS-20 implementations as examples of a manually-controllable 'binary' option. My interest in this is to improve the real-world usability of the Telnet protocol, and I realize I am proposing a change. I respect the interest of the authors of the original documents (I was referring to them last night, although I admit I hadn't been checking the authors' names). The problem: there are a growing number of applications which wish to exchange extended-ascii data with appropriate display terminals. In every case I am aware of, the application, the server O/S, the client O/S and the display all understand 8-bit, and the terminal type information is available to all components. The obstacle: Telnet clients and servers universally mask off the 8th bit of a received data stream, in spite of the sentence in the RFC which says that codes above 128 will have no effect. Why? Because of a number of clients and servers which take it upon themselves to generate parity to send over the network (which appears a total waste of time, but maybe I'm missing something?). 'Binary' mode was designed to solve the problem, but few implementations handle it, and yours are the only ones I am aware of where it is possible to get 'binary' without side effects. Side issue: Serial-line Parity. Are tty drivers that pass received parity to applications programs common? Are there many OSs where writing 8-bit data to the tty driver confuses its output parity generation? As long as the answers to those questions are 'no', the presence of serial-line parity seems to be reduced to another kind of terminal-type mismatch peculiar to 8-bit datastreams. Solution 1: Require that all clients and servers negotiate 'binary' before passing an 8-bit datastream. Advantages: The feature need only be dealt with on specific systems that understand it. Of course, the rest of the world must continue to mask the parity off, anyway... Disadvantages: The user and/or the 8-bit application must request 8-bit mode, (presumably the user, manually), and the client and server programs both need hooks, and some more code. Any useful automatic operation (which you don't seem to like) requires 'binary' and 'xx', so extended ascii can be differentiated from 3270, etc. TN3270 has this, although not all implementations conform completely. TN3270 is already fully automatic in most implementations. Do the other 'binary' dialects have similar behavior? Solution 2: Require the elimination of implementations that generate meaningless 8-bit, and allow clients and servers to pass all 8 bits between the application and the tty driver by default. Advantages: In the best case (possibly a PC client), implementation consists of removal of 1 line of code. This is the case wherever the applications and the tty driver can take care of themselves (no more bothered by 8-bit than by random control characters). If the OS can't hack it, then leave the existing masking code in, and write a hook to bypass it when requested by the application or user. Amenable to integration with automatic or semi-automatic terminal type selection, which can take place in the client and server OS, without hooks into the Telnet (which is likely to be a layered product, not always available from the OS vendor). The 8-bit application is less likely to have to understand about networks, too. Disadvantages: Everybody needs the mask operation, and the hook to bypass it, until the parity-senders get upgraded. Of course, by my reading, they're already in violation of the RFC. Requires issuance of new RFC and Mil-Std. Tinkers with something that's already working (except for people like the original poster). Axe-to-grind: I want to provide better functionality so more people will use TCP/IP and give me more money. Better functionality is nothing without interoperability, so I am motivated to push for what looks to me like the solution that requires less work from the average developer or vendor. I recognize that you've already done your part of your solution, but your posting implied that few others have done it (or done it right, anyway). I wish to become better informed, in part because I am participating in the effort to standardize 3270-mode. I would like to know details of other uses of 'binary' mode, and options used in conjunction with 'binary' mode. I would also like to hear other implementors' approaches to solving the original poster's problem, and if I have misunderstood yours (request binary manually, whereupon client and server do some checking, and agree upon it, and then the user can start the 8-bit application), please clarify. jbvb James B. VanBokkelen FTP Software Inc.