Subject: Re: Comments on Byte Doubline & Data Stream-Flush

From: "Burton C. Gearhart" <[email-masked]>
Date: Fri, 13 Feb 1998 16:45:06 -0600

Comments for Suppress-Byte-Doubling and Data-Stream-Flush Options
=================================================================

Both Suppress-Byte-Doubling and Data-Stream-Flush options should be
added as
new Telnet negotiated options. This will allow other block mode
protocols,
such as traditional TN3270 and TN5250 to take advantage of the
proposed
option. In another words, a traditional TN3270 vendor who wishes to
support
new proposed options does not have to upgrade his software to
TN3270E in
order to improve the performance and truncated data stream recovery.

The option code for Suppress-Byte-Doubling should be defined as:
  SUPPRESS-BYTE-DOUBLING 41 (0x29)

and option code for Data-Stream-Flush should be defined as:
  DATA-STREAM-FLUSH 42 (0x30).

The current Telnet negotiation rules apply for both new options.
Either side
may negotiate both options after current traditional TN3270, TN5250
or
TN3270E negotiations have been completed.

An example of a successful Suppress-Byte-Doubling option for
traditional
TN3270 would be:

      Server:  IAC DO TERMINAL-TYPE
      Client:  IAC WILL TERMINAL-TYPE
           .             .
           .             .

      Server:  IAC DO EOR IAC WILL EOR
      Client:  IAC WILL EOR IAC DO EOR
      Server:  IAC DO BINARY IAC WILL BINARY
      Client:  IAC WILL BINARY IAC DO BINARY
      Server:  IAC DO SUPPRESS-BYTE-DOUBLING IAC WILL
SUPPRESS-BYTE-DOUBLING
      Client:  IAC WILL SUPPRESS-BYTE-DOUBLING IAC DO
SUPPRESS-BYTE-DOUBLING
           .            .
           .            .

If either side does not support the SUPPRESS-BYTE-DOUBLING option,
then the
former convention still apply and all 0xFF's in the data stream must
be
byte-doubled.

If both side support this option, then each Telnet record must be
preceded by
2 byte data length to indicate the length of the data, including the
two byte
data length but excluding IAC/EOR, guaranteed to NOT contain any
embedded Telnet Commands.

The format of each Telnet record while Suppress-Byte-Doubling option
is
agreed to is as follow:

DATA-LENGTH  DATA

  2 bytes     ..  IAC EOR

If a TN server or client sends a partial chain of data, then the
data length
field MUST contain only the number of bytes actually sent. This mean
the
remainder of the chain MUST be scanned and byte-doubled. Both Client
and
Server can NOT assume that Telnet Command (usually IAC/EOR) is
always
"length" byte from the start of a Telnet record. They must be
prepare to
scan any remaining data, as if Suppress-Byte-Doubling is not agree
to, until
IAC/EOR or IAC/BREAK if Data-Stream-Flush option is agree to.

An example of a successful Suppress-Byte-Doubling option for TN3270E
would
be:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
         .             .
         .             .

      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
      Server:  IAC DO SUPPRESS-BYTE-DOUBLING IAC WILL
SUPPRESS-BYTE-DOUBLING
      Client:  IAC WILL SUPPRESS-BYTE-DOUBLING IAC DO
SUPPRESS-BYTE-DOUBLING
           .            .
           .            .

If either side does not support the SUPPRESS-BYTE-DOUBLING option,
then the
former convention still apply and all 0xFF's in the data stream,
including
the sequence number of TN3270E header, must be byte-doubled.

If both sides support this option, then each Telnet record must be
included a
2 byte data length, after the TN3270E header and before the user
data, to
indicate the length of the data, including the two byte data length
but
excluding IAC/EOR, guaranteed to NOT contain any embedded Telnet
Commands.
The TN3270E header will always be 5 bytes fixed length and no
byte-doubling
is required for sequence number while Suppress-Byte-Doubling is in
effect.

The format of each Telnet record while Suppress-Byte-Doubling option
is
agreed to is as follow:

DATA-TYPE REQ-FLAG     RESPONSE SEQ-NUMBER      DATA-LENGTH  DATA

 1 byte    1byte        1 byte   2 bytes          2 bytes    ..
