1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
<pre>Network Working Group D. Crocker
Request for Comments: 581 UCLE-NMC
NIC: 19860 J. Postel
References: <a href="./rfc560">RFC 560</a>, <a href="./rfc563">RFC 563</a> MITRE-TIP
Categories: Protocols, TELNET, RCTE November 1973
<span class="h1">Corrections to <a href="./rfc560">RFC 560</a></span>
<span class="h1">Remote Controlled Transmission & Echoing TELNET Option</span>
1a
[This RFC contains corrections to <a href="./rfc560">RFC 560</a> (NIC -- 18492,) which
described the Remote Controlled Transmission and Echoing TELNET
Option. A completely updated version of 18492 has been journalized
and will be included in the Protocols Notebook. These new
specifications for RCTE are in NIC document (19859,).] 2
<a href="#section-1">Section 1</a> of the RCTE Option specification (18492,2a:gy) was supposed
to include the name and code for the option. The code was
accidentally left out. That statement should read:
3
RCTE 7 3a
<a href="#section-2">Section 2</a> should include the End of Subnegotiation Parameter, at the
end of the subnegotiation parameter specification (18492,2b5:gy).
All examples in the option specifications, showing RCTE SB commands,
should also show the IAC SE parameter. (The revised RCTE
specifications have been so changed.) <a href="#section-2">Section 2</a> should be changed so
that it reads: 4
IAC SB RCTE <cmd> [BC1 BC2] [TC1 TC2] IAC SE 4a
The sample scenario, in <a href="#section-5">Section 5</a>.D (18492,2e4:gy), should be
modified to reflect the kind of asynchrony of events that can occur
with the RCTE protocol. The updated RCTE specifications (in --
19859,1e4:gy) now reflects this. 5
In <a href="./rfc563">RFC 563</a> (18755,) John Davidson criticizes RCTE's apparent failure
to allow Net I/O and server computation to overlap. 6
I agree with John's criticisms and feel that the following should fix
the problem: 7
<span class="grey">Crocker & Postel [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc581">RFC 581</a> Remote Controlled Transmission & Echoing November 1973</span>
1. Change 5.A (18492,2e1) 7a
from: 7a1
Overview of Interaction 7a1a
to: 7a2
Overview of User Terminal Printing Action & Control 7a2a
2. Change 5.B.5.a (18492,2e2e1) 7b
from: 7b1
A Transmission character is one which REQUIRES the User Host to
transmit all text accumulated up to and including its
occurrence. (For Net efficiency, User hosts are DISCOURAGED
from sending before the occurrence of a Transmission
character). 7b1a
to: 7b2
A Transmission character is one which RECOMMENDS that the Using
Host transmit all text accumulated up to and including its
occurrence. (For Net efficiency, Using hosts are DISCOURAGED
from sending before the occurrence of a Transmission character,
as defined at the moment the character is typed).
7b2a
3. Change 5.B.5.b (18492,2e2e2) 7c
from: 7c1
A Break character has the effect of a Transmission character,
but 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. 7c1a
to: 7c2
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
<span class="grey">Crocker & Postel [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc581">RFC 581</a> Remote Controlled Transmission & Echoing November 1973</span>
characters therefore define printing units. "Break character"
as used in this document does NOT mean Telnet Break character.
7c2a
4. Change 5.B.6 (18492,2e2f) 7d
from: 7d1
Input from the terminal is (hopefully) buffered up to the
occurrence of a Transmission or Break character; and the input
text is echoed or not echoed, up to the occurrence of a Break
Character. The most recent RCTE command determines the echo,
Transmission and Break actions. 7d1a
to: 7d2
Input from the terminal is (hopefully) buffered into units
ending with a Transmission or Break character; and 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 RCTE Break reset command
determines the Break actions. 7d2a
5. Change 5.C.4 (18492,2e3d) 7e
FROM: 7e1
A severe (User) site-dependent problem will be buffering type-
ahead input from the terminal. It is possible, especially in
the case of TIPS, that the input buffer will overflow often.
If the receiving (serving) host will permit, the accumulated
text should be transmitted at this point. If the text cannot
be transmitted and further typing by the user will result in
lost text, the user should be notified. 7e1a
to: 7e2
Buffering Problems and Transmission vs. Printing Constraints:
7e2a
There are NO mandatory transmission constraints. The Using
host is allowed to send a character a time, though this
would be a waste of RCTE. The Transmission Classes commands
are GUIDELINES, so deviating from them, as when the User's
buffer gets full, is allowed. 7e2a1
<span class="grey">Crocker & Postel [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc581">RFC 581</a> Remote Controlled Transmission & Echoing November 1973</span>
Additionally, the Using host may send a Break Class
character, without knowing that it is one (as with type-
ahead). 7e2a2
The problem with buffering occurs when printing on the
user's terminal must be suspended, after the user has typed
a currently valid Break Character and until a Break Reset
command is received from the serving host. During this
time, the user may be typing merrily along. The text being
typed may be SENT, but may not yet be PRINTED. 7e2a3
The more standard problem of filling the transmission
buffer, while awaiting an ALLOC from the Serving host, may
also occur, but this problem is well known to implementors
and in no way special to RCTE. 7e2a4
In any case, when the buffer does fill and further text
typed by the user will be lost, the user should be notified.
7e2a5
6. And add 5.C.5, 5.C.6, 5.C.7, 5.C.8, and 5.C.9 as follows: 7f
(5) The Serving and Using hosts must carefully synchronize Break
Class 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 User 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 Reset command may be preceded by terminal output.
7f1
(6) Text should be buffered by the User host until the user types
a character which belongs to the transmission class in force
at THE MOMENT THE CHARACTER IS TYPED. 7f2
(7) Transmission Class Reset commands may be sent by the Serving
host at ANY TIME. If they are frequently sent separate from
Break Class Reset commands, it will probably be better to exit
from RCTE and enter regular character at a time transmission.
7f3
8) It is not immediately clear what the Using host should do with
currently buffered text, when a Transmission Classes Reset
command is received. The buffering is according to the
previous Transmission Classes scheme. 7f4
<span class="grey">Crocker & Postel [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc581">RFC 581</a> Remote Controlled Transmission & Echoing November 1973</span>
The Using host clearly should NOT simply wait until a
Transmission character (according to the new scheme) is typed.
7f4a
Either the buffered text should be rescanned, under the new
scheme; 7f4b
Or the buffered text should simply be sent as a group. This
is the simpler approach, and probably quite adequate. 7f4c
9) It is possible to define NO BREAK CHARACTERS except TELNET
commands (IAC ...). This might actually be useful, as in the
case of transmitting on carriage-return, with the Using host
echoing (a controlled half-duplex). 7f5
Having the using host send a Telnet Command will allow the
serving host to know when he may reset the Break classes, but
the mechanism is awkward and probably should be avoided.
b 7e2
Crocker & Postel [Page 5]
</pre>
|
