File: rfc114.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 38,981 bytes parent folder | download | duplicates (5)
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






Network Working Group                                         A. Bhushan
Request for Comments: 114                                MIT Project MAC
NIC: 5823                                                  16 April 1971


                        A FILE TRANSFER PROTOCOL


I. Introduction

   Computer network usage may be divided into two broad categories --
   direct and indirect.  Direct usage implies that you, the network
   user, are "logged" into a remote host and use it as a local user.
   You interact with the remote system via a terminal (teletypewriter,
   graphics console) or a computer.  Differences in terminal
   characteristics are handled by host system programs, in accordance
   with standard protocols (such as TELNET (RFC 97) for teletypewriter
   communications, NETRJS (RFC 88) for remote job entry).  You, however,
   have to know the different conventions of remote systems, in order to
   use them.

   Indirect usage, by contrast, does not require that you explicitly log
   into a remote system or even know how to "use" the remote system.  An
   intermediate process makes most of the differences in commands and
   conventions invisible to you.  For example, you need only know a
   standard set of network file transfer commands for your local system
   in order to utilize remote file system.  This assumes the existence
   of a network file transfer process at each host cooperating via a
   common protocol.

   Indirect use is not limited to file transfers.  It may include
   execution of programs in remote hosts and the transfer of core
   images.  The extended file transfer protocol would facilitate the
   exchange of programs and data between computers, the use of storage
   and file handling capabilities of other computers (possibly including
   the trillion-bit store data computer), and have programs in remote
   hosts operate on your input and return an output.

   The protocol described herein has been developed for immediate
   implementation on two hosts at MIT, the GE645/Multics and the PDP-
   10/DM/CG-ITS (and possibly Harvard's PDP-10).  An interim version
   with limited capabilities is currently in the debugging stage. [1]
   Since our implementation involves two dissimilar systems (Multics is
   a "service" system, ITS is not) with different file systems (Multics
   provides elaborate access controls, ITS provides none), we feel that
   the file transfer mechanisms proposed are generalizable.  In
   addition, our specification reflects a consideration of other file
   systems on the network.  We conducted a survey [2] of network host



Bhushan                                                         [Page 1]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   systems to determine the requirements and capabilities.  This paper
   is a "first cut" at a protocol that will allow users at any host on
   the network to use the file system of every cooperating host.

II.  Discussion

   A few definitions are in order before the discussion of the protocol.
   A file is an ordered set consisting of computer instructions and/or
   data.  A file can be of arbitrary length [3].  A named file is
   uniquely identified in a system by its file name and directory name.
   The directory name may be the name of a physical directory or it may
   be the name of a physical device.  An example of physical directory
   name is owner's project-programmer number and an example of physical
   device name is tape number.

   A file may or may not have access controls associated with it.  The
   access controls designate the users' access privileges.  In the
   absence of access controls, the files cannot be protected from
   accidental or unauthorized usage.

   A principal objective of the protocol is to promote the indirect use
   of computers on the network.  Therefore, the user or his program
   should have a simple and uniform interface to the file systems on the
   network and be shielded from the variations in file and storage
   systems of different host computers.  This is achieved by the
   existence of a standard protocol in each host.

   Criteria by which a user-level protocol may be judged were described
   by Mealy in RFC 91, as involving the notion of logical records,
   ability to access files without program modifications, and
   implementability.  I would add to these efficiency, extendibility,
   adaptability, and provision of error-recovery mechanisms.

   The attempt in this specification has been to enable the reliable
   transfer of network ASCII (7-bit ASCII in 8-bit field with leftmost
   bit zero) as well as "binary" data files with relative ease.  The use
   of other character codes, such as EBCDIC, and variously formatted
   data (decimal, octal, ASCII characters packed differently) is
   facilitated by inclusion of data type in descriptor headings.  An
   alternative mechanism for defining data is also available in the form
   of attributes in file headings.  The format control characters
   reserved for the syntax of this protocol have identical code
   representation in ASCII and EBCDIC.  (These character are SOH, STX,
   ETX, DC1, DC2, DC3, US, RS, GS, and FS.)







Bhushan                                                         [Page 2]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   The notion of messages (the physical blocks of data communicated
   between NCP's) is suppressed herein and that of "logical" records and
   transactions is emphasized.  The data passed by the NCP is parsed
   into logical blocks by use of simple descriptors (code and count
   mechanisms) as described in Section III.  The alternative to count is
   fixed length blocks or standard end-of-file characters (scan data
   stream).  Both seem less desirable than count.

   The cooperating processes may be "daemon" processes which "listen" to
   agreed-upon sockets, and follow the initial connection protocol much
   in the same way as a "logger" does.  We recommend using a single
   full-duplex connection for the exchange of both data and control
   information [4], and using CLS to achieve synchronization when
   necessary (a CLS is not transmitted until a RFNM is received).

   The user may be identified by having the using process send at the
   start of the connection the user's name information (either passed on
   by user or known to the using system) [5].  This user name
   information (a sequence of standard ASCII characters), along with the
   host number (known to the NCP), positively identifies the user to the
   serving process.

   At present, more elaborate access control mechanisms, such as
   passwords, are not suggested.  The user, however, will have the
   security and protection provided by the serving system.  The serving
   host, if it has access controls, can prevent unprivileged access by
   users from other host sites.  It is up to the using host to prevent
   its own users from violating access rules.

   The files in a file system are identified by a pathname, similar to
   the labels described in RFC 76 (Bouknight, Madden, and Grossman).
   The pathname contains the essential information regarding the storage
   and retrieval of data.

   In order to facilitate use, default options should be provided.  For
   example, the main file directory on disk would be the default on the
   PDP-10/ITS, and a pool directory would be the default on Multics.

   The file to be transferred may be a complete file or may consist of
   smaller records.  It may or may not have a heading.  A heading should
   contain ASCII or EBCDIC characters defining file attributes.  The
   file attributes could be some simple agreed-upon types or they could
   be described in a data reconfiguration or interpretation language
   similar to that described in RFC 83 (Anderson, Haslern, and Heffner),
   or a combination.






Bhushan                                                         [Page 3]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   The protocol does not restrict the nature of data in the file.  For
   example, a file could contain ASCII text, binary core image, graphics
   data or any other type of data.  The protocol includes an "execute"
   request for files that are programs.  This is intended to facilitate
   the execution of programs and subroutines in remote host computers
   [6].

III.  SPECIFICATIONS

1. Transactions

   1A.   The protocol is transaction-oriented.  A transaction is defined
         to be an entity of information communicated between cooperating
         processes.

   1B.   Syntax

         A transaction has three fields, a 72-bit descriptor field and
         variable length (including zero) data and filler fields, as
         shown below.  The total length of a transaction is (72 + data +
         filler) bits.

   | <code><filler count><NUL><data count><NUL> |    <data><filler>   |
   | |____||____________||___||__________||___| |    |____________|   |
   |   |         |         |        |       |   |          |          |
   | 24-bits   8-bits    8-bits  24-bits  8-bits|    variable length  |
   | <-------descriptor field 72-bits---------> |<--data and filler-->|
   |                                            |                     |

   1C.   Semantics

         The code field has three 8-bit bytes.  The first byte is
         interpreted as transaction type, the second byte as data type
         and the third byte as extension of data type.

         The filler count is a binary count of bits used as "filler"
         (i.e., not information) at the end of a transaction [7].  As
         the length of the filler count field is 8-bits, the number of
         bits of filler shall not exceed 255 bits.

         The data count is a binary count of the number of data (i.e.,
         information) bits in the data field, not including filler bits.
         The number of data bits is limited to (2^24-1), as there are 24
         bits in the data count field.







Bhushan                                                         [Page 4]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         The NUL bytes are inserted primarily as fillers in the
         descriptor field and allow the count information to appear at
         convenient word boundaries for different word length machines
         [8].

2.  Transaction Types

   2A.   A transaction may be of the following four basic types:
         request, response, transfer and terminate.  Although large
         number of request and transfer types are defined,
         implementation of a subset is specifically permitted.  Host
         computers, on which a particular transaction type is not
         implemented, may refuse to accept that transaction by
         responding with an unsuccessful terminate.

         The following transaction type codes are tentatively defined:

         Transaction Type                       Transaction Type Code

                                             ASCII   Octal   Hexidecimal

         Request
                 Identify                        I       111     49
                 Retrieve                        R       122     52
                 Store                           S       123     53
                 Append                          A       101     41
                 Delete                          D       104     44
                 Rename                          N       116     4E
                 addname (Plus)                  P       120     50
                 deletename (Minus)              M       115     4D
                 Lookup                          L       114     4C
                 Open                            O       117     4F
                 Close                           C       103     43
                 Execute [9]                     E       105     45

         Response
                 ready-to-receive (rr)           <       074     3C
                 ready-to-send (rs)              >       076     3E

         Transfer
                 complete_file                   *       052
                 heading                         #       043     23
                 part_of_file                    '       054     2C
                 last_part                       .       056     2E

         Terminate
                 successful (pos.)               +       053     2B
                 unsuccessful (neg.)             -       055     2D



Bhushan                                                         [Page 5]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2B.   Syntax

         In the following discussion US, RS, GS, FS, DC1, DC2, and DC3
         are the ASCII characters, unit separator (octal 037), record
         separator (octal 036), group separator (octal 035), file
         separator (octal 034), device control 1 (octal 021), device
         control 2 (octal 022), and device control 3 (octal 023),
         respectively.  These have an identical interpretation in
         EBCDIC.

   2B.1  Requests

         Identify, retrieve, store, append, delete, open, lookup and
         execute requests have the following data field:

                       <path name>

                Rename request has the data field:

                       <path name> GS <name>

                Addname and deletename requests have the data field:

                       <path name> GS <filenames>

         where pathname [10], name and filenames have the following
         syntax (expressed in BNF, the metalanguage of the ALGOL 60
         report):

         <pathname> ::= <device name>|<name>|<pathname>US<name>
         <device name> ::= DC1<name>

         <name> ::= <char> | <name> <char>
         <char> ::= All 8-bit ASCII or EBCDIC characters except

                 US, RS, GS, FS, DC1, DC2, AND DC3.

         <filenames> ::= <name>|<filenames> RS <name>

         The data type for the request transaction shall be either A
         (octal 101 for ASCII, or E (octal 105) for EBCDIC [11].

         Some examples of pathname are:

         DC1 MT08
         DC1 DSK 1.2 US Net<3> US J.Doe US Foo
         udd US proj. US h,n/x US user US file
         filename 1 filename 2



Bhushan                                                         [Page 6]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2B.2  Responses

         The response transactions shall normally have an empty data
         field.

   2B.3  Transfers

         The data types defined in section 4 will govern the syntax of
         the data field in transfer transactions.  No other syntactical
         restrictions exist.

   2B.4  Terminates

         The successful terminate shall normally have an empty data
         field.  The unsuccessful terminate may have a data field
         defined by the data types A (octal 101) for ASCII, E (octal
         105) for EBCDIC, or S (octal 123) for status.

         A data type code of 'S' would imply byte oriented error return
         status codes in the data field.  The following error return
         status codes are defined tentatively:

         Error Code Meaning                        Error Code
                                             ASCII   Octal  Hexadecimal

         Undefined error                       U       125     55
         Transaction type error                T       124     54
         Syntax error                          S       123     53
         File search failed                    F       106     46
         Data type error                       D       104     44
         Access denied                         A       101     41
         Improper transaction sequence         I       111     49
         Time-out error                        O       117     4F
         Error condition by system             E       105     45

   2C.   Semantics

   2C.1  Requests

         Requests are always sent by using host.  In absence of a device
         name or complete pathname, default options should be provided
         for all types of requests.

         _Identify_ request identifies the user as indicated by
         <pathname> from serving to using host.

         _Retrieve_ request achieves the transfer of file specified in
         <pathname> from serving to using host.



Bhushan                                                         [Page 7]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         _Store_  request achieves the transfer of file specified in
         <pathname> from using to serving host.

         _Append_ request causes data to be added to file specified in
         pathname.

         _Rename_ request causes name of file specified in <pathname> to
         be replaced by name specified in <name>.

         _Delete_ request causes file specified in <pathname> to be
         deleted.  If an extra level of protection for delete is desired
         (such as the query 'Do you wish to delete file x?'), it is to
         be a local implementation option.

         _Addname_ and _deletename_ requests cause names in <filenames>
         to be added or deleted to existing names of file specified in
         <pathname>.  These requests are useful in systems such as
         Multics which allow multiple names to be associated with a
         file.

         _Lookup_ request achieves the transfer of attributes (such as
         date last modified, access list, etc) of file specified in
         <pathname>, instead of the file itself.

         _Open_ request does not cause a data transfer, instead file
         specified in <pathname> is "opened" for retrieve (read) or
         store (write).  Subsequent requests are then treated as
         requests pertaining to the file that is opened till such a time
         that a close request is received.

         _Execute_ request achieves the execution of file specified in
         <pathname>, which must be an executable program.  Upon receipt
         of rr response, using host will transmit the necessary input
         data (parameters, arguments, etc).  Upon completion of
         execution serving host will send the results to using host and
         terminate [12].

   2C.2  Response

         Responses are always sent by serving host.  The rr response
         indicates that serving host is ready to receive the file
         indicated in the preceding request.  The rs response indicates
         that the next transaction from serving host will be the
         transfer of file indicated in the preceding request.







Bhushan                                                         [Page 8]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2C.3  Transfers

         Transfers may be sent by either host.  Transfer transactions
         indicate the transfer of file indicated by a request.  Files
         can be transferred either as complete_file transactions or as
         part_of_file transactions followed by last_part transactions.
         The file may also have a heading transaction in the beginning.
         The syntax of a file, therefore, may be defined as:

         <file> ::= <text> | <heading> <text>
         <text> ::= <complete_file> | <parts> <last_part>
         <parts> ::= <part_of_file> | <parts> <part_of_file>

         Headings may be used to communicate the attributes of files.
         The form of headings is not formally specified but is discussed
         in Section IV as possible extension to this protocol.

   2C.4  Terminates

         The successful terminate is always sent by serving host.  It
         indicates to using host that serving host has been successful
         in serving the request and has gone to an initial state.  Using
         host will then inform user that his request is successfully
         served, and go to an initial state.

         The unsuccessful terminate may be sent by either host.  It
         indicates that sender of the terminate is unable to (or does
         not not wish to) go through with the request.  Both hosts will
         then go to their initial states.  The using host will inform
         the user that his request was aborted.  If any reasons for the
         unsuccessful terminate (either as text or as error return
         status codes) are received, these shall be communicated to the
         user.

3.    Transaction Sequence

   3A.   The transaction sequence may be defined as an instance of file
         transfer, initiated by a request and ended by a terminate [13].
         The exact sequence in which transactions occur depends on the
         type of request.  A transaction sequence may be aborted anytime
         by either host, as explained in Section 3C.

   3B.   Examples

         The identify request doesn't require a response or terminate
         and constitutes a transaction sequence by itself.





Bhushan                                                         [Page 9]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         Rename, delete, addname, deletename and open requests involve
         no data transfer but require terminates.  The user sends the
         request and the server sends a successful or an unsuccessful
         terminate depending on whether or not he is successful in
         complying with the request.

         Retrieve and Lookup requests involve data transfer from the
         server to the user.  The user sends the request, the server
         responds with a rs, and transfers the data specified by the
         request.  Upon completion of the data transfer, the server
         terminates the transaction sequence with a successful terminate
         if all goes well, or with an unsuccessful terminate is errors
         were detected.

         Store and Append requests involve data transfer from the user
         to server.  The user sends the request and the server responds
         with a rr.  The user then transfers the data.  Upon receiving
         the data, the server terminates the sequence.

         Execute request involves transfer of inputs from user to
         server, and transfer of outputs from server to user.  The user
         sends the request to which the server responds with rr.  The
         user then transfers the necessary inputs.  The server
         "executes" the program or subroutine and transfers the outputs
         to the user.  Upon completion of the output transfer, the
         server terminates the transaction sequence.

   3C.   Aborts

         Either host may abort the transaction sequence at any time by
         sending an unsuccessful terminate, or by closing the connection
         (NCP to transmit a CLS for the connection).  The CLS is a more
         drastic type of abort and shall be used when there is a
         catastrophic failure or when an abort is desired in the middle
         of a long file transfer.  The abort indicates to the receiving
         host that the other host wishes to terminate the transaction
         sequence and is now in the initial state.  When CLS is used to
         abort, the using host will reopen the connection.

4.    Data Types

   4A.   The data type code together with the extension code defines the
         manner in which the data field is to be parsed and interpreted
         [14].  Although a large number of data types are defined,
         specific implementations may handle only a limited subset of
         data types.  It is recommended that all host sites accept the





Bhushan                                                        [Page 10]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         "network ASCII" and "binary" data types.  Host computers which
         do not "recognize" particular data types may abort the
         transaction sequence and return a data type error status code.

   4B.   The following data types are tentatively defined.  The code in
         the type and extension field is represented by its ASCII
         equivalent with 8th bit as zero.












































Bhushan                                                        [Page 11]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


        Data Type                                    Code
                                     Byte Size       Type     Extension
ASCII character, bit8=0 (network)       8             A          NUL

ASCII characters, bit8=1                8             A          1

ASCII characters, bit8=even parity      8             A          E

ASCII characters, bit8=odd parity       8             A          O

ASCII characters, 8th bit info.         8             A          8

ASCII characters, 7 bits                7             A          7

ASCII characters, in 9-bit field        9             A          9
ASCII formatted files (with SOH,
        STX, ETX, etc.)                 8             A          F
DEC-packed ASCII (5 7-bit char.,
        36th bit 1 or 0)                36            A          D
EBCDIC characters                       8             E         NUL
SIXBIT characters                       6             S         NUL
Binary data                             1             B         NUL
Binary bytes (size is binary ext.)      1-255         B        (any)
Decimal numbers, net ASCII              8             D          A
Decimal numbers, EBCDIC                 8             D          E
Decimal numbers, sixbit                 6             D          S
Decimal numbers, BCD (binary coded)     4             D          B
Octal numbers, net. ASCII               8             O          A
Octal numbers, EBCDIC                   8             O          E
Octal numbers, SIXBIT                   6             O          S
Hexadecimal numbers, net. ASCII         8             H          A
Hexadecimal numbers, EBCDIC             8             H          E
Hexadecimal numbers, SIXBIT             6             H          S
Unsigned integers, binary (ext.
        field is byte size)             1-225         U        (any)
Sign magnitude integers (field is
        binary size)                    1-255         I        (any)
2's complement integers (ext.
        field is byte size)             1-255         2        (any)
1's complement integers (ext.
        field is byte size)             1-255         1        (any)
