-
Notifications
You must be signed in to change notification settings - Fork 4
/
rfc0076.txt
843 lines (474 loc) · 25.9 KB
/
rfc0076.txt
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
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
Network Working Group J. Bouknight
Request for Comments: 76 J. Madden
NIC 5180 G. Grossman
University of Illinois
28 October 1970
Connection-By-Name: User-Oriented Protocol
I. Introduction
Shortly after the first of the year, 1971, the Center for Advanced
Computation (CAC) at the University of Illinois will begin to use the
facilities of the ARPA network. We are the first of a small class of
network nodes whose chief characteristic is that the node is a port
to the network only. All computational power for these nodes will be
taken from other nodes on the network, ILLIAC IV for example.
An important characteristic of most of the users at our Center is a
lack of sophistication about data communication techniques and
practices. The user will eventually be in the majority of those
using the network from all nodes but the problem is ours, almost from
the start.
In our discussions with our prospective users of the network as we
designed our port facility, we found that the greatest confusion and
consternation arose over having to deal with network protocol at the
"nitty-gritty" level of sockets, links, etc. While most of them have
been acclimated to computer systems at the file and device-by-name
level where the software system handles details, here on the current
version of the network, the user handles all details.
Thus, we were compelled to seek a user level interface to network
protocol where all user protocol is handled symbolically with system
procedures making the translation into host-to-host protocol.
Currently, connections are established by exchange of known socket
numbers for the four loose ends of the connection. This requires
either that the user or process always know all socket numbers he
will use at his or other installations OR that his NCP (and/or
related software) remember them for him, allowing him to reference
them symbolically.
We propose a more general solution to the "telephone book" approach
of obtaining socket numbers for user or processes. Only the host, at
each site, knows its socket number space at any given instant in time
as well as the status of the user or process to which a socket number
Bouknight, et al. [Page 1]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
assigned. Additionally, most permanently assigned devices and/or
processes are known by standard mnemonic labels such as DSK (disk),
LP (line printer), CR (card reader), TECO (PDP-10 text editor), etc.
In most systems, all other communications are done through files or
pseudo files, known only to the user by their names and not by their
internal mechanism. In other words, most intrasystem communication
at the user level is by symbolic reference to both devices and
process.
We propose facilities, by extension of the current protocol, that
will allow users to use the network on a connection-by-name basis as
they already do in their host system. In the remainder of this paper
we will present the suggested extensions to the current protocol and
give an example of its usage in a dialogue between a user at CAC,
controlling two processes; one at UTAH, and one at PAOLI (ILLIAC IV
construction site).
II. Proposed Extensions to Protocol
Let us define a class of syntax elements for use in our proposed
extensions to the protocol. (This syntax is expressed in the
metalanguage of the ALGOL-60 report.)
<label> ::= <usercode>/<filename>|<device name>
<devicename> ::= <string>
<usercode> ::= <string>
<filename> ::= <string>|<filename>/<string>
<string> ::= <char>|<char> <string>
<char> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|0|1|2|
3|4|5|6|7|8|9|.|,
A standard set of <devicenames> should be established to reference
line printers, card readers, etc. - those hard peripherals with fixed
processing tasks. A beginning set of <labels> might be:
LP line printer
CR card reader
CP card punch
PTR paper tape recorder
PTP paper tape punch
MT magnetic tape
DSK disk
TTY teletype compatible terminal
Bouknight, et al. [Page 2]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
The format of <usercode> is that of the responding host for the
current discussion. Future discussions about foreign-user usage of
host facilities may result in a standard format for the entire
network.
Most systems can identify files by one <string> plus the <usercode>.
Others, such as the Burroughs B6500 use multifile identifiers where
many <strings> may be used in the <label>. The set of <char> is that
proposed in RFC 66, i.e., ASCII.
The proposed extensions involve a "request" for information and
several variants of a "response" to the request.
A. Request for Socket Number for this Label
<RFSNL> <my socker #> <0> <label>
The RFSNL is sent on the control link to the destination host
requesting the socket number of the attached <label>.
B. Acknowledgement of Request
Upon receipt of an <RFSNL>, the destination host returns one of three
responses:
<AORP> <desired socket#> <your socket #>
<AORN> <desired socket#> <your socket #>
<AORN> <0> <your socket #>
The first response returns the requested socket number and signifies
that the user, device, or process exists. The second response
returns the requested socket number but signifies that the user,
device, or process is not currently available for connection. The
last response signifies that no such user, device, or process exists.
C. Discussion
The above extensions to the protocol are intended to enhance user
acclimation to network usage. The element of strangeness is subdued
and, in fact, for user of the B6500 erased. Attached to this RFC is
an appendix containing a preliminary description of the user language
of the network port facility being brought up at the CAC. We now
present a sample user session on the CAC facility and detail how the
protocol is used to establish the proper communication paths.
Bouknight, et al. [Page 3]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
III. Example of User Dialogue
Assume a user residing at CAC, whose site code is URBANA. His
terminal is an alphanumeric CRT terminal and we assume solution of
code conversion problems for network communications.
The sample user session will involve the setting up of two processes
at two host sites with control from the third host site. All
operations can be accomplished with the current protocol plus the
proposed extensions.
In addition, we also assume that some form of standard user code is
in use for all host sites uniquely identifying every network user
when he is present.
Output keyed by systems will be underlined. Comments are offset to
the right for legibility. All statements about the UTAH system are
purely hypothetical.
User Dialogue Comments
The user moves to the terminal, applies
power and types:
HELLO
The CAC system responds for login
purposes with:
USER= GROSSMAN
------
for the user's code.
1437 TR7/GROSSMAN LOGGED IN
___________________________
LINE PRINTER DOWN TILL 1600
___________________________
This acknowledges proper usercode and
sends any appropriate notes on system
status.
! LINK TO ILLIAC
The exclamation point (!) is the escape
character which flags direct input to
the PDP-11 OS:
User requests connection to the ILLIAC
IV node. NCP operations establish link
from user terminal to B6500 MCP.
Bouknight, et al. [Page 4]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
1437 TR7/GROSSMAN LINKED ILLIAC
-------------------------------
Completes response.
? EXECUTE DISK/PRINT; FILE DISK = ALPHA@UTAH REMOTE QUEUE; END
1. DISK/PRINT lists text files from
disk to B6500 line printer.
2. REMOTE files on the B6500 will refer
to files going to/coming from the
network.
3. ALPHA@UTAH specifies that a
connection is to be made via the
network to a file GROSSMAN/ALPHA from
the UTAH node.
4. QUEUE specifies periodic attempt to
complete the connection.
The B6500 will ask for the socket
number associated with GROSSMAN/ALPHA
until an AORP is received.
The language is that of the monitor for
the B6500
! FLAG ILLIAC =#
All data received or sent on the link
to ILLIAC must now be prefaced by the #
character.
! LINK TO UTAH
1441 TR7/ GROSSMAN LINKED UTAH
------------------------------
User now links into UTAH PDP-10 system.
#1410: DISK/PRINT BOJ 1441
--------------------------
System message stating beginning-of-job
for DISK/PRINT on B6500.
^C
. R PIP
-
User will run PIP on a listing file.
Bouknight, et al. [Page 5]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
* NETWKR:ALPHA@ILLIAC <- DSK:FIL.TMP
-
NETWRK is network file type for UTAH
system. Mechanism for file control
basically same as for B6500 system.
Since PIP will be sending to the
network, it does not request a socket #
from the B6500 NCP but instead
instructs its NCP to acknowledge any
request for GROSSMAN/ALPHA from ILLIAC
with the socket number PIP will send
from. As soon as the B6500 NCP tries
again to find GROSSMAN/ALPHA from UTAH,
success occurs and the socket numbers
are exchanged with subsequent
connection establishment.
*
-
PIP completes the task and terminates
the connection to the B6500.
#14: DISK/PRINT EOJ 1448
B6500 acknowledges completion of task.
#? TO SPO: SAVE LIST GROSSMANHA FOR MAIL(U OF I/GROSSMAN)
User sends message to B6500 operator.
User logs out of UTAH.
JOB 10, USER GROSSMAN@URBANA TY68 AT 1448 ON 22-NOV-70
------------------------------------------------------
FILES DELETED: 0, FILES SAVEDL RUNTIME 0 MIN 12 SEC
---------------------------------------------------
System logout listing.
! END UTAH
1449 TR7/GROSSMAN DELINKED UTAH
-------------------------------
Link to UTAH system now dropped.
# FROM SPO: LISTING MAILED
--------------------------
B6500 operator response.
Bouknight, et al. [Page 6]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
! LEAVE
User desired to log out of CAC system.
1450 TR7/GROSSMAN DELINKED ILLIAC
---------------------------------
Link to ILLIAC system new dropped.
1450 TR7/GROSSMAN LOGGED OUT
----------------------------
Session over.
Bouknight, et al. [Page 7]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
Syntax and Semantics for the Terminal User Control Language
for the Proposed PDP-11 ARPA Network Terminal System
by
G. R. Grossman
Prefatory Notes
The following document represents a first attempt at providing a
control language for the terminal user of the PDP-11 network terminal
system. This language is deemed sufficiently powerful to provide the
user with a minimal facility for attaching to remote host computers
over the ARPA network, initiating processes, and routing data flow to
local peripheral devices.
The hardware system as envisioned will comprise a PDP-11/20 with a
least 8k of core, a small disk (512 kilobytes of storage), a console
teletype, and optional card readers, line printers, DECtapes, User
terminals, card punches, storage scopes, etc.
The executive system will consist of a basic driver system which will
control autonomous processes and interrupt-driven device service
routines. The system will keep tables in core and on the small disk
for logging peripheral usage, keeping track of connections on the
network, queuing up of tasks that cannot be immediately performed,
storing attributes of remote hosts, etc.
Since network hosts handle communications in character-at-a-time or
message modes, and may or may not echo characters over the network,
the system takes this into account when handling connections to
specific hosts. If the connection is in message mode, minimal line-
by-line editing facility (character and line deletion) is provided.
A means for the user to change flag and message transmit characters
is provided to prevent incompatibilities which may arise between the
PDP-11 and other hosts.
This document does not describe control card syntax for card reader
usage, nor does it describe the operator's control language. These
will be described in later documents.
Character Set
<character> ::= <letter> | <digit> | <special> | <space>
<letter> ::= A | B | ... | Y | Z
Bouknight, et al. [Page 8]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
<digit> ::= 0 | 1 | ... | 8 | 9
<special> ::= ! | " | # | $ | % | & | ' | ( | ) | * | + | , | - |
. | / | : | : | < | = | > | ? | @ | [ | | ] | ^ |
|` | { | <bar> | }
Identifiers
<identifiers> ::= <letter> | <identifier> <letter> |
<identifier> <digit>
Semantics: Identifiers are used to designate peripheral units,
host computers, etc. No identifier may exceed 8 characters in
length.
Numbers
<integer> ::= <digit> | <integer> <digit>
Semantics: <integer> are the only form of number allowed in the
control language. They must not exceed 2^15-1.
Peripheral Designator
<peripheral designator> ::= <device class> <device number> | OPR
<device number> ::= <digit> | <digit> <digit> |
<device class> ::= CR | CP | LP | DT | TR | SS
Semantics: Peripheral designators name specific peripheral
devices. Device lasses designate classes of peripherals.
OPR designates the operator's console teletype. The classes of
peripherals corresponding to the device classes are given on the
following table:
<device class> type of peripheral
CR card reader
CP card punch
LP line printer
DT DECtape
TR terminal
SS storage scope
Bouknight, et al. [Page 9]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
File Label
<file label> ::= <tape label> | <tape label> / <tape file name>
<tape label> ::= <identifier>
<tape file name> ::= <identifier>
Semantics: File labels provide the means for designating tape
files symbolically. If the <tape label> form is used, the
designated file is assumed to occupy the entire tape.
Flagged Control Statement
<flagged control statement> ::= <flag> <control statement>
<flag> ::= <special>
Semantics: <Flagged control statement>s arc the user's names of
communicating with the PDP-11 system. The <flag> must be the
system default flag (!) or a substitute which the user provides
by means of the <flag statement>. Input to the system which
does not begin with a <flag> will be passed on to the process to
which the user is connected, if any.
Control Statements
<control statement> ::= <link statement> |
<copy statement> |
<end statement> |
<user statement> |
<status statement> |
<out statement> |
<to statement> |
<escape statement> |
<back statement> |
<delete statement> |
<transmit statement> |
Bouknight, et al. [Page 10]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
<lock statement> |
<unlock statement> |
<assign statement> |
<label statement> |
<create statement> |
Link Statement
<link statement> ::= LINK TO <host> <q>
<q> ::= <empty> |
QUEUE |
QUEUE <integer>
Semantics: The Link statement directs the system to set up a
connection between the user's unit and a remote host. The <q>
construct allows the user to specify that, if the connection
cannot be set up immediately, the system is to keep trying. If
the QUEUE form is used, the system will keep trying
indefinitely. If the QUEUE integer form is used, the system
will try for integer minutes.
Copy Statement
<copy statement> ::= COPY <source> TO <dest> <q>
<source> ::= NETWORK |
<file label> |
<source class> |
<source device>
<source class> ::= CR | TR | SS |
<source device> ::= <source class> <device number>
<dest> ::= NETWORK
<file label> |
Bouknight, et al. [Page 11]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
<dest class> |
<dest device>
<dest class> ::= CP | LP | TR | SS
<dest device> ::= <dest class> <device number>
Semantics: The <copy statement> directs the system to set up a
connection between the <source> and <dest> and copy records of
information between them. If the <device class> or <device>
form is used for either <source> or <dest>, the copy process
cannot begin until a unit is assigned to the user. If the <file
label> form is used, the copy process can likewise not proceed
until the system has access to a properly labeled tape. if the
NETWORK form is used, a connection to a remote process must be
pending.
The <q> construct has the same meaning as for the <link
statement>, with the additional provision that the condition
that caused the process to be incomplete may be the lack of a
device assignment.
End Statement
<end statement> ::= END
Semantics: The <end statement> causes the current connection to
be terminated.
User Statement
<user statement> ::= USER = <identifier>
Semantics: The <user statement> is used during the log in
process to allow the user to identify himself.
Status Statement
<status statement> ::= STATUS <device class> |
STATUS <peripheral designator>
Semantics: The <status statement> allows the user to interrogate
the system as to the status of a device or class of devices.
Bouknight, et al. [Page 12]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
Out Statement
<out statement> ::= OUT|LEAVE
Semantics: The <out statement> allows a user to log out of the
system. If the OUT form is used, all queued process initiated
by the user are terminated. The LEAVE from does not terminate
such pending queued processes so long as these processes do not
directly involve the user's terminal.
To Statement
<to statement> ::= TO CON :<text> | TO <user> : <text>
Semantics: The <to statement> allows the user to send a message
to the operator or another logged-in user.
Flag Statement
<flag statement> ::= FLAG = <special>
Semantics: The <flag statement> allows the user to define the
character which the system recognizes as preceding a control
statement as distinguished from a message to a remote process to
which he may be attached. The default flag character is "|".
Back Statement
<back statement> ::= BACK ? {ascii special or control character}
Semantics: The <back statement> allows the user to define the
character which, in control or message mode, causes the system
to "forget" the previous input character. The default backspace
character is RUBOUT (ASCII 1778).
Delete Statement
<delete statement> ::= DELETE = {ASCII special or control character}
Semantics: The <delete statement> allows the user to define the
character which, in control or message mode, causes the system
to "forget" the previous line of input. The default delete
character is ASCII VT (control K).
Bouknight, et al. [Page 13]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
Transmit Statement
<transmit statement> ::= TRANSMIT = {ASCII special or
control character}
Semantics: The <transmit statement> allows the user to define
the character which, in control or message mode, causes the
system to begin interpreting the control statement or to
transmit the message. The default transmit character is
carriage return.
Lock Statement
<lock statement> ::= LOCK
Semantics: The <lock statement> causes the system to prevent any
user or process but the process to which the user is currently
attached from sending messages to the user's terminal.
Unlock Statement
<unlock statement> ::= UNLOCK
Semantics: The <unlock statement> reverses the action of a
previous <lock statement>.
Assign Statement
<assign statement> ::= ASSIGN <assign device> <q>
<assign device> ::= LP | DT | CP
Semantics: The <assign statement> causes the system to attempt
to assign a device not currently in use to the user. The <q>
construct has the same meaning as for the <link statement>.
Label Statement
<label statement> ::? LABEL DT <device number> <tape label>
Semantics: The <label statement> causes the system to write a
new label on the DEC tape specified.
Bouknight, et al. [Page 14]
RFC 76 Connection-By-Name: User-Oriented Protocol October 1970
Create Statement
<create statement> ::= CREATE <tape file name> ON <tape label>
Semantics: The <create statement> causes the system to create a
new file named <tape file name> on the DEC tape labeled <tape
label>.
Purge Statement
<purge statement> ::= PURGE <tape label> |
PURGE <tape file name> ON <tape label>
Semantics: The <purge statement> causes the system to delete all
tape directory information on the DEC tape or tape file
specified.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gottfried Janik 2/98 ]
Bouknight, et al. [Page 15]