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
278
279
280
281
282
283
|
Network Working Group David Walden
Request for Comments #365 Bolt Beranek and Newman Inc.
NIC # 10607 July 11, 1972
Categories:
Updates:
Obsoletes:
A LETTER TO ALL TIP USERS
Dear TIP Users,
You will shortly be sent a revised version of the "TIP User's
Guide." Besides now having a loose leaf format, mainly descriptions
of new commands have been added. Appendix B will be an alphabetical
list of all TIP commands. The new commands are:
@BINARY INPUT START
@BINARY INPUT END
@BINARY OUTPUT START
@BINARY OUTPUT END
@CLEAR DEVICE WILD
@CLEAR INSERT LINEFEED
@INSERT LINEFEED
@SEND COMMAND
@RECEIVE FROM WILD
@SEND TO WILD
@SET DEVICE WILD
@MAG ABORT
@MAG BACKSPACE FILE
@MAG BACKSPACE RECORD
@MAG READ FILE
@MAG READ RECORD
@MAG SETUP COPY
@MAG SPACE FILE
@MAG SPACE RECORD
@MAG UNLOAD
@MAG WRITE EOF
@MAG WRITE TAPE
The MAG commands are, of course, not relevant to users of TIPs without
the magnetic tape option.
A TIP system including the above commands has been in operation
since late June. We think this system is a substantial improvement
over previous versions.
[Page 1]
^L
RFC # 365 July 11, 1972
In case you've not been keeping track, there are now eleven TIPs
in the ARPA Network. These are ETAC, GWC, AMES, ARPA, MITRE, NBS,
BBN, USC, NOAA, ROME, and SAAC. Also, a TIP will soon be installed at
CCA.
I'll now briefly discuss a number of topics I think may be
interesting to you.
Getting TIP status information. As we develop new features for
the TIP and fix bugs, we are continually releasing new versions of the
TIP program. We do this by just reloading your TIP when you're not
looking (i.e., when no one is using your TIP). In the future we will
notify you whenever a new version of the TIP program is loaded into
your TIP by adding a tiny "status message" to the "HELLO" you get when
you "log onto" the TIP. This status message will usually be merely
the TIP's version number; however, occasionally the message will
indicate (by typing "NEWS") that there is some news about the TIP's
status which you should read before continuing your session with the
TIP. The NEWS can be retrieved by typing the command @NEWS which will
ICP to a special socket at BBN's TENEX or PDP-1D which will print the
news. Of course, either of these systems may sometimes be down, but
we won't worry about the problem until we see how serious it is.
To whom to complain or make suggestions. Many of you have had
occasion to complain about the operation of your TIP system or to make
suggestions for its improvement. All too frequently, however, these
complaints have been directed to the Host system you are using from
the TIP instead of to us. BBN maintains a Network Control Center
which is always manned. Its telephone number is 617-661-0100. All
TIP problems should be reported immediately to the Network Control
Center. If you have a suggestion for a new command, or if you think
you've found a subtle bug in the TIP program, ask to talk to Dave
Walden or Bernie Cosell when you call the Network Control Center.
Device buffers. In general, each TIP MLC port has a different
size buffer allocated to it and therefore to the device connected to
the port. Devices which operate at higher speeds, of course, require
larger buffers, especially output buffers. If you need more buffering
than you have (frequently indicated by output coming in short bursts),
try to arrange with whomever is locally responsible for the TIP you're
using to come in through a port with a larger buffer allocation. If
necessary, this person can arrange with us to specially tailor the
buffer allocation for your TIP.
[Page 2]
^L
RFC # 365 July 11, 1972
There are presently only about 2500 characters of buffers
available for the TIPs terminal devices. Since each device has an
input buffer and two output buffers (output is double buffered), each
of the 63 devices has available an average of about 13 charac- ters
for input and 13 characters for each output buffer. Since there is
continual pressure for new features in the TIP and for old features to
work more conveniently, the space available for device buffers is
steadily decreasing. There seem to be two ways to increase the space
available for device buffers; the first is to get more core memory;
the second is to modularize the program so that unneeded features can
be removed from particular sites. For instance, the 2741 code and
character conversion tables might be removed from a site at which they
were never used. You always have the option of getting more core for
your TIP; we are presently working on the latter method and should
have it ready in a few months. In the mean time, the space available
for device buffers will probably continue to slowly diminish.
The nominal (untailored) buffer sizes are presently about as
follows:
device input (characters) output (characters/buffer)
1-3 60 56
4-7 28 27
8-15 20 20
16-32 12 13
33-63 6 6
Echoing. The TIP's echoing capability has been a controversial
item in the past. We have recently fixed it up a little and we think
that if you try it now, you'll like it a lot better. Unfortunately,
"@@" is still not echoed correctly very often; this is a bug and we
are going to fix it, but it's hairy to fix.
We will shortly be removing three of the ECHO commands (ECHO ALL,
ECHO HALFDUPLEX, and ECHO NONE) and be slightly changing the meaning
of the two other ECHO commands (ECHO REMOTE and ECHO LOCAL). We will
also add two new ECHO commands (PHYSICAL HALFDUPLEX and PHYSICAL
FULLDUPLEX.) Thus the new set of ECHO commands will be:
@PHYSICAL HALFDUPLEX
@PHYSICAL FULLDUPLEX
@ECHO LOCAL
@ECHO REMOTE
[Page 3]
^L
RFC # 365 July 11, 1972
The ECHO LOCAL and ECHO REMOTE commands will probably be ignored for
physical halfduplex devices. Therefore, for physical full- duplex
devices, ECHO LOCAL and ECHO REMOTE will have the effect of declaring
the device to be virtual halfduplex or virtual full- duplex. Devices
which are known to be physical halfduplex (e.g., IBM 2741's) will come
up in physical halfduplex mode. All other devices will come up in
physical fullduplex mode and local echo mode (i.e., virtual halfduplex
mode). Whenever a connection is opened, the TIP will automatically
send off the current virtual echo mode to the server. Whenever a ECHO
LOCAL or ECHO REMOTE command is given, the virtual mode will be
appropriately updated and forwarded to the server. When the Telnet
ECHO (code 132) (=virtual fullduplex) or Telnet NO ECHO (code 131)
(=virtual half- duplex) characters are received by the TIP, it will
follow the following rules:
ECHO received and
TIP is physical halfduplex -- NO ECHO sent to server
TIP is virtual halfduplex -- ECHO sent to server and
mode changed to virtual
fullduplex
TIP is virtual fullduplex -- nothing
NO ECHO received and
TIP is physical halfduplex -- nothing
TIP is virtual halfduplex -- nothing
TIP is virtual fullduplex -- NO ECHO sent to server and
mode changed to virtual
halfduplex
When a connection is broken, devices in physical fullduplex mode will
be reset to virtual halfduplex mode.
Some other command changes we are planning to make.
--------------------------------------------------
1. PROTOCOL TO LOGIN will be removed. It has been replaced by
LOGIN.
2. LOGIN will take a parameter, the Host number, so it will not
be necessary to give both HOST and LOGIN commands.
Some things which we are presently doing.
----------------------------------------
[Page 4]
^L
RFC # 365 July 11, 1972
1. When a terminal hangs up, any captured devices will be given
back.
2. Output to high speed devices will be possible.
3. Data sets will automatically be hung up when the caller
disconnects even though the caller never "logged in".
4. 202C modems will work.
5. Major improvements on the magnetic tape option.
6. Trying to find the "R half" of the "R T CLOSED" message.
7. We have received numerous complaints that the TIP once in a
while loses an allocate. We will fix this or else demonstrate
it's not the TIP's fault.
Some things we are thinking about.
---------------------------------
1. Adding a lower case capability for Model 33 Teletypes.
2. Adding a mechanism so the TIP's status or a device's status
(e.g., its device number) can be obtained by the user.
Each of the above mentioned changes will be preceded by
notification via the NEWS and we plan to issue frequent updates to the
TIP User's Guide from now on.
We are trying hard to improve the TIP. If you've got a
suggestion (especially if it doesn't take any memory), let me hear
from you.
Regards,
< signed "Dave" >
David C. Walden
Bolt Beranek and Newman Inc.
July 11, 1972
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 1/97 ]
[Page 5]
^L
|