Floating point (IBM360)                 32            F          I
Floating point (PDP-10)                 36            F          D
Status codes                            8             S         NUL







Bhushan                                                        [Page 12]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   4C.   The data type information is intended to be interpretive.  If a
         host accepts a data type, it can interpret it to a form suited
         to its internal representation of characters or numbers [15].
         Specifically when no conversion is to be performed, the data
         type used will be binary.  The implicit or explicit byte size
         is useful as it facilitates storing of data.  For example, if a
         PDP-10 receives data types A, A1, AE, or A7, it can store the
         ASCII characters five to a word (DEC-packed ASCII).  If the
         datatype is A8 or A9, it would store the characters four to a
         word.  Sixbit characters would be stored six to a word.  If
         conversion routines are available on a system, the use of
         system program could convert the data from one form to another
         (such as EBCDIC to ASCII, IBM floating point to DEC floating
         point, Decimal ASCII to integers, etc.).

5. Initial Connection, CLS, and Identifying Users

   5A.   There will be a prearranged socket number [16] for the
         cooperating process on the serving host.  The connection
         establishment will be in accordance with the initial connection
         protocol of RFC 66 as modified by RFC 80.  The NCP dialog would
         be:

              user to server:    RTS<us><3><p>

         if accepted, server to user:    STR<3><us><CLS><3><us>
              server to user on link p:  <ss>
              server to user:    STR<ss+1><us>RTS<ss><us+1><q>
              user to server:    STR<us><ss+1>RTS<us+1><ss><r>

         This sets up a full-duplex connection between user and server
         processes, with server receiving through local socket ss from
         remote socket us+1 via link q, and sending to remote socket us
         through local socket ss+1 via link r.

   5B.   The connection will be broken by trading a CLS between the
         NCP'S for each of the two connections.  Normally the user will
         initiate the CLS.

         CLS may also be used by either the user or the server to abort
         a data transmission in the middle.  If a CLS is received in the
         middle of a transaction sequence, the whole transaction
         sequence will be aborted.  The using host will then reopen the
         connection.

   5C.   The first transaction from the user to server will be the
         identify transaction.  The users will be identified by the
         pathname in data field of the transaction which should be a



