Re: Newly revised standards-track RFC (term negotiation)
Eddie Renoux <elr0262@newsit2.mcdata.com> Fri, 15 April 1994 15:34 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05693; 15 Apr 94 11:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05689; 15 Apr 94 11:34 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa10536; 15 Apr 94 11:34 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 9739; Fri, 15 Apr 94 11:27:41 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 9738; Fri, 15 Apr 94 11:20:07 EDT
Date: Fri, 15 Apr 1994 09:14:34 -0600
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: Eddie Renoux <elr0262@newsit2.mcdata.com>
Subject: Re: Newly revised standards-track RFC (term negotiation)
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: <9404150620.AA07686@newsit2.mcdata.com> from "Peter DiCamillo" at Apr 15, 94 01:32:07 am
Message-ID: <9404151134.aa10536@CNRI.Reston.VA.US>
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. > 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
- Re: Newly revised standards-track RFC (IAC/EOR) Eddie Renoux
- Re: Newly revised standards-track RFC (IAC/EOR) Eddie Renoux
- Re: Newly revised standards-track RFC (term negot… Eddie Renoux
- Re: Newly revised standards-track RFC (IAC/EOR) Roger Fajman