Browse Prior Art Database

Discussion on RCTE (RFC0719)

IP.com Disclosure Number: IPCOM000003764D
Original Publication Date: 1976-Jul-22
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Abstract

The following is the significant portion of a dialog on RCTE that has followed the publication of RFC 718.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 58% of the total text.

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 no...