Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!ISI.EDU!braden
From: braden@ISI.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Telnet Option Negotiation to IBMish Hosts
Message-ID: <8702192154.AA01152@braden.isi.edu>
Date: Thu, 19-Feb-87 16:54:55 EST
Article-I.D.: braden.8702192154.AA01152
Posted: Thu Feb 19 16:54:55 1987
Date-Received: Thu, 26-Feb-87 19:30:58 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 56
Approved: tcp-ip@sri-nic.arpa

Mike,

Your recital of the various IBM host implementations of full-screen
3278 operation did not mention the UCLA OS/MVS version, which (almost!)
interoperates with the Wiscvm code.

You incorrectly state that the choice of mode is between ASCII and
EBCDIC encoding.   Suppose there were an EBCDIC option in TELNET... this
would simply be NVT encoded in EBCDIC; the only question would
be whether to use CR LF or NL for end of line. 

Actually, the choice is between NVT and encapsulated IBM 3278 order
streams.  Now, the latter is about as close to binary as anything I
know... it contains command code bytes, cursor positions, repeat counts,
flags, and, encapsulated in all that framing and control, some EBCDIC
text.  It could as well be Display Code or Sanskrit.  The 3278 stream is
BINARY, man!

You state that the Wiscnet implementation requires a fixed order of
negotiation.  That surprises me... in an exchange of mail several years
ago Larry Landweber and I agreed on the following rules:

  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 UCLA code (v.1.6) does this correctly; I thought that Larry said
the Wiscnet code did also.  

There is a problem with negotiating OUT of full-screen back to NVT.  The
MVS Telnet Server requires this; it negotiates OUT of BINARY, which
returns to NVT. Returning to 3278 mode later in the Telnet connection
requires only negotiating BINARY again; the EOR and Terminal Type
negotiations are assumed to be persistent on the connection.  The Wiscnet
code, because of the hacky way they implemented Telnet using existing VM
features, is unable to change a connection back to NVT mode if it begins
in full-screen mode.

The need for a little RFC on 3278 encapsulation in Telnet has been
repeated pointed out over the past 4 years, but no one has ever felt
they had the time (read $$) to pay for it.  Not Wisconsin, not UCLA,
not IBM FSD, not Berkeley.  If would be wonderful if someone would
write it down... but they had better understand the problem first.
For example, the current spec uses the pre-SNA encoding, which is
probably a mistake.  And it is probably necessary in general to
negotiate not just terminal type but also control unit type, since
different IBM controllers support different wonderful features of
the 3278/etc terminals.

Welcome to the wonderful world of...

   Bob Braden