IAC EOR

If a TN server or client sends a partial chain of data, then the
data length
field MUST contain only the number of bytes actually sent. This mean
the
remainder of the chain MUST be scanned and byte-doubled. Both Client
and
Server can NOT assume that Telnet Command (usually IAC/EOR) is
always
"length" byte from the TN3270E header. They must be prepare to scan
any
remaining data, as if Suppress-Byte-Doubling is not agree to, until
IAC/EOR
or IAC/BREAK if Data-Stream-Flush option is agree to.

An example of a successful Suppress-Byte-Doubling option for TN5250
would be:

      Server:  IAC DO TERMINAL-TYPE
      Client:  IAC WILL TERMINAL-TYPE
           .             .
           .             .

      Server:  IAC DO EOR IAC WILL EOR
      Client:  IAC WILL EOR IAC DO EOR
      Server:  IAC DO BINARY IAC WILL BINARY
      Client:  IAC WILL BINARY IAC DO BINARY
      Server:  IAC DO SUPPRESS-BYTE-DOUBLING IAC WILL
SUPPRESS-BYTE-DOUBLING
      Client:  IAC WILL SUPPRESS-BYTE-DOUBLING IAC DO
SUPPRESS-BYTE-DOUBLING
           .            .
           .            .

If either side does not support the SUPPRESS-BYTE-DOUBLING option,
then the
former convention still apply and all 0xFF's in the data stream must
be
byte-doubled.

If both side support this option, then the logical record length of
TN5250
data stream format must be used as a length field to indicate the
length of
the data, guaranteed to NOT contain any embedded Telnet Commands.

The format of each Telnet record while Suppress-Byte-Doubling option
is
agreed to is the same as RFC1205 stated.

Since the whole record length is sent in the first chain of data,
both Client
and Server CAN assume that Telnet Commands (IAC/EOR or IAC/BREAK,
etc.) is
always "length" byte from the start of a Telnet record.

Notice that the data length field is always the first 2 bytes of a
Telnet
record for traditional TN3270 and TN5250 and TN3270E after removing
the
header when Suppress-Byte-Doubling is agree to, a vendor can
implement all
three protocols using a single code based approach for
Suppress-Byte-
Doubling option.

An example of a successful Data-Stream-Flush option for traditional
TN3270 would be:

      Server:  IAC DO TERMINAL-TYPE
      Client:  IAC WILL TERMINAL-TYPE
           .             .
           .             .

      Server:  IAC DO EOR IAC WILL EOR
      Client:  IAC WILL EOR IAC DO EOR
      Server:  IAC DO BINARY IAC WILL BINARY
      Client:  IAC WILL BINARY IAC DO BINARY
      Server:  IAC DO DATA-STREAM-FLUSH IAC WILL DATA-STREAM-FLUSH
      Client:  IAC WILL DATA-STREAM-FLUSH IAC DO DATA-STREAM-FLUSH
           .            .
           .            .

If both side support this option, then both side must be prepare to
discard
the partially received data up to the last IAC/EOR when Telnet BREAK
command
is received after receiving partial data and before receiving
IAC/EOR. The
receiving party must be treated the Telnet BREAK command as IAC/EOR
and must
be prepare for receiving a new Telnet record after discarding the
partially
received data.

An example of a successful Data-Stream-Flush option for TN3270E
would be:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
         .             .
         .             .

      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
      Server:  IAC DO DATA-STREAM-FLUSH IAC WILL DATA-STREAM-FLUSH
      Client:  IAC WILL DATA-STREAM-FLUSH IAC DO DATA-STREAM-FLUSH
           .            .
           .            .

If both side support this option, then both side must be prepare to
discard
the partially received data up to the last IAC/EOR when Telnet BREAK
command
is received after receiving partial data and before receiving
IAC/EOR. The
receiving party must be treated the Telnet BREAK command as IAC/EOR
and must
be prepare for receiving a new Telnet record after discarding the
partially
received data.

