-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrfc100.txt
2075 lines (1167 loc) · 61 KB
/
rfc100.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
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group P. Karp
Request for Comments: XXXX MITRE
NIC: 5761 26 February 1971
Categorization and Guide to NWG/RFCs
The NWG/RFC Guide is an attempt to introduce some order into the
NWG/RFC series, which now numbers 102. The Guide categorizes the
NWG/RFC notes, identifies topics under discussion and the relevant
NWG/RFCs, and indicates whether the notes are current, obsolete, or
superseded.
A minimum subset of NWG/RFCs is identified. This subset consists of
the NWG/RFCs that one should read to quickly become familiar with the
current status of topics.
For historical reasons and for readers interested in tracing through
the stages of development of a topic, a brief summary is given for
each NWG/RFC relevant to a particular category.
This initial Guide is being issued as a NWG/RFC since it establishes
the basis for future releases. So, please comment! Suggestions,
criticism, corrections, etc., will be accepted for a period of
approximately two weeks. Be critical as I have not had to implement
an NCP and probably have some misconceptions regarding various
technical points. An official version will be released on March 26.
The Guide will then be a unique series of documents, separate from
NWG/RFCs (as is the Document No. 1, No. 2 series).
With regard to renumbering NWG/RFCs, I am inclined to keep she
sequential numbering scheme presently employed. The main reason for
this position is that the current numbers have both historical and
semantic significance. For example, reference to "#33, #66, #83,
etc." is a convenient shorthand (reminiscent of the old corny joke
about joke #s) used extensively during meetings. The list of
"current status" NWG/RFC numbers should dispel any fear of
maintaining stacks of NWG/RFCs for quick reference. The subject is
not closed, however, and I will entertain any objections,
suggestions, etc.
GUIDE TO NETWORK WORKING GROUP/REQUEST FOR COMMENTS
The NWG/RFC notes are partitioned into 9 categories, which in turn
are divided into subcategories. For each category the official
document (if any), unresolved issues, and documents to be published
are identified.
Karp [Page 1]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
For each subcategory, relevant NWG/RFCs are listed and a brief
description of the topics addressed in each note is given.
The categories are again listed and the current NWG/RFCs identified
(p. 23). The NWG/RFCs in the list comprise the subset defining
"current status". Note that most of the documentation in the subset
addresses topics in Category D - Subsystem Level Protocol, where at
the present time most issues are unresolved.
Finally, the NWG/RFCs are listed by number, with a reference to the
relevant categories (p. 26).
A. ADMINISTRATIVE
A.1 Distribution list
NWG/RFC #s: 3, 10, 16, 24, 27, 30, 37, 52, 69, 95
The distribution list contains names, addresses, and phone numbers
for recipients of NWG/RFCs. The most recent list, NWG/RFC 95,
designates the Technical Liaison as the recipient for each site and
supersedes all other RFCs in this category.
A.2 Meeting announcements
NWG/RFC #s: 35, 43, 45, 54, 75, 85, 87, 99
General network working group meetings are held approximately every
three months. Special subcommittee meetings are held on an ad hoc
basis. All related NWG/RFCs are obsolete except 87, announcing a
graphics meeting to be held at MIT in April and 99, announcing a
general NWG meeting, Atlantic City, May 16-20.
A.3 Meeting minutes
NWG/RFC #s: 21, 37, 63, 77, 82
The meeting minutes present highlights of issues discussed at general
NWG meetings and report definite decisions that are made.
To be published: A NWG/RFC will be published by Dick Watson, SRI,
reporting on the NWG meeting held at the University of Illinois,
February 17-19.
Karp [Page 2]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
A.4 Guide to NWG/RFCs
NWG/RFC #s: 84, 100
The NWG/RFC Guide categorizes the NWG/RFC notes, identifies topics
under discussion, the relevant NWG/RFCs, and denotes whether the
notes are current, obsolete, or superseded. Included in this
category are lists of NWG/RFCs, ordered by number (as in 84) and/or
by author.
A.5 Policies
NWG/RFC #s: 18, 24, 25, 27, 30, 37, 41, 48, 53, 54, 72, 73, 77, 82,
102
NWG/RFCs categorized as policy contain official stands on issues
i.e., the position taken by S. Crocker, NWG Chairman. The issues
covered are varied.
In particular:
77 and 82 discuss meeting policy.
72, 73, 77, and 82 discuss the decision to delay making changes to
the Host/Host protocol in order to first gain experience with the
network. A committee to propose specific changes has been formed.
37 discusses changes to the Host/Host protocol and the schedule for
introducing modifications.
53 sets forth the mechanism for establishing and modifying the
official Host/Host protocol.
54 presents the initial official protocol.
48 presents some suggestions for policy on some outstanding issues.
41 requests the tagging of IMP-IMP teletype messages.
Documentation conventions for NWG/RFCs are given in 24, 27, and 30.
25 and 18 designate uses for particular link numbers. 25 has been
superseded by 37 and 48. 18 is obsolete.
102 discusses the issuing of Document #2, in lieu of the official
modification procedure outlined in 53.
Karp [Page 3]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
B. HOST/IMP PROTOCOL (LEVEL 1)
Official document: BBN Memo No. 1822 (latest revision - February
1971)
Unresolved issues: Location of first byte of data in a message.
To be published: Document No. 2 will be written by S. Crocker and
will, among other things, resolve the first byte location issue.
B.1 General Topics
NWG/RFC #s: 17, 17a, 19, 21, 33, 36, 37, 38, 46, 47, 102
In particular:
17 raised several questions regarding HOST/IMP protocol. In 17a,BBN
responds to the questions.
19 proposes that the hosts control the ordering of IMP/Host traffic
rather than getting messages delivered in the order received by the
IMP. This proposal is counter to BBN's position, specifically
expressed in 47; that is, buffering is a Host rather than an IMP
function. The purpose of buffering in the IMP is to handle surges of
traffic, thus IMP buffers should be empty. NWG/RFC 19 is obsolete.
21 discusses changes to BBN Memo No. 1822. The remarks are obsolete.
33 contains a general description of the interface between a host and
the IMP. NWG/RFC 47 comments on NWG/RFC 33.
The use of RFNMs (type 10 and type 5 messages) to control flow is
discussed in NWG/RFCs 36, 37 and 46. The official position in "cease
on link" (i.e., discontinue the mechanism) is presented in 102 and
renders obsolete the remarks in 36, 37, and 46.
38 discusses the changes to message format that would be necessary if
multiplexing connections over links was allowed.
Karp [Page 4]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
B.2 Marking/Padding
NWG/RFC #s: 44, 48, 49, 50, 54, 64, 65, 67, 70, 102
In particular:
102 presents the decision of the Host/Host protocol committee to
abandon the marking convention and to ignore padding. The issue of
whether to have the first data byte begin after 72 bits of header or
to use double physical transmission (NWG/RFC #s 65, 67) is discussed.
The former official position is expressed in 54: "All regular
messages consist of a 32 bit leader, marking, text, and padding.
Marking is a (possibly null) sequence of zeros followed by a 1;
padding is a 1 followed by a (possibly null) sequence of zeros."
Several proposals to eliminate marking have been made. 64 suggests a
hardware modification to eliminate marking/padding by adding
appropriate counters to Host/IMP interfaces. 65 suggests breaking
regular messages into two messages. 67 supports 65. 72 and 73 suggest
that such changes be postponed until sufficient experience with the
network is gained.
44 introduces the notion of double padding and presents two
alternative approaches when a message does not end on a Host word
boundary:
a) The host provides padding in addition to the IMPS ("double
padding")
b) The host shifts messages to end on a word boundary.
48 explains double padding in more detail and discusses the pros and
cons. A suggestion is made to use marking to adjust the word
baundary (alternative b). NWG/RFCs 49 and 50 are concurrences with
48.
70 presents a method to handle the stripping of padding from a
message.
All NWG/RFCs in this category have been superseded by 102.
C. HOST/HOST PROTOCOL (LEVEL 2)
Host/Host protocol specifies the procedures by which connections for
inter-Host interprocess communication over the network are
established, maintained, and terminated. The software which
implements the protocol within each Host is called the Network
Karp [Page 5]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
Control Program (NCP). The topics included in this category are
connection establishment and termination, flow control, interrupt
handling, error control and status testing, dynamic reconnection, and
the relationship between connections and links.
Official documents: Document No. 1 by S. Crocker, 3 August 1970, with
modifications presented in NWG/RFC 102.
Unresolved issues: Length of control messages
Location in message of first byte of data
Flow control algorithm
Socket identification format
To be published: Document No. 2 will be written by S. Crocker and
will resolve the first three issues. A NWG/RFC will be written by J.
Heafner, in collaboration with E. Meyer and G. Grossman. presenting
the pros and cons on alternative proposals for socket number
identification.
C.1 Host/Host Protocol Proposals
NWG/RFC #s: 9, 11, 22, 33, 36, 37, 38, 39, 40, 44, 46, 48, 49, 50,
54, 57, 59, 60, 61, 62, 65, 68, 93, 102
The official Host/Host protocol presented in Document No. 1 is based
on the proposals, discussions, acceptance, and rejection of ideas in
the above list of NWG/RFCs, up to and including 59.
In particular:
9, 11, and 22 represent an early attempt at a Host/Host protocol. 11
supersedes 9 and 22 contains some modifications to control message
formats presented in 11. The protocol was not considered powerful
enough because it didn't provide for inter-host communication without
logging in. This protocol was thrown out as a result of a network
meeting in December 1969.
33 is the basis for the current protocol. It was presented at the
SJCC, 1970.
36 is a modification of 33. It discusses connection establishment
without switching, flow control, and introduces the idea of
reconnection. Control commands are summarized. 36 was distributed at
a Network meeting in March 1970.
Karp [Page 6]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
37 presents the reaction to 36 and presents ideas on reconnection
flow control and decoupling of links and connections. Provisions of
error detection, status testing, experimentation and expansions are
discussed.
38, 39, 40, 44, 49 and 50 are comments written in response to the
meeting. 46 is also a comment but in the form of a rewrite of 33. 46
introduces the notion of interrupts, INT, and ECO for status testing.
47 concerns the philosophy behind the notion of a link.
48 summarizes the issues discussed in the above NWG/RFCs.
54 is the initial official protocol submitted for criticism,
comments, etc. It introduces a new mechanism for flow control in
which the receiving host allocates buffer space and notifies the
sending host of the space available.
57 and 59 comment on 54.
Document No. 1 differs from NWG/RFC 54 as follows: commands GVB and
RET have been added for flow control and error condition codes have
been added to ERR. NWG/RFC 102 presents some modifications to
Document No. 1: fixed lengths are specified for ECO, ERP, and ERR; a
new pair of commands RST and RRP (suggested in 57) are added.
60, 61, and 62 propose new Host/Host protocols, quite different from
the current official protocol. 62 supersedes 61. 60 and 62 are worth
considering for possible implementation in future protocols.
Hopefully, more documents of a similar nature will be generated as
experience is gained with the current protocol.
NWG/RFCs 65 and 68 comment on Document No. 1.
93 points out an ambiguity in Document No. 1 regarding the
requirement of a message data type in the message sent from server
socket 1. The ambiguity is resolved by 102 which eliminates message
data type from level 2 protocol.
C.2 NCPs (Description, Structure, Techniques)
NWG/RFC #s: 9, 11, 22, 23, 33, 36, 44, 46, 48, 55, 70, 71, 74, 89
This category includes RFCs which give details of system calls, table
structures, implementation techniques, etc.
Karp [Page 7]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
In particular:
NWG/RFCs 9, 11, and 22 are obsolete
23 is a general statement on sending or receiving multiple control
messages in a single communication.
33 discusses the system calls used for interaction between the NCP
and a user process.
36 describes a possible implementation giving table structures and
their interrelationships.
44 lists the system calls that SDC feels should operate, includes
spec. of calls to NCP.
NWG/RFC 48 presents Postel's and Crocker's view on the environment in
which a host time-sharing system operates, suggests some system
calls, and presents a design to illustrate the components of an NCP.
55 presents a prototypical NCP which implements the initial official
protocol specified in 54. It is offered as an illustrative example.
70 gives some techniques for stripping the padding from a message.
71 presents the method employed by the CCN-Host at UCLA to
resynchronize flow control when an input error occurs.
74 documents the implementation of sections of the NCP at UCSB.
89 gives a brief description of the "interim interim NCP" (IINCP) on
the MIT Dynamic Modeling PDP-6/10 used to run some experiments.
C.3 Connection Establishment and Termination
NWG/RFC #s: 33, 36, 39, 44, 49, 50, 54, 60, 62
The NWG/RFCs in this category present the system calls and control
commands used to establish and terminate connections, i.e., the
handshaking that must transpire before connections are established or
terminated.
In particular:
36 presents a rough scenario of connection establishment which
differs from that specified in 33 in that establishment does not
include procedures for switching procedures.
Karp [Page 8]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
39 suggests the addition of a command TER to supplement CLS.
44 discusses the use of the CLS command and suggests that two
commands BLS and CLS be adopted.
46, 46, and 50 all discuss queuing of RFCs.
54 presents the initial official method for establishing and
terminating connections.
60 and 62 present schemes different from the official protocol.
C.4 Flow Control
NWG/RFC #s: 19, 33, 36, 37, 46, 47, 54, 59, 60, 65, 68, 102
The NWG/RFCs in this category address the problem of controlling the
flow of messages from the sending socket to the receive socket. The
official position is stated in Document No. 1 with an unresolved
issue pending as described in NWG/RFC 102.
In particular:
19 suggests that Hosts may want the capability of agreeing to lock
programs into core for more efficient core-to-core transfers. This
may require different handling of RFNMs.
33 describes the use of RFNM (type 10 rather than 5) on a link to
control flow. A control command RSM (resume) is defined to allow the
host to signal for resumption of message flow. 46 describes the same
technique.
37 describes the effect some proposed changes (for reconnect and
decoupling of connections and links) would have on RFNMs and "cease
on link."
46 (MIT's rewrite of protocol) introduces BLK and RSM commands as an
alternative to "cease on link", SPD and RSM commands.
47 presents BBN's position that buffering be handled by the Host, not
the IMP.
54 introduces a new flow control mechanism in which the receiving
host is required to allocate buffer space for each connection and not
notify the sending host of bit sizes. A new command, ALL to allocate
space is sent from the receiving host to the sending host. With this
new mechanism, 33, 37, 46, and 47 become obsolete.
Karp [Page 9]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
59 presents the objections of Project MAC and Lincoln Labs to the
flow control mechanism introduced in 54. Their preference is for
"cease on link" which allocates buffer space on demand.
60, which defines a simplified NCP protocol, presents a method of
flow control based on the requirement that connections are full
duplex.
65 comments on Document No. 1. With respect to flow control, it
disagrees with the allocation mechanism and the introduction of
irregular message to make the cease mechanism work.
68 proposes modifications to RFNM by defining three forms which would
insure control of data and would replace the memory allocation
mechanism.
102 eliminates the cease mechanism and introduces potential
modifications to the flow control mechanism. The latter will be
resolved and presented in Document No. 2.
C.5 Error Control and Status Testing
NWG/RFC #s: 2, 37, 39, 40, 46, 48, 54, 57, 102
This category addresses schemes for detecting and controlling errors
and for Host status reporting and testing.
In particular:
2 talks about error checking and gives an algorithm for implementing
a checksum. It also recommends that Hosts should have a mode in
which positive verification of all messages is required.
37 brings up the topics of error detection and status testing, which
are expanded by RAND in 39 and 40. 39 introduces control commands ERR
for error checking and QRY, HCU, and HGD for status testing. 40
expands on the discussion, suggests error codes, introduces RPY as a
response to QRY, and suggests that NOP could be used for reporting
Host status.
46 concurs with 40 on ERR and introduces ECO to test communication
between NCPs.
48 recommends that ERR, as presented in 40 and 46, be adopted, that a
distinction be made between resource errors and other error types,
that ECO, presented in 46, be of variable length, and that an ECO,
ERP command pair be adopted.
Karp [Page 10]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
54 officially specifies the control commands ERR, ECO, and ERP. The
official protocol doesn't include a specific list of error types nor
does it recommend the action to be taken. Suggestions for extensions
to error detection and recovery and Host/Host status testing are
encouraged.
57 presents a list of error types and suggests new commands OVF for
overflow errors and RST/RSR for host status testing.
102 sets fixed lengths for ERR, ECO, and ERP control commands. RST
and RSR are adopted.
C.6 Interrupt
NWG/RFC #s: 46, 48, 49, 50, 54, 102
The interrupt system call and the INT control commands are used to
interrupt a process. This is actually a third level issue. The
NWG/RFCs leading up to the decision to include INR and INS in the
official protocol are summarized below.
In particular:
46 introduces the INT command as a method for interrupting a process.
48 recommends adoption of INT with the restriction that the feature
should not be used during communication with systems which scan for
interrupts and that INT should not be used on non-console type
connections (see D.2).
49 expands on the explanation of INT. 50 concurs with proposal 46,
that INT is useful.
54 induces INT, INS control commands in the official protocol as an
escape mechanism, where interpretation is a local matter.
102 discusses synchronization of interrupt signals, presents two
implementation schemes, and relegates the topic to third level
protocol. INS should be used to indicate a special code in the input
stream.
C.7 Dynamic Reconnection
NWG/RFC #s: 33, 36, 37, 38, 39, 44, 46, 48, 49, 50
The notion of dynamic reconnection was introduced early in the
Host/Host protocol design. However, the consensus was that it
introduced complexities with which the initial NCP implementations
Karp [Page 11]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
did not want to cope. The need for dynamic reconnection was
questioned; NWG/RFC 48 explains why it was included and considered
useful.
In particular:
33 introduces the concept of switching connections to the Logger. 36
presents a scheme for dynamic reconnection, i.e., reconnection can
take place after the flow is started.
37 presents two methods suggested by BBN for handling reconnection.
38 discusses changes to proposed END and RDY control commands that
would be necessary if connections were multiplexed over links.
39 states that dynamic reconnection is too complex.
44 presents two cases where reconnection could be used, suggests that
the cases be separated, and recommends implementation of only the
case of a simple connection switch within the same Host.
46 recommends that dynamic reconnection be reserved for further
Host/Host protocol implementations.
48 discusses the aesthetics of dynamic reconnection in detail but
concedes that it won't be included in the initial protocol. 49 and 50
concur with the decision.
C.8 Relation Between Connections and Links
NWG/RFC #s: 37, 38, 44, 48
A connection is an extension of a link. The NWG/RFCs in this
category discuss this relationship.
In particular:
37 presents the pros and cons on decoupling connections and links. 38
recommends that connections be multiplexed over links. Two cases
where this would be useful are presented. The effect on the proposed
protocol is discussed. Both 37 and 38 suggest the inclusion of the
destination socket as part of the text of the message and recommend
that messages should be send over any unblocked link.
44 suggests the use of link numbers in control commands (except RFSs)
due to the 1 to 1 correspondence between links and foreign socket
numbers.
Karp [Page 12]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
48 recommends leaving links and connections coupled.
C.9 Other
Other topics that fall into the category of Host/Host protocol are:
Marking/Padding: see B.2
Record/Message Boundaries: see D.5
Experimentation and Expansion. The assignment of links for
experimentation and expansion is discussed in NWG/RFC #s 37 and 48.
Instance Tag: The addition of an instance tag to the socket
identifier is introduced in 46, is supported by 49 and 50, and is not
recommended in 48. The matter is unresolved (see "To be published",
section C).
Broadcast Facility: A control command to implement a broadcast
facility as introduced in 39. It was not supported in 48.
D. SUBSYSTEM LEVEL PROTOCOL (LEVEL 3)
Official document: none
Unresolved issues: all
To be published: Three committees have been set up to address user
level issues, specifically: logger, console, and TELNET protocols
(D.1, D.2, D.3); data transformation (D.4); and, graphics protocol
(D.6). Status reports will be published prior to the next Network
meeting (May 1971). In addition, a companion paper to 98 discussing
console protocol has been promised by MIT MAC and G. Grossman (Ill.)
will issue an RFC proposing a file transmission protocol.
D.1 Logger Protocol
NWG/RFC #s: 33, 46, 48, 49, 50, 56, 66, 74, 77, 79, 82, 88, 91, 93,
97, 98
Logger Protocol specifies the procedures by which a user gets
connected to a remote Host. The logger is a process, always in
execution, which listens for login requests.
Karp [Page 13]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
In particular:
33 proposes that the logger listen to calls on socket #0. It then
switches to the assigned socket. The sequence of events is
illustrated.
46 proposes a User Control and Communication (UCC) module, which
implements logger protocol and permits the logger to interact with
the NCP. It proposes the use of two full-duplex pseudo-typewriter
connections.
48 proposes that sockets <U, H, 0> and <U, H, 1> designate either the
input and output sockets of a copy of the logger or the console
sockets.
49 is a write-up of a combination of the proposals presented in 46
and 48. 49 presents the disadvantages of the new proposal and reverts
back to supporting the UCC of 46.
50 indicates RAND support for the UCC presented in 46.
56 defines a send-logger and a receive-logger with a full-duplex
connection. The logger handles one request at a time; requests are
queued. The receiver logger is identified as user 0 on socket 0.
66 introduces a dial-up protocol (Initial Connection Protocol, ICP)
to get a process at one site in contact with the logger at another
site.
74 documents the logger implemented at UCSB.
77 and 82 report the discussion of logger protocol at the FJCC 1970
Network meeting. E. Harslem and E. Meyer agreed to write proposals.
79 discusses a conflict between Document No. 1 and NWG/RFC 66
regarding the use of ALL prior to connection establishment.
80 presents a variation of 66 that rectifies the conflict. 80 also
suggests that ICP should apply to more than just the logger i.e., let
user 0 signify the logger.
88 documents the logger implemented as part of NETRJS, which allows
access to RJS at UCLA's CCN. The ICP described in 66 and 80 is
adhered to. The logger is designated as user 0.
91 contains a description of the logger for the PDP-10 at Harvard.
Karp [Page 14]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
93 points out an ambiguity in the Host/Host protocol of Document No.
1 regarding the requirement of message data type for ICP. The
ambiguity is rectified by NG/RFC 102.
97 includes the ICP (as proposed in 80) used to establish connection
to NIC.
98 is the logger protocol proposal issued by E. Meyer.
D.2 Console Protocol
NWG/RFC #s: 20, 44, 46, 48, 49, 50, 56, 66, 74, 77, 82, 88, 91, 96,
97, 98
Console protocol will specify conventions for what goes out over the
network. Included are conventions for echoing, character set,
interrupt or break, end of line, message formats.
In particular:
20 suggests a standard of 7-bit ASCII in an 8-bit byte, with the high
order bit 0.
44 discusses three possibilities for echoing over the network
(echoing, no echoing, optional echoing) and states a preference for
no echoing. 44 also states a preference for establishing a network
common code where all code conversion is performed on outgoing text;
thus, all incoming text would be in the common code.
46 proposes the use of interrupt on the third level. An interrupt
means "quit" when sent from a requestor process to a created process.
The command level is entered.
48 and 49 relegate issues of echoing and code conversion to third
level protocol.
50 and 56 support adoption of ASCII for the network standard
character set. 56 also discusses two uses of break characters
(interrupt): in a panic situation and to exit from subsystem. Three
message formats (character by character, end by carriage return,
several command lines per message) are discussed. A recommendation
that echoing be handled locally is made.
66 specifies that the standard console use 7-bit ASCII in 8 bits with
the 8th bit on (note the conflict with 20). It also specifies the
use of INR for break or interrupt.
74 documents console protocol implemented by UCSB.
Karp [Page 15]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
77 and 82 report on console protocol topics (echoing, full vs half
duplex) discussed at the Network meeting, FJCC 1970.
88 documents conventions used by NETRJS for RJS at CCN, UCLA.
91 discusses code standards.
96 and 97 document conventions used for NIC at SRI ARC.
98 proposes specifications for general console communications and
addresses full vs half duplex, character escapes, and action
characters.
D.3 TELNET Protocol
NWG/RFC #s: 15, 33, 76, 80, 83, 91, 96, 97
TELNET is a subsystem permitting a teletype-like terminal at a remote
Host for function as a teletype at the serving Host. TELNET protocol
specifies user level interface to the network by way of network
system calls.
In particular:
15 introduces the TELNET concept and presents a sample dialogue
between Utah's PDP-10 and SRI's 940. System primitives are proposed.
33 describes TELNET and gives essentially the same example as in 15.
76 describes a terminal user control language for Illinois's PDP-11
ARPA Network Terminal System. The protocol defined permits the user
to utilize the network at a symbolic level.
80 and 83 introduce the concept of a Protocol Manager that can manage
protocol sequences between consoles and the network. The Form
Machine (see D.4) can be used for translations.
91 contains a proposal for a User/User protocol that has the ability
to function as TELNET.
96 describes a series of experiments to be conducted using the TELNET
subsystem at SRI ARC.
97 presents a detailed proposal for a standard TELNET protocol.
Karp [Page 16]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
D.4 NIL, DEL, and Form Machines
NWG/RFC #s: 5, 31, 42, 51, 63, 80, 83, 96
NIL, DEL, and Form Machines are proposals of similar methods for
adapting user programs and/or data to the network. A committee
chaired by J. Heafner has been formed to plan, implement, and
exercise a language for reconfiguring data streams.
In particular:
NIL (Network Interchange Language), described in 51, introduces the
concept of an abstract network machine which would permit a user to
consider the computer network as an overall computing facility. All
dialogue would take place between hosts and the network machine. NIL
permits the description of the environment and the description of the
Front End of an interactive system. Sublanguages for describing
control, operation, data declaration, and environment are used. With
NIL, the network machine can operate in standard mode as well as
user-defined extended mode. The network machine can act as a user of
a Host; conversely, a Host can be a user of a network machine. Each
Host will have a generator to generate a translator from the
descriptive sublanguage inputs.
DEL (Decode - Encode Language), described in 5, utilizes a front end
translator at the using site to translate the using site characters
to the server host character set. Return messages are subsequently
translated locally to the local standard. Immediate feedback in an
interactive mode is also handled locally. DEL can be used for the
operation of large display-oriented systems. Provisions are given
for representing a universal hardware. The syntax is included.
Two proposals for the Form Machine have been given. 80 introduces the
concept of the Form Machine, an experimental software package
operating on regular expressions that describe data formats. 83
presents a different approach: a syntax-driven interpreter which
operates on a grammar which is an _ordered_ set of replacement rules.
83 contains a description of the Form Machine with some examples of
replacement rules for particular data types. Application of the
Form-Machine to program protocols is also discussed.
31 proposes a message description language as a standard symbolic
method for defining and describing binary messages. In the future,
the descriptive language could be used as input to generators of data
translation programs.
42 proposes the use of message data types prior to the development of
network languages specifying the syntax and semantics of messages.
Karp [Page 17]
RFC 100 Categorization & Guide to NWG/RFC's 26 February 1971
Programs would extract the message data type and transform the data
accordingly. Both standard and local types would be handled (as in
RFC #51), probably using tables stored at one location such as NIC.
62 presents data typed codes.
96 includes a discussion on a Front End for NLS (T) and suggests that
further study be given to standard languages as presented in 51.
D.5 Record/Message Boundaries
NWG/RFC #s: 13, 49, 50, 58, 63, 77, 82, 91
Positions that no special structures should be imposed on data
transmission are presented in 49 and 91. 50 and 58 disagree. 58
claims that logical and physical message distinctions exist and that
logical messages must begin on a physical message boundary.
63 reports a decision from a meeting that records may begin anywhere
in a message. In a later meeting, 77 and 82, the issue was reopened.
Discussion included consideration of methods of indicating the end of
message and alternatives were given. Earlier RFCs had discussed
these alternatives: 13 proposes a 0 length message to specify EOF; 50
proposes use of a bit count preceding the transmission and discusses
solutions to the problem of dropping bits.
D.6 Network Graphics
NWG/RFC #s: 43, 77, 80, 82, 86, 87, 89, 94
Proposals specifying network graphics protocol are in the formative
stages.
In particular:
43 mentions LIL, in interpretable language at Lincoln Labs that can
handle interactive graphics.
77 and 82 discuss the formation of a working group to specify
procedures for using graphics over the network.
80 states that graphics oriented descriptions will added to the Form
Machine.