Path: utzoo!utgpu!CUNYVM!IBMTCP-L
Date:	Tue, 20 Feb 90 15:38:41 EST
Reply-To: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM.bitnet>
Sender: IBM TCP/IP For VM List <IBMTCP-L@CUNYVM.bitnet>
From:	braden@VENERA.ISI.EDU
Subject:      Re: Options, one more time...
X-To:         BRUCE@umdd.umd.edu, jbvb@vax.ftp.com
X-cc:         IBMTCP-L@cunyvm.cuny.edu, TN3270@terminus.umd.edu,
To:	UofToronto LAN redistribution <IBMTCP-L@UTORGPU.uucp>
Message-ID: <90Feb21.032129est.57561@ugw.utcs.utoronto.ca>
Newsgroups: list.ibmtcp-l
Distribution: ut
Approved: devnull@gpu.utcs.toronto.edu

        Perhaps the phrasing wasn't clear enough.  As I understood it, the
        intent of the sentence that said "...MUST accept any name" was to cope
        with 'vt100' (4bsd termcap) vs.  'dec-vt100' (Assigned Numbers).  In
        other words, you need to have aliases.  We can certainly get it
        clarified in an update to the RFC.

Hmmm.  My understanding is (maybe) a little different.  It MUST send the
officially defined terminal type name, when there is one... thus, the
intent is that in the case you cit, it is broken for a 4bsd to send 'vt100'.
However, if there is a foobar terminal that is not currently defined in
Assigned Numbers, you can send anything you want.  For robustness, the
receiver is required to receive any name.

           ..... In case you don't
           recognize that sequence, those are the 3 options that TN3270 uses to
+ decide
           whether or not to send 3270 data streams.  So when people start to
+ write
           TELNETs that are compliant to RFC-1123, we are going to be in BIG
+ trouble.

Sorry, I am probably being dense, but I don't see what the "BIG
trouble" is.  We have required the things you need to do 3270
datastream negotiation.  Where is the rub?

Bob Braden