Subject: TN3270E Header Byte-doubling Suppression

From: Gene Pullen <[email-masked]>
Date: Fri, 13 Feb 1998 09:38:17 -0600

All,

Here is the revision of the Byte-doubling issue I promised.  It is not
nearly as broad as some may have wanted.  Marty Williams was charged with
trying to do something within TN3270E to address this issue, and he gave
it a try.  But, he and I have always thought it would be better to do
this as a separate Telnet option.  And several on the list echoed this
sentiment, particularly Derek Bolton.  Thanks, Derek.

So I am proposing that we take care of the piece of byte-doubling
suppression that makes sense in TN3270E and ask for volunteers to
start pulling together a Telnet Byte-doubling suppression option in
a separate draft.  Do we have any volunteers?

I tried to follow RFC in the format of this draft.  So let me know
how I am doing in style and/or substance.

Thanks, Gene
TN3270E Working Group                                                                    G. Pullen
Internet Draft:                                                                      M. Williams
Updates:  RFC 1647                                                        OpenConnect Systems Inc.
                                                                                  10 February 1998

                        TN3270E Functional Extensions

Status of this Memo

        This document is an Internet-Draft. Internet-Drafts are working documents of the
        Internet Engineering Task Force (IETF), its areas, and its working groups. Note that
        the other groups may also distribute working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six months and may be
        updated, replaced or made obsolete by other documents at any time.  It is inappropriate
        to use Internet-Drafts as reference material or to cite them other than as "work in
        progress."

Copyright Notice

        Copyright (C) The Internet Society (1998).  All Rights Reserved.

Intent of Draft

        The intent of this draft is to address one of the issues that were discussed at the
        TN3270E Interoperability Event.  One of the issues discussed was a mechanism to reduce
        the amount of processing required to scan byte-streams to differentiate Telnet data from
        Telnet commands.

TN3270E Header Byte-doubling Suppression

        A performance bottleneck facing Telnet server and client vendors is, any 0xFF within an
        outbound data stream must be byte-doubled (a second 0xFF inserted into the data stream)
        by the sender in order to differentiate actual data from Telnet IAC commands.  The
        receiver of the data stream must then scan through data stream removing the inserted
        0xFF bytes.  With header-based protocols, like TN3270E, Telnet byte-doubling forces the
        header to be variable length, to allow for any 0xFF bytes that may occur within the header.

        From discussions on the TN3270E list, it was determined that Telnet Byte-doubling Suppression
        would best be handled outside of the TN3270E standard as a new Telnet negotiated option.  This
        will allow other block mode protocols (i.e. traditional TN3270, and TN5250) to take advantage
        of the proposed option.

        However, the variable length header issue is within the scope of  the TN3270E standard.  This
        draft proposes a method to make the TN3270E header fixed length by eliminating byte-doubling
        of the 5 header bytes.  This function will extend the TN3270E standard to address this issue.
        Although this function is proposed in anticipation of a new Suppress Byte-doubling Telnet
        option, it is intended to be independent of whether such a Telnet option is negotiated.

Pullen & Williams                       Internet Draft                                        [Page 1]
Internet Draft                  TN3270E Functional Extensions                   10 February 1998

        The Header Byte-doubling Suppression function is a negotiated TN3270E function to maintain
        backward compatibility with clients and servers that do not support the function. TN3270E
        function negotiation rules apply.  Either side may request the addition of the Header
        Byte-doubling Suppression function.  Either side may reject the function by removing it
        from the function list during negotiations.

        The function negotiation code is defined as:

        SUPPRESS-HEADER-BYTE-DOUBLING   5

        The Header Byte-doubling Suppression function support is enabled by the negotiation below:

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

        Support is disabled by the negotiation below (the server does not support the Header
        Byte-doubling Suppression function):

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

        When the SUPPRESS-HEADER-BYTE-DOUBLING function is enabled the TN3270E header
        will never be byte-doubled in either direction (client to server/server to client).
        Therefore, the size of the TN3270E header will ALWAYS be 5 bytes when the Header
        Byte-doubling function is in effect.

        The sender of a TN3270E message guarantees that the first five (header) bytes of the record
        will not contain any embedded Telnet commands.  The sender must byte-double the data portion
        of the TN3270E message.

        The receiver of the message must validate that the message received does begin with a valid
        TN3270E header, to avoid misinterpreting asynchronous Telnet command packets between
        TN3270E records.  The receiver must also be cognizant of whether a TN3270E header is
        expected to avoid problems that may occur if bytes in the middle of a chain of buffers
        are not scanned properly.  When the receiver has determined that a valid TN3270E header
        is present it must skip past the header to begin scanning for byte-doubled 0xFF
        characters.

Pullen & Williams                       Internet Draft                                        [Page 2]
--------------------------------------------------------------------------
      OOOO   CCCC   SSSS            Gene B. Pullen ([email-masked])
    OO  OO CC  CC SS  SS            Senior Software Engineer
   OO  OO CC     SS                 OpenConnect Systems, Inc.
  OO  OO CC       SS                2711 LBJ Freeway, Dallas, TX  75234
 OO  OO CC         SS               Tel: (972)888-0600  Fax: (972)888-0686
OO  OO CC  CC SS  SS
OOOO   CCCC   SSSS  "Transforming Separate Networks Into Seamless Systems"
==========================================================================