Movatterモバイル変換

Network Working Group                                     Jon Postel  (SRI-ARC)Request for Comments: 719                                                Jul 76NIC #36138                          Discussion on RCTEThe following is the significant portion of a dialog on RCTE that hasfollowed the publication ofRFC 718.15-Jul-76 Nancy Mimno (BBN-NET)   Jon,   I've readRFC718 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,   Nancy15-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.   Doug21-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-