Bhushan                                                        [Page 13]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         form acceptable to the server.  The server is at liberty to
         truncate pathnames for its own use.  Since the identify
         transaction does not require a response or terminate, the user
         can proceed directly with other requests.

IV.  Extensions to Protocol

   The protocol specified above has been designed to be extendable.  The
   obvious extensions would be in the area of transaction types (new
   types of requests), error return status words, and data types.  Some
   of the non-obvious extensions, that I can visualize are provisions of
   access control mechanisms, developing a uniform way of specifying
   file attributes in headings of files, increasing the scope of the
   execute command to include subroutine mediation, and the provision of
   transaction sequence identification numbers to facilitate handling of
   multiple requests over the same connection pair.

   Users of protected file systems should be able to have a reasonable
   degree of confidence in the ability of the serving process to
   identify remote users correctly.  In the absence of such confidence,
   some users would not be willing to give access to the serving process
   (especially write access).  Inclusion of access control mechanisms
   such as passwords, is likely to enhance the indirect use of network
   by users who are concerned about privacy and security.  A simple
   extension to the protocol would be to have the serving host sent a
   transaction type "password?" after it receives user name.  Upon
   receipt of "password?" the using host will transmit the password,
   which when successfully acknowledged, would indicate to the user that
   requests may proceed.

   There are a number of file attributes which properly belong in the
   heading of a file rather than the file itself or the data type in
   descriptors of transactions.  Such attributes include access control
   lists, date file was last modified, information about the nature of
   file, and description of its contents in a data description or data
   reconfiguration language.  Some uniformity in the way file attributes
   are specified would be useful.  Until then, the interpretation of the
   heading would be up to the user or the using process.  For example,
   the heading of files which are input to a data reconfiguration (form)
   machine may be the desired transformations expressed in the
   reconfiguration language.

   The "execute" command which achieves the execution of programs
   resident in remote hosts is a vital part of indirect use of remote
   hosts.  The present scope of the execute command, as outlined in the
   specifications, is somewhat limited.  It assumes that the user or





