    Network Working Group                                     Jon Postel  (SRI-ARC)
    Request for Comments: 719                                                Jul 76
    NIC #36138

                              Discussion on RCTE

    The following is the significant portion of a dialog on RCTE that has
    followed the publication of RFC 718.

    15-Jul-76 Nancy Mimno (BBN-NET)

       Jon,
       I've read RFC718 and have got some comments, in particular with
       respect to the "third problem" or clearing the input buffer part.

       1) I believe the stated implementation is backwards: in the normal
       case of the RCTE mode negotiation, the server sends "WILL RCTE" and
       the user sends ,"DO RCTE"; the reverse case is thus the server sending
       "DO RCTE" and the user "WILL RCTE" Also, it is probably wise to say
       explicitly that the server's sending "DO RCTE" requires the user
       process to respond "WILL (or WON'T) RCTE" and that this response is
       the synchronizing mark.

       2) The problem is a real one and I think the RCTE protocol would be
       better with a "clear input, reset counters" function.  The question is
       Ill now to do it.  In talking with Rav yesterday, I learned that he had
       this in mind as a general function, not restricted to RCTE; in fact,
       TENEX sends the "reverse RCTE" option for "clear your input buffer"
       whether or not the connection is in RCTE mode.  In this case, the
       statement about "cannot be confused with the normal use of the RCTE
       option" will not always be true.  I think we both agreed that the
       current solution should just be an interim one.

       3) I suggest a different way of performing this function, using the
       synch-datamark sequence.  First, the RCTE option would have to
       explicitly require that this function reset the counters and cause a
       "clear your input buffer (of data)", all synchronized with the
       datamark of course.  This is pretty much what it is now except for
       the reset counters; receiving Synch-data mark when in RCTE probably
       needed defining anyhow.  Because RCTE won't work unless both sides
       agree, the "clear input and reset counters" meaning for
       synch-data mark would have to be a mandatory part of the RCTE option.
       Second, since the Synch-data mark is a "one-way" function, there needs
       to be a way for one side of the connection to tell the other side to
       "send me a Synch-data mark".  The New Telnet protocol spec implied that
       Abort Output could be used for that purpose; if hot, then perhaps a
       new function could be defined.  Again, the RCTE option should make
       some explicit statement requiring (or very strongLy recommending)
       this interpretation of AO.  For non-RCTE mode, it's a nice idea but
       probably not required.  Ray has tentatively agreed- thinks it could
       work on Tenex (server side).   I would like your comments and Doug
       Dodds' (Tenex user RCTE).  I don't know of any other existing RCTE
       implementations that would have to change.  I also don't know what it

                                         -1-

       takes to extend official protocols these days, but maybe it's easier
       to do that than define a new option (ie reverse RCTE).

       Regards,
       Nancy

    15-Jul-76 Doug Dodds (BBN-RCC)

       Nancy,

       Your suggestion for the RCTE-clear function being performed by the Au
       command (when RCTE is on) is a good one.  I see no problem with it
       from the side of the Tenex User Telnet (NTELNET).  At present NTELNET
       is ignoring AO (and some other commands) entirely; this is a good
       opportunity to implement it in general.

       Doug

    21-Jul-76 Jon Postel (SRI-ARC)

       I met with Ray Tomlinson for a few minutes to discuss the RCTE-clear
       function and other RCTE features.  We agreed that Nancy's suggestion
       for using the AO command for the clear function made sense.  We also
       determined that the RCTE document should say something about the
       state some other options should be in when using RCTE.  For example we
       believe that GO-AHEAD must be suppressed while RCTE is in use, that
       when one quits RCTE the ECHO mode must be restored to what it was at
       the time of entering RCTE,, and that BINARY and RCTE do not make sense
       as a combination because every byte would have to be assumed to be a
       break character.  We also determined that it is unworkable to use
       RCTE and no break characters since there is no way to get out of that
       state.

    22-Jul-76 Jon Postel (SRI-ARC)

       As a result of the above discussion I will prepare a revised RCTE
       specification document.  A draft will be distributed to interested
       parties for comments and the final document will be published as an
       RFC.

                                         -2-