Re: Newly revised standards-track RFC
Pierre Goyette - The 3270 Man <PIERRE@cc.mcgill.ca> Fri, 15 April 1994 01:40 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17962; 14 Apr 94 21:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17958; 14 Apr 94 21:40 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa24243; 14 Apr 94 21:40 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7874; Thu, 14 Apr 94 21:38:27 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7869; Thu, 14 Apr 94 21:15:43 EDT
Date: Thu, 14 Apr 1994 20:41:48 -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
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 Thu, 14 Apr 1994 20:24:13 EDT from <RAF@CU.NIH.GOV>
Message-ID: <9404142140.aa24243@CNRI.Reston.VA.US>
Roger and Folks, As a developer of multiple 3270 products, I would prefer that all IACs be sent in separate TCP blocks and not part of 3270 blocks. Although this doesn't change the parsing code, it does facilitate people who support multiple terminals types by allowing the application to properly switch modes before processing the next data block. A clean break... I would also encourage vendors to send certain IAC sequences in the same block. i.e. A particular vendor I won't name sends the IAC SB in two or three parts: the FF FA is sent alone, then the next packet contains 18 01, then the final packet FF F0. Obviously, someone was too lazy to send this out in one packet and make life easier for us 'client' software implementors. 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. 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. (Maybe I rattling on here 'cause I didn't read the last review, so ...) Pierre Goyette E-Mail: Pierre@CC.McGill.Ca Developer, TCP3270/NET3270 Systems Tel: (514) 398-3270 Manager, Networking & Communications FAX: (514) 398-6876 McGill University Computing Centre 805 Sherbrooke West, Room 200 Montreal, Quebec Canada H3A 2K6
- Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Robert G. Moskowitz
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Jagan Bearelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Robert G. Moskowitz
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Pierre Goyette - The 3270 Man
- Re: Newly revised standards-track RFC Peter DiCamillo