Re: Newly revised standards-track RFC

[Roger Fajman <[e-mail]>]

> > Ok, Telnet commands within a TN3270E data message must be processed,
> > but they may be processed either before or after the TN3270E data
> > message that contains them (implementation dependent).
> >
> >                         -David Borman, [e-mail]
> >
>
> I for one do not like this ambiguity.  Here is a hole into which great
> interoperability problems may someday fall.  Dave, please argue WHY
> the options should be processed EITHER before or after, instead of
> just AFTER.

We are talking here about how to handle something here that is never
supposed to be done.  So it seems to me that we should allow
flexibility for the implementor to handle the case in the manner that
is most convenient for them, rather than making them write extra code
to handle this case in some particular way.

If there are interoperability problems resulting from someone doing
something that the standard says they must not, then it will be clear
whose fault it is.

> Here is Eddie's reason why it should be AFTER:
>
> >I think it is better to do it after the EOR because there might be more
> >TN3270 data than could possibly be buffered up.  It is presumed that the
> >TELNET options could more easily be saved until the EOR is rec'd.
> >Eddie Renoux   [e-mail]
>
> Fred

If you are sending data to the host as you receive it, then I agree
that it might be better to save the Telnet commands until the end of
the block.  (How big will that buffer be, though?) But all
implemenations may not find that the most convenient way.  We are
talking about clients as well as servers.  A client might find it
easiest to reply to the Telnet commands when they are received.

As for a SYSREQ or ATTN in the middle of a 3270 block, you should be
free to ignore such a request.

Now having said all that, I'll say that I am not an implementor of a
TN3270 server or client, although I do have credentials as a system
developer.  If all the implementors of clients and servers on the list
agree that it's just as easy to save the Telnet commands until the end
of the block, then I will retract my objection.  I'm just trying to
insure that the standard is no harder to implement than it has to be.