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