Bhushan                                                        [Page 14]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   using process is aware of the manner in which the arguments and
   results should be exchanged.  One could broaden the scope of the
   execute command by introducing a program mediation protocol [17].

   The present specification of the protocol does not allow the
   simultaneous transfer and processing of multiple requests over the
   same pair of connections.  If such a capability is desired, there is
   an easy way to implement it which only involves a minor change.  A
   transaction sequence identification number (TSid) could replace a NUL
   field in the descriptor of transactions.  The TSid would facilitate
   the coordination of transactions, related to a particular transaction
   sequence.  The 256 code combinations permitted by the TSid would be
   used in a round-robin manner (I can't see more than 256 outstanding
   requests between two user-processes in any practical implementation).
   An alternate way of simultaneous processing of requests is to open
   new pairs of connection.  I am not sure as to how useful simultaneous
   processing of requests is, and which of the two is a more reasonable
   approach.

V. Conclusions

   I tried to present a user-level protocol that will permit users and
   using programs to make indirect use of remote host computers.  The
   protocol facilitates not only file system operations but also program
   execution in remote hosts.  This is achieved by defining requests
   which are handled by cooperating processes.  The transaction sequence
   orientation provides greater assurance and would facilitate error
   control.  The notion of data types is introduced to facilitate the
   interpretation, reconfiguration and storage of simple and limited
   forms of data at individual host sites.  The protocol is readily
   extendible.

