Re: Newly revised standards-track RFC

[Peter DiCamillo <[e-mail]>]

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