Comments on the RCTE Telnet option(2)

　　Ideal channel utilization might be achieved, since no "unnecessary"　packets are sent (and, strangely, no extra characters are allowed in　the current packet) but the overlap of I/O and computation has been　eliminated, and the human has an extra round-trip time added to the　server's processing time. This is wrong.

　　An Alternative Implementation

　　Unless a round-trip time penalty is to be paid by the human at every　break interaction, the user TELNET must transmit characters based on　the transmission character set in effect at the moment the characters　are typed. And unless the step-by-step interaction developed in the　RCTE TENEX example was not a true representation of the relative　temporal occurances of events, RCTE did not do this.

　　The sample TENEX interaction showed the user typing

　　(T:) LOGIN ARPA

　　while the break set included and . The only　transmission characters in effect were the break characters - by　default. The RCTE example showed that the LOGIN phrase　was, properly, a completed command; it was transmitted. But　while the alternative transmission strategy of the current RFC　would "recognize" the ARPA phrase as a second completed　command, and thus initiate a second transmission, RCTE withholds　judgment until the server respecifies the transmission classes.　Response for the user suffers.

　　One might also ask what transmission strategy was to be undertaken　when two users were, say, linked thru a TENEX. Transmission　should obviously be at every character. RCTE would send the first　single character packet and then wait to be sure that a single　character did in fact delimit the next command also. It would　wait a long time it would seem, since no break interaction would　occur until the end of the line (). The user would be echoing　like a champ, but no characters would be transmitted for the　linked party's inspection.

　　If we adopt the convention that transmission decisions should be　based on the transmission set [and by default, the break set] in　effect at the time the character is typed, then the sample　interaction might in fact look like this:

　　P: TENEX 1.31.18, TENEX EXEC 1.50.2 @

　　T: LOGIN

　　P: LOGIN } >>>>>>NOTE: Typing and printing occurs simul-

　　U: LOGIN taneously up to the at　which point the human "types-ahead."

　　T: ARPA

　　U: ARPA <

　　S: <0>

　　P: AR

　　S: (PASSWORD): <7>

　　[the server sends while text is printing]

　　P: PA (PASSWORD):

　　T: WASHINGTON

　　U: WASHINGTON

　　T: 100

　　S: <3>

　　P: 100

　　T: 0 [Again printing is

　　simultaneous to typing]

　　P: 0

　　T:

　　P:

　　U: 1000

　　S: JOB ...

　　The interaction will not necessarily be the same each time. It　depends on the typing speed of the user and response time of the　server. For this example, both channel utilization and performance　for the human are perfect, since the transmission set [even though　it was only the default break set] did not change.

　　Unsolicited Output

　　The question of unsolicited output arise again. The treatment in 560　was simplified over that of 357 only because of the RCTE transmission　strategy. No output could possibly be returning for a command which　hasn't been sent yet (!), so the message must be "SYSTEM GOING　DOWN."

　　RFC357outlines when unsolicited output can be recognized and when　it should be printed, in line with the alternate transmission scheme　proposed. The requirement that such system alerts be terminated by　RCTE commands is of course the proper way to handle such interrupts;　this clarification of the unsatisfactory solution in 357 is　appreciated.

　　TIP Buffering

　　RCTE as defined cannot allow a user to transmit when his buffer is　full, else he might send a break character. [presumably the buffer　fills because we are waiting for break (transmission) redefinition].

　　The response to the command delimited by the break character could　return before the characters, of the command were "echoed." RCTE　would thus demand that it be printed first, and the listing would be　out of order.

　　The alternative transmission strategy eliminates this problem since　transmission of a full buffer is no worse than guessing incorrectly　that the last character in the buffer is a transmission character.

　　A further suggestion

　　All server-to-user echoing could be eliminated if control bytes were　sent to indicate which break sets should be echoed and which　shouldn't.

　　Endnotes

　　[1] for example: statement 2E2F does not properly distinguish　between the "occurrence" of a break character and the "occurrence" of　a Transmission character. The present RFCshows that they are　fundamentally different.