Subject: Comments on TN5250E from an implementor

From: Michael Johnson <[email-masked]>
Date: Fri, 17 Jul 1998 17:25:02 -0400

I realize that I am a late-comer to this discussion, but since the timetable
on TN5250E is in the "Gather operational experience from implementers." stage
I would like to make the following observations and comments:

The NEW-ENVIRON option is perhaps not the best vehicle for implementing
TN5250E for a number of reasons:

A) TN5250E uses NEW-ENVIRON in a manner that seems to violate RFC 1572, in
   that the server sends information embedded in a variable name, and the
   client then sends a variable with a different name when responding to
   the send request. A liberal reading of RFC 1572 would seem to allow this,
   but IMHO it violates the intention of the RFC designers. Defining a new
   option/subnegotiation would allow the password encryption feature to function
   smoothly without using NEW-ENVIRON in a questionable way.

B) There are a large number of USERVAR variables defined to supply the server
   with various data. These data might more easily (that is to say, with
   less complexity) be transmitted by a newly designed option/subnegotiation
   rather than piggy-backed onto the NEW-ENVIRON option.

C) A new option/subnegotiation would eliminate the need for deferring the
   TERMINAL-TYPE negotiation that using NEW-ENVIRON introduces, a need which
   introduces an objectionable complexity into the negotiation process. This is
   the sort of thing that subnegotiations are intended to avoid. A server that
   can support the new option would presumably try it first and would only move
   on to TERMINAL-TYPE when the new subnegotiation completed or failed.

Since existing TN5250 is based on 5250 Workstation Pass-Through and the
draft TN5250E reveals more of the underlying 5250 Workstation Pass-Through
architecture, I would like to suggest that TN5250E reveal the full format of
the 5250 WPT SUR structure and allow the client to transmit the SUR to the
server as part of a new subnegotiation. This would allow the client to send
all of the information which is currently being sent using NEW-ENVIRON and
would allow implementers to leverage existing code for building a WPT SUR
which they will already have if they support APPC connectivity between an
emulator and an AS/400. The mechanism already exists and is easily adaptable
to TN5250E.

An example subnegotiation might look like this:

   server                                     client
   IAC DO TN5250E ->
                                           <- IAC WILL TN5250E
   IAC SB TN5250E SEED xxxxxxxx IAC SE ->
                                           <- IAC SB TN5250E SEED yyyyyyyy IAC SE
   IAC SB TN5250E USERPASS SEND IAC SE ->
                                           <- IAC SB TN5250E USERPASS IS userid IS password IAC SE
   IAC SB TN5250E SUR SEND IAC SE ->
                                           <- IAC SB TN5250E SUR IS startup-record IAC SE
   IAC DO TERMINAL-TYPE ->
                                           <- IAC WILL TERMINAL-TYPE
   IAC SB TERMINAL-TYPE SEND IAC SE ->
                                           <- IAC SB TERMINAL-TYPE IS terminal-type IAC SE
   IAC DO EOR ->
                                           <- IAC WILL EOR
   IAC DO BINARY ->
                                           <- IAC WILL BINARY

Where "xxxxxxxx" is the server seed, "yyyyyyyy" is the client seed, "userid" is the user profile
name to be used, "password" is the password in either encrypted or cleartext form (depending on
whether the client sent a seed value or not) and "startup-record" is an appropriate WPT SUR for
the desired session. Any of these could be undefined values (i.e. IAC SB TN5250E SEED IS IAC SE)
in which case corresponding features such as password encryption or automatic login would not be
used. Client sending an undefined value for the SUR could be interpreted by the server as a
refusal to do TN5250E and the server could then send WONT or DONT TN5250E and fall back on
traditional TN5250.

The TN5250E standard would need to specify which, if any, fields in the SUR the server is allowed to
modify or ignore. For example, the server could reasonably be allowed to ignore the device type/model
pair in the SUR since that information is in the TERMINAL-TYPE negotiation. Alternatively, the SUR
device type/model could be used to replace TERMINAL-TYPE, as the DEVICE-TYPE subnegotiation replaces
TERMINAL-TYPE under TN3270E. Agreeing to TN5250E could also imply EOR and BINARY as TN3270E does.

Michael T. Johnson
NetManage - delivers Standards Based IntraNet Solutions