Re: Newly revised standards-track RFC (term negotiation)

Pierre Goyette - The 3270 Man <PIERRE@cc.mcgill.ca> Fri, 15 April 1994 15:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05981; 15 Apr 94 11:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05977; 15 Apr 94 11:48 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa10935; 15 Apr 94 11:48 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 9839; Fri, 15 Apr 94 11:46:06 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 9838; Fri, 15 Apr 94 11:42:28 EDT
Date: Fri, 15 Apr 1994 11:36:06 -0400
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Pierre Goyette - The 3270 Man <PIERRE@cc.mcgill.ca>
Organization: McGill University Computing Centre
Subject: Re: Newly revised standards-track RFC (term negotiation)
X-To: Multiple recipients of list TN3270E <TN3270E@LIST.NIH.GOV>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: Message of Fri, 15 Apr 1994 09:14:34 -0600 from <elr0262@NEWSIT2.MCDATA.COM>
Message-ID: <9404151148.aa10935@CNRI.Reston.VA.US>

On Fri, 15 Apr 1994 09:14:34 -0600 Eddie Renoux said:
>Pierre says:
>>  A number of vendors also send some negotiations twice, for example,
>>I'll receive a DO BIN at the beginning and after some other
>>negotiations, I'll get another DO BIN. I hope the RFC makes it crystal
>>clear that options are negotiated ONCE ONLY.
>
>It was my understanding that any option can be (re)negotiated at any time.  If
>as a result of that negotiation the TN3270 session is no longer valid (WONT
>BIN) the TN3270 session is terminated and the host notified.  That is how
>McDATA currently tries to handle it.  It would be nice if this were prohibited
>but that is perhaps not in keeping with the TELNET culture.

Just to clarify, the host system didn't renegotiate the option
differently, it sent the same option again, which per current rules
is ignored by the client to prevent negotiation loops. My point is
that many vendors don't clearly understand the tn3270 protocol
negotiation probably since there is no single source of information (truth)
to the protocol.

>>  I don't like protocols which leave the 'implementor' to decide when
>>to process certain items. This results is poor standards such as HLLAPI
>>and EHLLAPI. Therefore, I would vote for a solution which is fixed in
>>nature and exactly describes when events are processed and what to do
>>with them.
>
>I certainly agree.
>
>Eddie Renoux  elr@mcdata.com