Endnotes

   [1] The interim version of the protocol, limited to transfer of ASCII
   files, was developed by Chander Ramchandani and Howard Brodie of
   Project MAC.  The ideas of transactions, descriptors, error recovery,
   aborts, file headings and attributes, execution of programs, and use
   of data types, pathnames, and default mechanisms are new here.
   Howard Brodie and Neal Ryan have coded the interim protocol in the
   PDP-10 and the 645, respectively.

   [2] The network system survey was conducted last fall by Howard
   Brodie of Project MAC, primarily by telephone.

   [3] PDP-10 Reference Handbook, page 306.





Bhushan                                                        [Page 15]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   [4] We considered using two full-duplex links, one for control
   information, the other for data.  The use of a separate control link
   between the cooperating processes would simplify aborts, error
   recoveries and synchronization.  The synchronization function may
   alternatively be performed by closing the connection (in the middle
   of a transaction sequence) and reopening it with an abort message.
   (The use of INR and INS transmitted via the NCP control link has
   problems as mentioned by Kalin in RFC 103.)  We prefer the latter
   approach.

   [5] Identifying users through use of socket numbers is not practical,
   as unique user identification numbers have not been implemented, and
   file systems identify users by name, not number.

   [6] This subject is considered in detail by Bob Metcalfe in a
   forthcoming paper.

   [7] Filler bits may be necessary as particular implementations of
   NCP's may not allow the free communication of bits.  Instead the
   NCP's may only accept bytes, as suggested in RFC 102.  The filler
   count is needed to determine the boundary between transactions.

   [8] 72-bits in descriptor field are convenient as 72 is the least
   common multiple of 6, 8, 9, 18, 24 and 30, the commonly encountered
   byte sizes on the ARPA network host computers.

   [9] The execute request is intended to facilitate the indirect
   execution of programs and subroutines.  However, this request in its
   present form may have only limited use.  A subroutine or program
   mediation protocol would be required for broader use of the execute
   feature.  Metcalfe considers this problem in a forthcoming paper.

   [10] The pathname idea used in Multics is similar to that of labels
   in RFC 76 by Bouknight, Madden and Grossman.

   [11] We, however, urge the use of standard network ASCII.

   [12] The exact manner in which the input and output are transmitted
   would depend on specific mediation conventions.  Names of input and
   output files may be transmitted instead of data itself.

   [13] The transactions (including terminate) are not "echoed", as
   echoing does not solve any "hung" conditions.  Instead time-out
   mechanisms are recommended for avoiding hang-ups.

   [14] The data type mechanism suggested here does not replace data
   reconfiguration service suggested by Harslem and Heafner in RFC 83
   and NIC5772.  In fact, it complements the reconfiguration.  For



Bhushan                                                        [Page 16]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   example, data reconfiguration language can be expressed in EBCDIC,
   Network ASCII or any other code that form machine may "recognize".
   Subsequent data may be transmitted binary, and the form machine would
   reconfigure it to the required form.  I have included in data types,
   a large number suggested by Harslem and Heafner, as I do not wish to
   preclude interpretation, reconfiguration and storage of simple forms
   of data at individual host sites.

   [15] The internal character representation in the hosts may be
   different even in ASCII.  For example PDP-10 stores 7-bit characters,
   five per word with 36th bit as don't care, while Multics stores them
   four per word, right-justified in 9-bit fields.

   [16] It seems that socket 1 has been assigned to logger and socket 5
   to NETRJS.  Socket 3 seems a reasonable choice for the file transfer
   process.

   [17] The term program mediation was suggested by Bob Metcalfe who is
   intending to write a paper on this subject.


         [ This RFC was put into machine readable form for entry ]
             [ into the online RFC archives by Ryan Kato 6/01]




























Bhushan                                                        [Page 17]