Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!ucbcad!ucbvax!CORNELLC.BITNET!MQH From: MQH@CORNELLC.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Telnet Option Negotiation to IBMish Hosts Message-ID: <8702141520.AA15042@ucbvax.Berkeley.EDU> Date: Fri, 13-Feb-87 18:32:19 EST Article-I.D.: ucbvax.8702141520.AA15042 Posted: Fri Feb 13 18:32:19 1987 Date-Received: Sun, 15-Feb-87 05:10:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 120 Approved: tcp-ip@sri-nic.arpa Hello (and forgive me, this is awful long), I'm trying to decide how to "correctly" implement TELNET option negotiation for programs which can emulate both ASCII and EBCDIC. I support Wiscnet (a VM implementation of TCP/IP) here at Cornell. I've been working with one of our programmers who's been working on Cornell versions of TN3270 which run on MACs and PCs. Our TN3270s can successfully negotiate into 3270 terminal emulation with Wiscnet, but we've discovered that they can't talk to KNET (yet another implementation of TCP/IP for VM). It turns out that Wiscnet can't talk to KNET either, and that Berkeley's latest release of TN3270 doesn't talk to KNET in 3270 mode. I've spent some time researching this whole mess, and my results are below (I'm of the opinion that everyone's at least a little busted). Basically, the big problem is how to decide that we're going to do the connection in EBCDIC. I don't think the current RFCs for telnet supply enough information on how to properly handle EBCDIC connections. Here is a basic summary of the various "philosophies" of option negotiation in the code I've dealt with. I'll warn you in advance that these are my impressions, and best guesses, and that I've been known to be wrong. If I am wrong, please let me know. Wiscnet After establishment of the connection, both user, and server must "discuss" the following options, IN THIS ORDER, to form a "transparent mode" (3270) connection. TERMINAL TYPE, END OF RECORD, TRANSMIT BINARY. If any of the options are settled out of order, or some of the responses are unacceptable, or data arrives before option negotiation completes, the connection will irrevocably be put into "line mode" (ASCII). KNET After establishment of the connection, KNET will send a one line blurb in ASCII announcing itself and the host. Then option negotiation begins. If KNET does a SEND TERMINAL TYPE, and the user code responds with a valid 3270-ish terminal, KNET sends DO BINARY, WILL BINARY, and begins sending EBCDIC data. If it doesn't get an acceptable terminal type, the server puts up a menu of ASCII terminals it's willing to do protocol conversion for. Cornell TN3270 (PC and MAC) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". Hack 1: If the server sends DO EOR, we enter 3270 emulation mode. If not, we do H19 emulation. Hack 2: If the server sends DO BINARY, we enter 3270 emulation mode. If not, we do H19 emulation. Berkeley TN3270 (UN*X hosts) (I'm not at all positive about this one) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". If we change an option, and we get to a state where we have sent IBM-3278-2, and we are sending and receiving in binary, we enter 3270 emulation. Now, after all that, we can look at why some won't talk to others. Wiscnet -> KNET When the KNET server sends its one line blurb, Wiscnet decides to do line mode emulation. Unfortunately, it will still respond with options appropriate to 3270 emulation. The result is that KNET server is in 3270 mode, and Wiscnet user code is in ASCII line mode. I'm not sure of how the reverse case turns out. Cornell TN3270 -> KNET KNET doesn't initiate EOR option processing with the user. Hack 1 of our TN3270 therefore never went into 3278 emulation. Hack 2 does better, but we've come upon a bug at the TCP level. We're looking into it. Berkeley TN3270 -> KNET An old release (March 22, 1985) works fine. A newer release, (January 11, 1986) end's up talking to KNET in ASCII, and is forced to use the KNET protocol conversion. I think it's KNET's fault. The new TN3270 does a DO SUPPRESS GO AHEAD before KNET gets a chance to send an option. I think this confuses KNET, because it never gets around to sending a SEND TERMINAL TYPE. Since it never gets a 3270-ish terminal type from the user, it does ASCII emulation. Fortunately, since TN3270 never sent it's terminal type, it also decides to do ASCII. Now that that's clear as mud.... It seems that most all the implementations seem to think that the BINARY option is the way to do EBCDIC. Is that cool? It seems to me that an "EBCDIC" option would be less confusing. I DON'T think that the ASCII/EBCDIC question should be settled based on terminal type 'cause most UN*X implementations won't behave properly. If the server doesn't know how to do the terminal type announced by the user code, it's supposed to ask the user if it'll do something else. In practice, I haven't seen a single implementation that does this. Berkeley 4.2 never asked, and Berkeley 4.3 asks only once. It doesn't notice, for example, that "IBM-3278-2" isn't in its termcap. So, I guess I'd like to see an EBCDIC option added to telnet. Once that's in place, it's a trivial matter to make one end or the other announce that it WILL EBCDIC. If both sides DO EBCDIC, then everything would be fine. The matter of 3270 emulation could be decided with TERMINAL TYPE negotiation. If EBCDIC is refused, then both ends would do the connection in ASCII. If an EBCDIC option is the way to go, I have two questions. First, would the server, or the user announce WILL EBCDIC? The TN3270 programs are a little wierd in that they can emulate more than one kind of terminal. Second, would EBCDIC imply anything about BINARY? My thanks in advance for any comments you have on the subject. I hope that we can come to a quick resolution to this problem so we can get all our IBM implementations talking to one another. Mike Hojnowski Long-winded Wiscnet Grunt Cornell Theory Center