Re: Newly revised standards-track RFC

["David A. Borman" <[e-mail]>]

I've been loosely following the discussion of Telnet commands
in the TN3270E data message, and its probably overdue that I
comment...

> 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...

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?

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?

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.

To just state that any Telnet commands other than IAC-IAC within
the TN3270E data message will be ignored encourages less than robust
implementations.  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.  And who knows, there may be some future Telnet option that
does make sense within a TN3270E data message...

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.

                -David Borman, [e-mail]