Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!UCBVAX.BERKELEY.EDU!minshall%opal.Berkeley.EDU
From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Telnet Option Negotiation to IBMish Hosts
Message-ID: <8703090451.AA06401@opal.Berkeley.Edu>
Date: Sun, 8-Mar-87 23:50:00 EST
Article-I.D.: opal.8703090451.AA06401
Posted: Sun Mar  8 23:50:00 1987
Date-Received: Mon, 9-Mar-87 19:36:48 EST
References: <8703051246.AA14918@gjetost.wisc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 56
Approved: tcp-ip@sri-nic.arpa

All,
	First, as to Philip Budne's complaint about 3270
negotiation making it hard to pass the REAL terminal type
across the telnet connection - true.  But, you have to
think about where this all came from.  The original intent
was that real, live, ibm 327x's, when initiating telnet from
their real, live ibm host, should be able to talk to other
ibm hosts in a "native" fashion.  No one should complain
about this - we let vt241 users get their vt241's connected
in "native" fashion when talking between two Vax Unix systems.

	However, the people at Wisconsin, Rice, Berkeley,
Yorktown labs, Cornell, and who knows where else have realized
that "hey, we can do that from Unix/ms-dos/macintosh-land, too!"
Then, there IS a problem.  Maybe what we need is "do terminal-type"
and also "do charlatan-terminal-type".  Anyway, the point is that
it WOULD be convenient if we knew we were trying for 3270 emulation;
or we could pass both a series of 3270 types and of "real" terminal
types.

	Say you are connecting to a system (any old system) from a PC.
The system may have a "preferred" terminal type (VT241, say), and the
PC may have a few emulation modes (adm3a, vt100, tvi950, say).  So,
the system keeps says "send terminal type", and the PC sends them
all, and finally indicates end-of-file with "unknown".  Now, we have just
"lost", since the system might just wish it had been willing to
take the best of what had been offered at the time (maybe vt100).
This is something like "the price is right" (TV show, for the uncultured).
"You may now take this vt100 and run with it, OR you may toss it
away in the hopes that what lies hidden behind that door may be better
for you".

	In fact, it may be more complicated than that.  Still, I don't
think so.  So, maybe the ability to "see the list again" would allow
for things to work.  If so, then the server could see the whole list,
keep track of "what seemed best", and then go back and ask for that
(so, why not "send terminal LIST", and "SET terminal type"?).
(The point is, right, that we are TRYING to learn; not that "we made
a mistake!".)

	As to Marvin Solomon's comments, I doubt I can add much.
I do believe that the server could buffer some data, waiting for
the end of the terminal type/eor/binary negotiations to happen
before committing to either NVT or 3270 mode.  The server is
probably in error in not accepting even some of the negotiation
out of order (but, it isn't the only server with this bug).

	The bottom line in the Wiscnet case is, probably, people
to do the various "small" things.  To my knowledge, Wisconsin is
no longer getting any IBM money to support (let alone enhance)
Wiscnet.

	I think an RFC would be nice.  I think, however, that maybe
it needs to address a fairly large amount of issues.

Greg