GENWiki

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-