Network Working Group Jon Postel (SRI-ARC)
Request for Comments: 719 Jul 76
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)
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.
15-Jul-76 Doug Dodds (BBN-RCC)
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.
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
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