An example of a successful Data_Stream-Flush option for TN5250 would
be:

      Server:  IAC DO TERMINAL-TYPE
      Client:  IAC WILL TERMINAL-TYPE
           .             .
           .             .

      Server:  IAC DO EOR IAC WILL EOR
      Client:  IAC WILL EOR IAC DO EOR
      Server:  IAC DO BINARY IAC WILL BINARY
      Client:  IAC WILL BINARY IAC DO BINARY
      Server:  IAC DO DATA-STREAM-FLUSH IAC WILL DATA-STREAM-FLUSH
      Client:  IAC WILL DATA-STREAM-FLUSH IAC DO DATA-STREAM-FLUSH
           .            .
           .            .

If both sides support this option, then both side must be prepare to
discard
the partially received data up to the last IAC/EOR when Telnet BREAK
command
is received after receiving partial data and before receiving
IAC/EOR. The
receiving party must be treated the Telnet BREAK command as IAC/EOR
and must
be prepare for receiving a new Telnet record after discarding the
partially
received data.

Since the data length field (TN5250 logical record length) always
indicates
the length of Telnet record, the sender must send padded data up to
the
indicated length before sending Telnet BREAK, while
Suppress-Byte-Doubling
option is in effect, to signal the receiver to discard the data up
to the
previous received IAC/EOR.

A.H. Yi
[email-masked]

---

From: Gene Pullen <[email-masked]>
Date: Sat, 14 Feb 1998 15:21:05 -0600

I have inserted some comments.

Gene

Burton C. Gearhart wrote:

> Both Suppress-Byte-Doubling and Data-Stream-Flush options should be added as
> new Telnet negotiated options. This will allow other block mode protocols,
> such as traditional TN3270 and TN5250 to take advantage of the proposed
> option. In another words, a traditional TN3270 vendor who wishes to support
> new proposed options does not have to upgrade his software to TN3270E in

I am glad we agree that Byte-doubling suppression should be a separate option.
Are you
volunteering to write the draft for this option?

I don't really see the need to make the Data Stream Flush function a separate
option so
traditional TN3270 and TN5250 can use it.  Telnet already provides a mechanism
for
this in the Abort Output command.  The problem we are trying to address is the
fact that TN3270E has redefined Abort Output to mean SysReq key inbound
from the client.  This "overloading" of the Abort Output command can lead to
confusion over whether a client is sending a SysReq key or actually aborting the

current/previous buffer.  So the proposed TN3270E Data Stream Flush function is
not trying to define new functionality, it is trying to clear up this confusion
that
is inherent to TN3270E only.  It is doing this by remapping Abort Output to
the Telnet Break command.  Since TN3270 and TN5250 do not remap Abort
Output to SysReq there is no need for this to be available to them.

I guess I need to clarify this in my draft.  Thanks.

> The current Telnet negotiation rules apply for both new options.  Either side
> may negotiate both options after current traditional TN3270, TN5250 or
> An example of a successful Suppress-Byte-Doubling option for traditional
> TN3270 would be:
>
> If either side does not support the SUPPRESS-BYTE-DOUBLING option, then the
> former convention still apply and all 0xFF's in the data stream must be
> byte-doubled.
>
> If both side support this option, then each Telnet record must be preceded by
> 2 byte data length to indicate the length of the data, including the two byte
> The format of each Telnet record while Suppress-Byte-Doubling option is
> agreed to is as follow:
>
> DATA-LENGTH  DATA
>
>   2 bytes     ..  IAC EOR
>
> If a TN server or client sends a partial chain of data, then the data length
> field MUST contain only the number of bytes actually sent. This mean the
> remainder of the chain MUST be scanned and byte-doubled. Both Client and
> Server can NOT assume that Telnet Command (usually IAC/EOR) is always
> "length" byte from the start of a Telnet record. They must be prepare to
> scan any remaining data, as if Suppress-Byte-Doubling is not agree to, until
> An example of a successful Suppress-Byte-Doubling option for TN3270E would be:

> If either side does not support the SUPPRESS-BYTE-DOUBLING option, then the
> former convention still apply and all 0xFF's in the data stream, including
> If both sides support this option, then each Telnet record must be included a
> 2 byte data length, after the TN3270E header and before the user data, to
> indicate the length of the data, including the two byte data length but
> excluding IAC/EOR, guaranteed to NOT contain any embedded Telnet Commands.
> The TN3270E header will always be 5 bytes fixed length and no byte-doubling
> is required for sequence number while Suppress-Byte-Doubling is in effect.
>
> The format of each Telnet record while Suppress-Byte-Doubling option is
> agreed to is as follow:
>
>  1 byte    1byte        1 byte   2 bytes          2 bytes    .. IAC EOR
>

