Re: Newly revised standards-track RFC

[[e-mail]]

> On Thu, 31 Mar 1994, David A. Borman wrote:
>
> > > Another thing I've been wondering about is whether or not our summarily
> > > throwing away Telnet commands like this is going to ruffle feathers among
> > > the "Telnet traditionalists" out there...
>
> >         2) Some telnet commands imply a point in the data stream
> >            that something is to be done, that may be ambiguous or
> >            not make sense within a TN3270E data message.
>
> ...I think #2 is the main problem...
>
> Yes.  The fact that we are still requiring scanning for IACs (even if it
> were only to find IAC-IAC) irks some of the vendors, I think.  But given
> the requirement for that scanning, I see little additional overhead in
> looking for the "<foo>"s.
>
> > ...If some implementation actually does insert Telnet
> > commands into the TN3270E data message, either intentionally or
> > accidently, it can lead to problems.  If the client sent "IAC DO FOO"
> > within the data message, and the server just ignored it, the client
> > will hang if it is waiting for the "IAC WILL FOO" or "IAC WONT FOO"
> > response.
>
> Again, I agree.
>
> > I have no problem with trying to discourage Telnet commands from being
> > sent within a TN3270E data message, but to mandate that any any Telnet
> > commands within a TN3270E data message other than IAC-IAC will be
> > ignored seems to be wrong.  It would be much better to recommend that
> > Telnet commands not be sent within the TN3270E data message, along with
> > a short description of why (e.g., ambiguity and performance).
> >
> > How about something like:
> >
> >    The presence of Telnet commands within a TN3270E data message
> >    (i.e., between the header and the trailing IAC EOR) is not
> >    recommended; neither clients nor servers should send such data.
> >    IAC-commands should be sent between TN3270E data messages, with no
> >    header and no trailing IAC EOR.  If a TN3270E data message
> >    containing an IAC-command sequence (other than IAC IAC) is received,
> >    it is implementation dependent how the IAC-command sequence will be
> >    processed; the processing may be defered until after the current
> >    TN3270E data message has processed.  (Any IAC-command sequence that
> >    is received within a TN3270E data message that would normally require
> >    response must be responded to at some point to avoid the potential
> >    for deadlocks. Any IAC-command that does not require a response
> >    may just be ignored.)
> >
> > The goal is to encourage the spirit of not having arbitrary Telnet
> > command sequences within the TN3270E data message, while making sure
> > that if they do happen, that implementations will be robust enough
> > to deal with them and that the protocol processing will remain
> > deterministic.
>

This language is not strong enough and precise enough for me.  How about
saying that IAC sequences (other than IAC-IAC) WILL be handled as if they
appeared AFTER the IAC EOR if they appear inside a TN3270E frame.
For this reason, they SHOULD be sent outside a TN3270E frame.

Fred