Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!uwvax!husc6!panda!genrad!decvax!ucbvax!MIT-MULTICS.ARPA!Kodinsky
From: Kodinsky@MIT-MULTICS.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Telnet Option Negotiation to IBMish Hosts
Message-ID: <870329202736.635670@MIT-MULTICS.ARPA>
Date: Sun, 29-Mar-87 15:27:00 EST
Article-I.D.: MIT-MULT.870329202736.635670
Posted: Sun Mar 29 15:27:00 1987
Date-Received: Tue, 31-Mar-87 01:02:54 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

I wish to first apologize for not reading and responding to this note
earlier.  It obviously has great importance to the KNET telnet programs
(both client and server).

The KNET telnet client and server operate almost identically to the
procedure laid out in Marvin's note (at least that is the way they
should operate).  There are a few exceptions -

FIRST:  we will renegotiate the terminal type at any time - though in ]
the "No change" mode.  As a matter of fact, if the terminal type were to
be changed (within telnet server storage) there would be no effect - the
logical device already exists.

SECOND:  we do not, as best as I can tell, require an EOR option to be
negotiated.  If we are in "3270" mode then we automatically assume that
EOR is going to be understood by the other end.

I think that an RFC would be a good thing for this.  It should address
two issues:  the details of 3270 telnet AND (more importantly) the
issues involved in tying together interdependent options (as Marvin
Pointed out).  We at Spartacus would be glad to work with the community
on this RFC.  We do not feel that we can take a lead in this effort
since we have been on the net for only a few months.

Regards, Frank Kastenholz - Manager KNET/VM Development -
Spartacus/Fibronics