I would prefer to have the Suppress Byte-doubling option ALWAYs use the first
2bytes of a Telnet "record".  This option should NOT have to draw a distinction
between
TN5250, TN3270, and TN3270E data.  It should not care.  That way TN3270E will
remain backward compatible with regard to header size.

> If a TN server or client sends a partial chain of data, then the data length
> field MUST contain only the number of bytes actually sent. This mean the
> remainder of the chain MUST be scanned and byte-doubled. Both Client and
> Server can NOT assume that Telnet Command (usually IAC/EOR) is always
> "length" byte from the TN3270E header. They must be prepare to scan any
> remaining data, as if Suppress-Byte-Doubling is not agree to, until IAC/EOR
> An example of a successful Suppress-Byte-Doubling option for TN5250 would be:
>
> If either side does not support the SUPPRESS-BYTE-DOUBLING option, then the
> former convention still apply and all 0xFF's in the data stream must be
> byte-doubled.
>
> If both side support this option, then the logical record length of TN5250
> data stream format must be used as a length field to indicate the length of
> The format of each Telnet record while Suppress-Byte-Doubling option is
> Since the whole record length is sent in the first chain of data, both Client
> and Server CAN assume that Telnet Commands (IAC/EOR or IAC/BREAK, etc.) is
> Notice that the data length field is always the first 2 bytes of a Telnet
> record for traditional TN3270 and TN5250 and TN3270E after removing the
> header when Suppress-Byte-Doubling is agree to, a vendor can implement all
> three protocols using a single code based approach for Suppress-Byte-
> Doubling option.
>

Again, to me it would be best to think of this option as a 2-byte header that
can beskipped to get to the "generic" data.  Otherwise, you are using cycles to
strip the
TN3270E header unnecessarily.  So the record would always look like:

    2-Byte Suppression Length Header/Generic Data/IAC EOR

Where "Generic Data" can be any type of data stream (TN3270E, TN3270,
TN5250, or other).

> If both side support this option, then both side must be prepare to discard
> the partially received data up to the last IAC/EOR when Telnet BREAK command
> is received after receiving partial data and before receiving IAC/EOR. The
> receiving party must be treated the Telnet BREAK command as IAC/EOR and must
> be prepare for receiving a new Telnet record after discarding the partially
> received data.
>

See my comments above.

> An example of a successful Data-Stream-Flush option for TN3270E would be:
>
>       Server:  IAC DO TN3270E
>       Client:  IAC WILL TN3270E
>          .             .
>          .             .
>
> If both side support this option, then both side must be prepare to discard
> the partially received data up to the last IAC/EOR when Telnet BREAK command
> is received after receiving partial data and before receiving IAC/EOR. The
> receiving party must be treated the Telnet BREAK command as IAC/EOR and must
> be prepare for receiving a new Telnet record after discarding the partially
> received data.
>

TN3270E function negotiation is also more efficient then Telnet option
negotiation.

> An example of a successful Data_Stream-Flush option for TN5250 would be:
>
> If both sides support this option, then both side must be prepare to discard
> the partially received data up to the last IAC/EOR when Telnet BREAK command
> is received after receiving partial data and before receiving IAC/EOR. The
> receiving party must be treated the Telnet BREAK command as IAC/EOR and must
> be prepare for receiving a new Telnet record after discarding the partially
> received data.
>
> Since the data length field (TN5250 logical record length) always indicates
> the length of Telnet record, the sender must send padded data up to the
> indicated length before sending Telnet BREAK, while Suppress-Byte-Doubling
> option is in effect, to signal the receiver to discard the data up to the

It seems IAC Abort Output can be used as currently defined for TN5250 as well.In
any future TN5250(E) standards how to recover should be spelled out,
particularly the padding stuff.  However, padding seems to defeat the purpose of

"aborting" the output.

> [email-masked]

Thanks for your comments.

Gene Pullen