home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc719.txt < prev    next >
Text File  |  1992-10-14  |  5KB  |  116 lines
  1. Network Working Group                                     Jon Postel  (SRI-ARC)
  2. Request for Comments: 719                                                Jul 76
  3. NIC #36138
  4.  
  5.  
  6.  
  7.  
  8.                           Discussion on RCTE
  9.  
  10. The following is the significant portion of a dialog on RCTE that has
  11. followed the publication of RFC 718.
  12.  
  13. 15-Jul-76 Nancy Mimno (BBN-NET)
  14.  
  15.    Jon,
  16.    I've read RFC718 and have got some comments, in particular with
  17.    respect to the "third problem" or clearing the input buffer part.
  18.  
  19.    1) I believe the stated implementation is backwards: in the normal
  20.    case of the RCTE mode negotiation, the server sends "WILL RCTE" and
  21.    the user sends ,"DO RCTE"; the reverse case is thus the server sending
  22.    "DO RCTE" and the user "WILL RCTE" Also, it is probably wise to say
  23.    explicitly that the server's sending "DO RCTE" requires the user
  24.    process to respond "WILL (or WON'T) RCTE" and that this response is
  25.    the synchronizing mark.
  26.  
  27.    2) The problem is a real one and I think the RCTE protocol would be
  28.    better with a "clear input, reset counters" function.  The question is
  29.    Ill now to do it.  In talking with Rav yesterday, I learned that he had
  30.    this in mind as a general function, not restricted to RCTE; in fact,
  31.    TENEX sends the "reverse RCTE" option for "clear your input buffer"
  32.    whether or not the connection is in RCTE mode.  In this case, the
  33.    statement about "cannot be confused with the normal use of the RCTE
  34.    option" will not always be true.  I think we both agreed that the
  35.    current solution should just be an interim one.
  36.  
  37.    3) I suggest a different way of performing this function, using the
  38.    synch-datamark sequence.  First, the RCTE option would have to
  39.    explicitly require that this function reset the counters and cause a
  40.    "clear your input buffer (of data)", all synchronized with the
  41.    datamark of course.  This is pretty much what it is now except for
  42.    the reset counters; receiving Synch-data mark when in RCTE probably
  43.    needed defining anyhow.  Because RCTE won't work unless both sides
  44.    agree, the "clear input and reset counters" meaning for
  45.    synch-data mark would have to be a mandatory part of the RCTE option.
  46.    Second, since the Synch-data mark is a "one-way" function, there needs
  47.    to be a way for one side of the connection to tell the other side to
  48.    "send me a Synch-data mark".  The New Telnet protocol spec implied that
  49.    Abort Output could be used for that purpose; if hot, then perhaps a
  50.    new function could be defined.  Again, the RCTE option should make
  51.    some explicit statement requiring (or very strongLy recommending)
  52.    this interpretation of AO.  For non-RCTE mode, it's a nice idea but
  53.    probably not required.  Ray has tentatively agreed- thinks it could
  54.    work on Tenex (server side).   I would like your comments and Doug
  55.    Dodds' (Tenex user RCTE).  I don't know of any other existing RCTE
  56.    implementations that would have to change.  I also don't know what it
  57.    
  58.                                      -1-
  59.  
  60.    takes to extend official protocols these days, but maybe it's easier
  61.    to do that than define a new option (ie reverse RCTE).
  62.  
  63.    Regards,
  64.    Nancy
  65.  
  66.  
  67.  
  68. 15-Jul-76 Doug Dodds (BBN-RCC)
  69.  
  70.    Nancy,
  71.  
  72.    Your suggestion for the RCTE-clear function being performed by the Au
  73.    command (when RCTE is on) is a good one.  I see no problem with it
  74.    from the side of the Tenex User Telnet (NTELNET).  At present NTELNET
  75.    is ignoring AO (and some other commands) entirely; this is a good
  76.    opportunity to implement it in general.
  77.  
  78.    Doug
  79.  
  80.  
  81.  
  82.  
  83. 21-Jul-76 Jon Postel (SRI-ARC)
  84.  
  85.    I met with Ray Tomlinson for a few minutes to discuss the RCTE-clear
  86.    function and other RCTE features.  We agreed that Nancy's suggestion
  87.    for using the AO command for the clear function made sense.  We also
  88.    determined that the RCTE document should say something about the
  89.    state some other options should be in when using RCTE.  For example we
  90.    believe that GO-AHEAD must be suppressed while RCTE is in use, that
  91.    when one quits RCTE the ECHO mode must be restored to what it was at
  92.    the time of entering RCTE,, and that BINARY and RCTE do not make sense
  93.    as a combination because every byte would have to be assumed to be a
  94.    break character.  We also determined that it is unworkable to use
  95.    RCTE and no break characters since there is no way to get out of that
  96.    state.
  97.  
  98. 22-Jul-76 Jon Postel (SRI-ARC)
  99.  
  100.    As a result of the above discussion I will prepare a revised RCTE
  101.    specification document.  A draft will be distributed to interested
  102.    parties for comments and the final document will be published as an
  103.    RFC.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.                                      -2-
  115.  
  116.