RFC 726
Remote Controlled Transmission and Echoing Telnet option
Title Block β¨
Okay bestie, the header facts first, because they're the foundation π«Ά
- RFC number: 726, in the NWG series, with NIC number 39237
- Title: Remote Controlled Transmssion & Echoing Telnet Option (the body spells it "Transmssion" too, so that's how it's written, typo and all π)
- Authors: Jon Postel (SRI-ARC) & Dave Crocker (UC Irvine) π
- Date: 8 March 1977 πΈ
- Category or status: the header doesn't say one π€·ββοΈ
- Obsoletes or updates: the header doesn't list anything it obsoletes or updates π¦
1. Command name and code: π
RCTE 7 π
2. Command meanings: π
IAC WILL RCTE π₯
The sender of this command REQUESTS or AGREES to use the RCTE option, and will send instructions for controlling the other side's terminal printer. It's giving "I want in and I'll be the one bossing your printer around" π
IAC WON'T RCTE π ββοΈ
The sender of this option REFUSES to send instructions for controlling the other side's terminal printer. Hard pass, not interested π
IAC DO RCTE β¨
The sender REQUEST or AGREES to have the other side (sender of WILL RCTE) issue commands which will control his (sender of the DO) output to the terminal printer. So this one is the reverse flow: "yes, you can drive my printer" π§
IAC DON'T RCTE π
The sender of this command REFUSES to allow the other side to control his (sender of DON'T) terminal printer. Absolutely not, my printer is MINE π€
IAC SB RCTE ...
Here's the big one, the sub-command format π
IAC SB RCTE <cmd> [BC1 BC2] [TC1 TC2] IAC SE
Where:
<cmd> is one 8-bit byte with the following flags (bits are counted from the right) π
Bit Meaning
0 0 = Ignore all other bits in this byte and
repeat the last <cmd> that was sent. Equals
a 'continue what you have been doing'.
1 = Perform actions as indicated by other bits
in this byte.
1 0 = Print (echo) break character
1 = Skip (don't echo) break character
2 0 = Print (echo) text up to break character
1 = Skip (don't echo) text up to break character
3 0 = Continue using same classes of break
characters.
1 = The two 8-bit bytes following this byte
contain flags for the new break classes.
4 0 = Continue using same classes of transmit
characters.
1 = Reset transmit classes according to the two
bytes following 1) the break classes bytes,
if the break classes are also being reset,
or 2) this byte, if the break classes are
NOT also being reset.
Now the decimal values of the <cmd> byte and what each one means π§
0 = Continue what you have been doing
1 = Print (echo) up to AND INCLUDING break character
3 = Print up to break character and SKIP (don't echo)
break character
5 = Skip text (don't echo) up to break character, but
PRINT break character
7 = Skip up to and including break character
Okay, the rule here is that even numbers above zero (aka the rightmost bit is off) are an error, and they SHOULD be read as zero. And when <cmd> is an even number above zero, you MUST NOT send TC1 TC2 and/or BC1 BC2. Bestie, that's a whole vibe check π
Now you add one of those non-zero values to one of these, to get the total decimal value for the byte. Classes can't get reset without the printing action being reset too, so the total always ends up odd πΈ
8 = Set break classes (using the next two bytes [BC1
BC2])
16 = Set transmission classes (using the next two
bytes [TC1 TC2])
24 = Set break classes (using the next two bytes [BC1
BC2]) and the transmission classes (using the two
bytes after that [TC1 TC2]).
Sub-commands (IAC SB RCTE...) are only sent by the controlling host, and besides their other jobs, they functionally replace the Go-Ahead feature (IAC GA). RCTE also functionally replaces the Echo option (IAC ECHO). So the Suppress Go-Ahead option SHOULD be in force, and the Echo option SHOULD NOT be in force while RCTE is in use. When you stop using RCTE, the echo mode SHOULD be the default state, which is DON'T ECHO, WON'T ECHO π«Ά
Next up are the classes for break and transmission characters. The right-most bit of the second byte (TC2 or BC2) is class 1, and the left-most bit of the first byte (TC1 or BC1) is the currently undefined class 16 π¦
- Class 1: Upper-Case Letter (A-Z)
- Class 2: Lower-case Letters (a-z)
- Class 3: Numbers (0-9)
- Class 4: Format Effectors (
<BS> <CR> <LF> <FF> <HT> <VT>)- The sequence
<cr><lf>counts as one character when it's processed as the Telnet end of line, and it's a single break character when class 4 is set. The sequence<cr><nul>counts as one character, and it's a break character if and only if<cr>is a break character (aka class 4 is set).
- The sequence
- Class 5: Non-format Effector Control Characters including
<DEL>and<ESC> - Class 6:
. , ; : ? ! - Class 7:
{ [ ( < > ) ] } - Class 8:
' " / \ % @ $ & # + - * = ^ _ | ~ - Class 9:
<Space>
And Telnet commands (IAC . . .) sent by the user always count as a break character. Every instance of an IAC is treated as a break character, except the sequence IAC IAC π₯
For display, the visible characters (classes 1, 2, 3, 6, 7, and 8) are shown the obvious way. Space (class 9) shows up as a blank space. The format effectors (class 4) do their format effect. The non-format effector controls (class 5) print nothing, not even a space π
Initially, no break classes or transmission classes are in effect β¨
Heads up, this is a big one: if all the bits are set in a Telnet subcommand argument byte, like TC2 or BC2, then that byte MUST be preceded by an <IAC> flag byte. It's the usual trick of doubling the escape character so its value gets used as data π
Sub-commands (IAC SB RCTE...) are referred to as "break reset commands" π
3. Default: πΈ
WON'T RCTE -- DON'T RCTE
Neither host asserts special control over the other host's terminal printer. Nobody's taking the wheel by default π§
4. Motivation for the option: π
RFC's 1, 5 and 51 discuss network and process efficiency and smoothness, so that's the background energy πΏ
RFC 357, by John Davidson, brings up the echoing delay that happens when a remote user is on a full-duplex host through a satellite link. To save the many thousands of miles of transit time for each echoed character, while still keeping full server responsiveness and clean terminal output, an echo control similar to what some time-sharing systems use is suggested for the whole Network. The main-character-energy move π
In effect, this option has a using host carefully regulate its local terminal printer according to explicit instructions from the remote (serving) host π§
Another important issue is efficient Network transmission. If you implement the Davidson Echoing Scheme, you'll eliminate almost all server-to-user echoing π
The option in this document also asks using hosts to buffer a terminal's input to the serving host until it forms a useful unit. A "useful unit" is delimited by break or transmission characters, as described below. So fewer messages get sent on the user-to-server path β¨
N.B.: This option is only intended for use with full-duplex hosts. The Go-Ahead Telnet feature is completely adequate for half-duplex server hosts. Also, RCTE SHOULD be used in place of the ECHO Telnet option. That is, the Suppress Go-Ahead option SHOULD be in force and the Echo option SHOULD NOT be in force while the RCTE option is in use. π
5. Explicit description of control mechanism: π₯
User Terminal Printing Action & Control Procedure π
First, negotiate the use of the RCTE option. Once the option is in force, the user Telnet follows this procedure π
- Read an item from the network.
- If the item is data, then print it and go to 1.
- If the item is a command, then set the classes and go to 2.
- If the terminal input buffer is empty, then go to 3, else go to 4.
- Wait for an item to appear either from the terminal or from the network.
- If an item appears from the terminal, then go to 4.
- If a data item appears from the network, then print it and go to 3.
- If a command appears from the network, then an error has occured.
- Read an item from the terminal input buffer.
- If the item is not a break, then print/skip it and go to 2.
If the item is a break, then print/skip it and go to 1. Bestie, that's the whole plan for break characters π
Note: Output from the server host can happen at any time, and that "spontaneous output" gets printed in step 3 πΈ
Explanation:
Okay so both hosts agree to use the RCTE option π«Ά After that, the using host (IAC DO RCTE) just acts on the controlling (serving) host's commands. It doesn't send any RCTE commands unless and until it decides to stop allowing the option, which it does by sending IAC DON'T RCTE π
- The using host is synchronized with the server by initially, and whenever it returns to step 1, suspending terminal echo printing until it receives a command from the server. β¨
The server may send either output to the terminal printer or a command, and usually sends both.
The server may send output to the terminal printer either in response to user input or spontaneously. In the former case, the output is processed in step 1. In the latter case, the output is processed in step 3.
Server sends an RCTE command. The command may redefine break and transmission classes, the action to be performed on break characters, and the action to be performed on text. Each of these independent functions is controlled by separate bits in the <cmd> byte. π¦
A transmission character is one which RECOMMENDS that the using host transmit all text accumulated up to and including its occurrence. (For network efficiency, using hosts are DISCOURAGED (but not prohibited) from sending before the occurrence of a transmission character, as defined at the moment the character is typed). π
If the transmission classes bit (bit 4) is on, the two bytes following the two break classes bytes (or immediately following the <cmd> byte, if the break classes bit is not on) will indicate what classes are to be enabled.
If the bit is OFF, the transmission classes remain unchanged. When the RCTE option is first initiated, NO CLASSES are in effect. That is, no character will be considered a transmission character. (As if both TC1 and TC2 are zero.) π
A break character REQUIRES that the using host transmit all text accumulated up to and including its occurrence, and also causes the using host to stop its print/discard action upon the user's input text, until directed to do otherwise by another IAC SB RCTE <cmd> IAC SE command from the serving host. Break characters therefore define printing units. "Break character" as used in this document does NOT mean Telnet Break character. π₯
If the break classes bit (bit 3) is on, the two bytes following <cmd> will indicate what classes are to be enabled. There are currently nine (9) classes defined, with room for expansion.
If the bit is OFF, the break classes remain unchanged. When the RCTE option is initiated, NO CLASSES are to be in effect. That is, no transmission will take place in the user to server direction until the first break reset command is received by the user from the server. π
The list of character classes used to define break and transmission classes is listed at the end of this document, in the Tables Section. π
Because break characters are special, the print/discard action that should be performed upon them is not always the same as the action that should be performed upon the rest of the input text. π
For example, while typing a filename to TENEX, I want the text of the filename to be printed (echoed), but I do not want the <escape> (if I use the name completion feature) to be printed.
If bit 1 is ON, the break character is NOT to be printed.
A separate bit (bit 2) signals whether or not the text itself should be printed (echoed) to the terminal. If bit 2 = 0, then the text IS to be printed.
Yet another bit (bit 0, the right-most bit) signals whether or not any of the other bits of the command should be checked. If this bit is OFF, then the command should be interpreted to mean "continue whatever echoing strategy you have been following, using the same break and transmission classes." π§
- The user Telnet now checks the terminal input buffer. If it contains data, the data is processed in step 4. Otherwise, the user Telnet waits in step 3 for further developments. πΈ
- The user Telnet waits until either the human user enters some data, in which case Telnet proceeds to step 4, or an item is received from the network. If the item from the network is data, it is spontaneous output and is printed, and Telnet then continues to wait. If the item from the network is a command, then an error has occurred. In this case, the user Telnet may attempt to resynchronize the use of RCTE as indicated below. π
- Items from the terminal are processed with printing controlled by the settings of the latest break reset command. When a break character is processed, the cycle of control is complete and action re-commences at step 1. π
Input from the terminal is (hopefully) buffered into units ending with a transmission or break character. Echoing of input text is suspended after the occurrence of a break character, and until receipt of a break reset command from the serving host. The most recent break reset command determines the break actions. β¨
In summary, what is required is that for every break character sent in the user to server direction, there be a break reset command sent in the server to user direction. The user host initially has no knowledge of which characters are break characters, so it starts in a state that assumes that there are no break characters and also that no echoing is to be provided. The server host is expected to send a break reset command to establish the break classes and the echoing mode before it receives any data from the user. π«Ά
Synchronization and Resynchronization:
The serving and using hosts must carefully synchronize break reset commands with the transmission of break characters. Except at the beginning of an interaction, the serving host may only send a break reset command in response to the using host's having sent a break character, as defined at that time. This should establish a one-to-one correspondence between them. (A <cmd> value of zero, in this context, is interpreted as a break classes reset to the same class(es) as before.) The break reset command may be preceded by terminal output. π¦
The re-synchronization of the break characters and the break reset commands is done via the exchange of the Telnet signal Abort Output (AO) in the server to user direction, and the SYNCH in the user to server direction. π
Suppose the server wants to resynchronize the break characters and the break reset commands. π
- a. The server should be sure all output to the terminal has been printed, by using, for example, the Timing Mark Option.
- b. The server sends the
AOsignal. - c. The user receives the
AOsignal. The user flushes all user to server data, whether it has been echoed or not. The user sends aSYNCHto the server. [TheSYNCHconsists of the Telnet Data Mark (DM) and the host-to-host interrupt (INS).] The user now enters the initial state at step 1. - d. The server receives the
SYNCHand flushes any data preceding theDM(as always). The server now sends a break reset command. (Actually, the break reset command could be sent at any time following theAO.) π₯
Suppose the user wants to resynchronize the break characters and the break reset commands. π
- a. The user should discard all user to server data, whether it has been echoed or not.
- b. The user sends the
AOsignal. The user now enters the algorithm at step 1. - c. The server receives the
AOsignal. The server discards all data buffered but not yet sent to the user. The server sends aSYNCHto the user. The server sends a break reset command to the user. π
Notes and Comments:
Even-numbered commands, greater than zero, are in error, since they will have the low-order bit off. The command should be interpreted as equal to zero, which means that any classes reset bytes ([TC1 TC2] [BC1 BC2]) will be in error. (The IAC SE at the end of the command eliminates any parsing problems due to this error.) π
Serving hosts will generally instruct using hosts not to echo break characters, even though it might be alright to echo most break characters. For example, <cr> is usually a safe character to echo, but <esc> is not. TENEX Exec is willing to accept either during filename specification. Therefore, the using host must be instructed not to echo any break characters. π§
- This is generally a tolerable problem, since the serving host has to send an RCTE command at this point anyhow. Adding an echo for the break character to the message will not cause any extra network traffic. πΈ
The RCTE Option entails a rather large overhead. In a true character-at-a-time situation, this overhead is not justified. But on average, it should result in significant savings, both in network traffic and host wake-ups. π
In the sample dialogues below, <cr> means carriage return, <lf> means linefeed, <sp> means space, and <IAC>, <SB>, <SE> and <WILL>/<DO> are Telnet command bytes, all kept exactly as the spec writes them.
Okay so, bestie, there are no mandatory transmission constraints π«Ά. The using host is totally allowed to send one character at a time, but ngl that would be such a waste of RCTE π. The transmission class commands are GUIDELINES, not rules, so going off-script (like when the user's buffer gets full) is allowed β¨.
The using host is also allowed to send a break class character without even knowing it's one, kind of like with type-ahead π.
If the user implementation is clever, it can send the user's typed data to the server before it's actually needed. This type-ahead data may contain break characters.
Let's say only space counts as a break character. That means the last break reset command specified "print up to and including the break characters" and set the break classes to class 9. Now suppose the user typed abc<space>def<esc>ghi<cr>. The user-side RCTE could send all of it to the server, but it could only print abc<space>. It would have to buffer def<esc>ghi<cr> at least until a break reset command arrives from the server π§. That break reset command could change the break classes, which means the buffered string would need to be rescanned π.
For example, say the break reset command sets the break characters to class 5, with the action "print up to but not including the break character." The user RCTE could then print def and discard the <esc>, but it would have to keep buffering ghi<cr> π.
Buffering gets messy when printing on the user's terminal has to be suspended. That happens after the user has typed a currently valid break character and before a break reset command comes in from the serving host. During that time, the user may be typing merrily along π. The text being typed may already be SENT, but it may not be PRINTED yet.
The more common problem is filling up the transmission buffer while waiting for a host-to-host allocate from the serving host. That can happen too, but implementors already know all about it, and it's in no way special to RCTE π .
Either way, when the buffer does fill up and further text the user types will be lost, the user should be notified, maybe by ringing the terminal bell π.
Text should be buffered by the using host until the user types a character that belongs to the transmission class in force at the moment that character is typed π.
The serving host can send transmission class reset commands at any time. If they're sent often, separate from break class reset commands, it'll probably be better to exit RCTE and go back to regular character-at-a-time transmission πΈ.
It's not immediately clear what the using host should do with text it's already buffered when a transmission classes reset command arrives. The buffering was done under the previous transmission classes scheme π€.
The using host clearly should not just wait until a transmission character (under the new scheme) gets typed π.
Instead, either the buffered text gets rescanned under the new scheme, or the buffered text gets sent as a group. Sending as a group is the simpler approach, and it's probably quite adequate β¨.
It is possible to define no break characters except Telnet commands (IAC ...). That seems undesirable, and it's something we should avoid π
ββοΈ.
If that situation did happen, the using host should send a Telnet command so the server knows when it's allowed to reset the break classes. But the mechanism is awkward, so this case should be avoided too π.
6. Sample Interaction β¨
Here's the key to reading the examples, bestie ποΈ:
S:is sent from the serving (WILL RCTE) host to the using host.U:is sent from the using (DO RCTE) host to the serving host.T:is typed by the terminal user.P:is printed on the terminal.
Text inside square brackets ([]) is commentary. Text inside angle brackets (<>) is a single unit. For example, carriage return is <cr>, and the decimal value 27 is written <27>.
This interaction shows a logon to a Tenex, starting up the DED editor, inserting some text, and returning to the Exec level π₯οΈ.
An attempt has been made to give some flavor of the asynchrony of network I/O and the user's terminal input. Lots of other combinations, using the same set of actions listed here, could be made up. The actual order of events depends on the network and the hosts' load, plus how fast the user types πββοΈ.
We assume the user's Telnet is also in an "insert linefeed" mode. That means whenever the user types carriage return <cr>, the user Telnet sends both carriage return and linefeed, <cr><lf> (the Telnet end-of-line signal). When a space character sits at the end of a line in this example, it's shown explicitly as <sp> so it doesn't get confusing. Other spaces aren't marked, so the example stays readable π.
A Telnet connection is already open, but the TENEX prompt hasn't been issued yet. The hosts first talk about the RCTE option π€:
S: <IAC><WILL><RCTE>
U: <IAC><DO><RCTE>
S: TENEX 1.31.18, TENEX EXEC 1.50.2<cr><lf>@
<IAC><SB><RCTE><11><1><24><IAC><SE>
[Print the herald and echo input text up to a break character, but do not echo the break character. Classes 4 (Format Effectors), 5 (Non-format Effector Controls and <DEL>), and 9 (<sp>) act as break characters.] π
P: TENEX 1.31.18, TENEX EXEC 1.50.2<cr><lf>@
T: LOGIN ARPA<cr>
P: LOGIN
U: LOGIN<sp>
U: ARPA<cr><lf>
S: <sp><IAC><SB><RCTE><0><IAC>SE>
P: <sp>ARPA
S: <cr><lf>(PASSWORD): <IAC><SB><RCTE><7><IAC><SE>
P: <cr><lf>(PASSWORD):<sp>
T: WASHINGTON 1000<cr>
[The password "WASHINGTON" is not echoed. Printing of "1000<cr>" is withheld.] π
U: WASHINGTON<sp>
U: 1000<cr><lf>
S: <sp><IAC><SB><RCTE><3><IAC><SE>
S: <cr><lf>JOB 17 ON TTY41 7-JUN-73 14:13<cr><lf>@
<IAC><SB><RCTE><0><IAC><SE>
P: <sp>1000
[Printing is slow at this point, so the account number isn't printed as soon as the server's command for it arrives.] π’
P: <cr><lf>JOB 17 ON TTY41 7-JUN-73 14:13<cr><lf>@
T: DED<esc><cr>
P: DED
U: DED<esc>
S: .SAV;1<IAC><SB><RCTE><0><IAC><SE>
P: .SAV;1
U: <cr><lf>
S: <cr><lf><lf>DED 3/14/73 DRO,KRK<cr><lf>:
<IAC><SB><RCTE><15><1><IAC><255><IAC><SE>
[The program starts and the DED prompt ":" is sent. At the command level, DED responds to every character. The server sets the break classes to all classes.] π₯
P: <cr><lf><lf>DED 3/14/73 DRO,KRK<cr><lf>:
T: IThis is a test line.<cr>This is another test
line.<^Z>Q
["I" means Insert Text. The text follows, terminated by a Control-Z. The "Q" instructs DED to Quit.] π
U: I
U: This is a test line.<cr><lf>
S: I<cr><lf>*<IAC><SB><RCTE><11><0><24><IAC><SE>
[DED prompts the user, during text input, with an asterisk at the beginning of every line. The server sets the break classes to classes 4 and 5, the format effectors and the non-format effector controls.] π
P: I<cr><lf>*This is a test line.
S: <cr><lf>*<IAC><SB><RCTE><0><IAC><SE>
P: <cr><lf>*This is another test line.
U: This is another test line.<^Z>
U: Q
[Note that the "Q" won't be printed on the terminal right away, since it has to wait for authorization.] β³
S: ^Z<cr><lf>:<IAC><SB><RCTE><15><1><IAC><255><IAC><SE>
[The returned "^Z" is two characters, not the ASCII Control-Z or <sub>.] π
S: Q<cr><lf>@<IAC><SB><RCTE><11><1><24><IAC><SE>
P: Q<cr><lf>@
And the user is back at the Exec level ππ
π¦ where this page comes from
- ietf: rfc726 1977-03
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms