[list.ibmtcp-l] Options, one more time...

Bruce Crabill <@CUNYVM.CUNY.EDU:BRUCE@UMDD.BITNET> (02/20/90)

How about client programs running on a IBM mainframe that support 3270 data
streams and try to connect to a Unix system?  Since the Unix system is
going to say Yes to IBM-3278-2 (or which ever), and will have to say yes
to the other options, how do you prevent the IBM client program thinking
it is talking to a Unix TELNET server in 3270 data streams when the Unix
server doesn't understand them at all?

                                       Bruce

Bruce Crabill <@CUNYVM.CUNY.EDU:BRUCE@UMDD.BITNET> (02/20/90)

But the problem is that Unix systems will currently say Yes to any client
specified terminal type.  You can TELNET into a Unix system specifying
IBM-3278-2 and it will happily accept it.  And looking thru the Host
Requirements RFC and your RFC (RFC-1091), no where do I see where this
practice has been declared illegal.  Certainly it is the intention of your
RFC that this should be so, but there is no requirement in the Host
Requirements RFC that makes it required (or even a should).  Even if such
a requirement was put in, all we have to do is fix all the Unix TELNET
servers in the world.  Personally I find fixing the TN3270s more
practical.

                                       Bruce

braden@VENERA.ISI.EDU (02/20/90)

        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

braden@VENERA.ISI.EDU (02/21/90)

Ah, the perils of reading mail serially, and living 3 hours west!

I concur with JVBV's comments and explanations of the intent of the
HRRFC.  As James suggests, the requirement to "support" feature X (eg X
= Telnet Binary option) was meant in the sense in which a knowledgable
and experienced network programmer would take it.  Some may wish for
much more explicit and detailed definitions, but that would lead to the
sort of state tables you find in the Mil Specs.  I think it would be
(have been) a mistake to go to such a level of detail, since it is
difficult to get it all right, and it would be constraining when new
situations arise.

Still, I will make a note of this issue for the future.

Bob Braden