[mod.protocols.tcp-ip] IBMish

budd@BU-CS.BU.EDU (Philip Budne) (03/06/87)

What I find most upsetting about WISCNETs behavior is that it makes it
impossible to use the terminal type subnegotion for what is was meant
for: terminal types!

4.3 telnet and telnetd use the terminal type subnegotion, but if you
try to use 4.3 tn3270 to connect to a 4.3 host you end up as an
ibm-3277-2. We have a more recent version from Bekeley that will
negotiate based on screen size.

The problem is that the version of WISCNET we run sends DO TERMINAL
before there is any indication that the client telnet is willing to do
327x emulation.  This forces any tn3270-like program to assume the
worst.

IBM 327x emulation is not a simple (or unique) instance of the desire
to transparently transmit binary data.  Why isn't there an explicit
(sub)negotiation for "DO 327x"? The reply could be WILL/WONT or the
emulated 327x terminal type.

I thought that EOR had been invented explicitly for this. But WISCNET
negotiates EOR *AFTER* TERMINAL TYPE.

	oy gevalt!

	-Phil

Here is a log of a conversation between a SUN running the most recent
tn3270 we have from Berkely and our 3090, the faint of heart might
wish to stop here.


Connected to buacca.bu.edu.
SENT do SUPPRESS GO AHEAD
RCVD do TERMINAL TYPE (reply)
SENT will TERMINAL TYPE (don't reply)
RCVD wont SUPPRESS GO AHEAD (reply)
SENT dont SUPPRESS GO AHEAD (reply)
Received suboption Terminal type - request to send.
Sent suboption Terminal type is IBM-3278-3
<nasty escape seqences>
RCVD do END OF RECORD (reply)
SENT will END OF RECORD (don't reply)
RCVD will END OF RECORD (reply)
SENT do END OF RECORD (reply)
RCVD do BINARY (reply)
SENT will BINARY (don't reply)
RCVD will BINARY (reply)
SENT do BINARY (reply)
Unable to find entry for xterm in file /usr/etc/map3270
Unable to find entry for xterm in file /usr/etc/map3270
Using default key mappings.
<more nasty escape seqences here>
RCVD do BINARY (don't reply)
RCVD will BINARY (don't reply)
<madness ensues from here on it>