Re: Telnet Option Negotiation to IBMish Hosts


Marvin Solomon (solomon@gjetost.wisc.edu)
Thu, 5 Mar 87 06:46:24 CST


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?



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:44 GMT