Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!GJETOST.WISC.EDU!solomon From: solomon@GJETOST.WISC.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8703051246.AA14918@gjetost.wisc.edu> Date: Thu, 5-Mar-87 07:46:24 EST Article-I.D.: gjetost.8703051246.AA14918 Posted: Thu Mar 5 07:46:24 1987 Date-Received: Fri, 6-Mar-87 23:57:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 132 Approved: tcp-ip@sri-nic.arpa OK, here's the "Wisconsin view" on the 3270/telnet controversy. Sorry I took so long to respond, but I somehow got deleted from the TCP/IP list. I think I tracked down all the relevant mail on this subject from the list, but if I seem to be ignoring some past message, it may be because I missed it. I used to think that no new rfc was needed, since the existing telnet specs (especially rfc885 and rfc930) told the whole story. I now think that while a new spec may not be needed, an rfc might be called for just to make things clearer. I pretty much agree with Bob Braden about what SHOULD happen: > The terminal type negotiation and the EOR negotiations may occur > in any order. If EOR has been negotiated in both directions and if a 3278 > terminal type has been negotiated, THEN negotiation of BINARY will cause > the mode to change from NVT to full-screen-3278. Note that the BINARY > is negotiated separately in each direction, which correctly synchronizes > the mode change (any NVT data in the pipeline in each direction should > be correctly handled). The remainder of this (rather long) message contains my views about the philosophy of telnet, some of the practical problems in implementing it, and some explanation of why Wiscnet behaves the way it does. Telnet assumes that there is a set of "options". Corresponding to each option is a pair of Boolean variables, one for each end of the connection. The telnet spec (rfc854) gives a protocol for changing any one of these Boolean variables. It gives no information about what they may mean. The individual options are described in separate rfc's, some in more detail than others. Telnet also provides a "suboption" facility to send more complicated out-of-band information. Finally, telnet defines a "network virtual terminal" (NVT), which is a dumb teletype-like device that dictates the default syntax and semantics of data on the connection. Telnet has no facilities for tying together a package of options that are logically interdependent. The general strategy is to hold back data during a flurry of option negotiations until everything settles down, so that you don't send anything while the options are in an inconsistent state. The ASCII option is misnamed. It should be called "NVT", since it means that data sent (from an end where ASCII is "true") will conform to NVT conventions. The negation of ASCII is BINARY (perhaps "transparent" would be a better name), which means that the data is NOT assumed to have any particular telnet-defined structure. The 327x terminals have their own protocol, which is very unlike NVT. Therefore, it seems reasonable for two consenting telnet ends to exchange data in the "raw" 327x format. Other "bilateral" agreements could similarly be defined. The BINARY option almost, but not quite, fits the bill. There are two problems. First, the details of the protocol depend on the particular model of 327x terminal, and perhaps on other information, such as the type of controller and whether SNA is in use. Thus there has to be a way of exchanging terminal type information. The set of terminal types defined in rfc930 is small, but the intention is that this option negotiation be used to convey whatever information is necessary to set up whatever ad hoc protocol is desired. Berkeley's tn3270 always says "ibm3278-2". The 3270 emulator I wrote (included with the Wiscnet distribution), says 3278-2, -3, or -4 depending on the number of line on the screen (from termcap or from the tty driver on 4.3BSD UNIX systems). If the need arises, one can easily define other "terminal types" to describe SNA, or whatever. Second, the 327x protocol is a record-oriented rather than byte-stream protocol. There has to be a way of signaling the end of a record outside the set of 256 possible octets. (By the way, for the same reason, IMAGE mode in FTP is not adequate for transferring IBM files; the end of a record is not indicated by any of the 256 EBCDIC characters, but by out-of-band data. You have to use PAGE mode instead.) I originally suggested that we simply define an escape sequence IAC EOR (where EOR is some code distinct from WILL, WONT, etc) to mark the end of a record. Since this sequence could never legally occur according to the existing spec (even in BINARY mode!), it shouldn't cause any confusion. However, Jon Postel insisted that a telnet process shouldn't send IAC EOR without first getting permission via IAC DO EOR. Thus the general scheme is as follows: Consenting telnets use BINARY to agree that they will not use NVT, but rather their own private protocol agreed upon by bilateral negotiation. Before doing so, they have to establish the details of this bilateral protocol. Thus a telnet process may refuse BINARY if it feels adequate groundwork has not been laid out. In the present case, an acceptable terminal type and permission to use EOR are required. I can imagine similar variants of this scheme for other non-NVT protocols. Now for implementation problems. If you want to implement server telnet, you either have to modify every application so that it can talk to the telnet server rather than a terminal, or you need an operating-system facility for the server to masquerade as a terminal to another process. The latter facility is called a pseudo-tty (pty) in UNIX jargon; under VM, it's called "logical device support facility" (LDSF or ldev). Under LDSF, the information passed between the application and the server must be a 327x data stream. One of the parameters to the "initiate" LDSF call is the terminal type. Once the logical device is created, there is no way to change the terminal type. Thus the Wiscnet server tries to avoid creating the logical device as long as possible. If a telnet connection begins with an appropriate negotiation for BINARY mode, the server has all the necessary information. Otherwise, it creates the logical device with type "3278-2" and goes though the painful process of translating between that protocol and NVT. If any NVT data arrives before the terminal type is established, the server is forced to create a logical device, and so it must choose a terminal type. Subsequent attempts to go into BINARY mode are simply rejected. I suppose two enhancements are possible: First, if the other end sends some NVT data and then decides to advertise a terminal type that "just happens" to match the type chosen by the server, it should be possible to accept it. Second, the server could save up a "small" amount of NVT data before setting up the LDSF device, in hopes that the necessary info will soon arrive. Both are kludgy, but both might be very helpful in practice. A similar problem comes up in backing out of BINARY mode. Backing out of BINARY/3278-2 to NVT shouldn't be too hard in principle (simply a matter of programming :-). Backing out of some other 327x model would be a bit harder. Right now Wiscnet refuses to do either. Finally, I should discuss sequencing of negotiations. As I think I've made clear, the terminal type and EOR have to be settled before BINARY makes sense. The current Wiscnet code insists on EOR before terminal type. That's probably a bug. However, the Wiscnet code will also be willing to go into BINARY mode without first agreeing on EOR. That's a "feature"--really a historical curiosity (see the discussion above and the comment in the Wiscnet code), but it also conforms to the maxim, "be conservative in what you send and liberal in what you send". Telnet can understand IAC EOR perfectly well whether or not DO EOR has been established. Well Bob, can this longwinded discussion serve as a draft of the needed rfc, or should be rfc just be the single paragraph of yours that I quoted above?