Re: Newly revised standards-track RFC

[Bill Kelly <[e-mail]>]

Hi,

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.  Any thoughts?
>
> It'll ruffle my feathers...

I had a feeling it might :-)

> First, this is the Telnet protocol.  That means that you always
> have to scan for the IAC in the entire data stream, the sender
> has to double any 255 data bytes, and the receiver has to turn
> any IAC IAC back into a 255 data byte.  It is my understanding
> that the current spec continues to do this within the TN3270E
> data message, and that the issue is what about other Telnet
> commands in the data stream?

Yep.

> I only see two issues.
>         1) Avoiding Telnet commands within a TN3270E data message
>            will allow for faster processing of that data segement.
>         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.
> Are there others?

I think that about sums it up...although I think #2 is the main problem.

> These can be addressed by stating that it is strongly
> recommeneded that Telnet command sequences (other than IAC-IAC)
> should not be sent within a TN3270E data message.  If they
> are, it is undefined (i.e., implementation dependent) how they
> may be processed (e.g, processing may be defered until after
> the TN3270E data message has been processed, requests to enable
> options may be denied).  Since, you have to look for the IAC-IAC
> anyway, recognizing IAC-<foo> should only introduce extra overhead
> when an IAC-<foo> is received.

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).
>
> Instead of:
>
> >    The presence of Telnet commands within a TN3270E data message
> >    (i.e., between the header and the trailing IAC EOR) is not
> >    supported; neither clients nor servers should send such data.  If a
> >    TN3270E data message containing an IAC-command sequence (other than
> >    IAC IAC) is received, the receiver should discard the IAC-command
> >    sequence and continue processing the TN3270E data message.
> >    IAC-commands should be sent between TN3270E data messages, with no
> >    header and no trailing IAC EOR.
>
> 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 makes a lot of sense to me.  How 'bout you other folks?

Thanks,
Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]