Re: Newly revised standards-track RFC

Peter DiCamillo <CMSMAINT%BROWNVM.bitnet@list.nih.gov> Fri, 15 April 1994 06:47 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00518; 15 Apr 94 2:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00513; 15 Apr 94 2:47 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa01091; 15 Apr 94 2:47 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 8425; Fri, 15 Apr 94 02:18:41 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 8423; Fri, 15 Apr 94 02:15:49 EDT
Date: Fri, 15 Apr 1994 01:32:07 -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: Peter DiCamillo <CMSMAINT%BROWNVM.bitnet@list.nih.gov>
Subject: Re: Newly revised standards-track RFC
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: Your mail of Thu 14 Apr 1994 20:24:13
Message-ID: <9404150247.aa01091@CNRI.Reston.VA.US>

In my tn3270 implementation, Telnet options received within a data
block are processed at the time they are received.  No special precautions
are taken to defer processing which would more sensibly be done at the
completion of a data block.

This is by far the easiest and most straightforward way for me to implement
it.  It also is very general, in that it allows the possibility of
handling options that would affect only part of the data in a 3270
block.  It's conceivable that some future option could cause tn3270 to
change a flag which would affect how it processes subsequent data even
within the same block.  My general approach is to assume that if an option
occurs within a data block, there is a good reason why it was sent then,
instead of between blocks.

What I would most favor is a requirement that Telnet options should be
processed at the time they are received.  It allows for the kind of
processing I described above, and does not allow different implementations
to handle the options at different times.  Apparently, some implementations
need to defer options processing.  Considering that, I wouldn't object
to a statement that implementations SHOULD attempt to process Telnet options
at the time they are received, but MUST process them no sooner than at the
start of the data block that contains them, and no later than at the end of
the data block.

I would be opposed to a requirement that forced processing of options
to be delayed.  To strictly implement that, I'd need to add new code to
save up options to process later, and I don't see any good reason to do
that.  Can anyone think of a situation where even though a server wanted
an option processed at the end of a data block, it had to send the option
sooner?

Peter