doc: Add RFC documents

1 files changed, 115 insertions, 0 deletions

diff --git a/doc/rfc/rfc719.txt b/doc/rfc/rfc719.txt
new file mode 100644
index 0000000..506383e
--- /dev/null
+++ b/doc/rfc/rfc719.txt
@@ -0,0 +1,115 @@
+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-
+