File: rfc1068.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 (1515 lines) | stat: -rw-r--r-- 49,490 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
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515






Network Working Group                                         A. DeSchon
Request for Comments: 1068                                     R. Braden
                                                                     ISI
                                                             August 1988

                Background File Transfer Program (BFTP)


Status of This Memo

   This memo describes an Internet background file transfer service that
   is built upon the third-party transfer model of FTP.  No new
   protocols are involved.  The purpose of this memo is to stimulate
   discussion on new Internet service modes.  Distribution of this memo
   is unlimited.

1. Introduction

   For a variety of reasons, file transfer in the Internet has generally
   been implemented as an interactive or "foreground" service.  That is,
   a user runs the appropriate local FTP user interface program as an
   interactive command and requests a file transfer to occur in real
   time.  If the transfer should fail to complete for any reason, the
   user must reissue the transfer request.  Foreground file transfer is
   relatively simple to implement -- no subtleties of queuing or stable
   storage -- and in the early days of networking it provided excellent
   service, because the Internet/ARPANET was lightly loaded and
   reasonably reliable.

   More recently, the Internet has become increasingly subject to
   congestion and long delays, particularly during times of peak usage.
   In addition, as more of the world becomes interconnected, planned and
   unplanned outages of hosts, gateways, and networks sometimes make it
   difficult for users to successfully transfer files in foreground.

   Performing file transfer asynchronously (i.e., in "background"),
   provides a solution to some of these problems, by eliminating the
   requirement for a human user to be directly involved at the time that
   a file transfer takes place.  A background file transfer service
   requires two components: a user interface program to collect the
   parameters describing the required transfer(s), and a file transfer
   control (FTC) daemon to carry them out.









DeSchon & Braden                                                [Page 1]

RFC 1068                                                     August 1988


   Background file transfer has a number of potential advantages for a
   user:

   o    No Waiting

        The user can request a large transfer and ignore it until a
        notification message arrives through some common channel (e.g.,
        electronic mail).

   o    End-to-end Reliability

        The FTC daemon can try a transfer repeatedly until it either
        succeeds or fails permanently.  This provides reliable end-to-
        end delivery of a file, in spite of the source or destination
        host being down or poor Internet connectivity during some time
        period.

   o    Multiple File Delivery

        In order for background file transfer to be accepted in the
        Internet, it may have to include some "value-added" services.
        One such service would be an implementation of a multiple file
        transfer capability for all hosts.  Such a facility is suggested
        in RFC-959 (see the description of "NLST") and implemented in
        some User-FTP programs.

   o    Deferred Delivery

        The user may wish to defer a large transfer until an off-peak
        period.  This may become important when parts of the Internet
        adopt accounting and traffic-based cost-recovery mechanisms.


   There is a serious human-engineering problem with background file
   transfer: if the user makes a mistake in entering parameters, this
   mistake may not become apparent until much later.  This can be the
   cause of severe user frustration.  To avoid this problem, the user
   interface program ought to verify the correctness of as many of the
   parameters as possible when they are entered.  Of course, such
   foreground verification of parameters is not possible if the remote
   host to which the parameters apply is currently unreachable.

   To explore the usefulness of background file transfer in the present
   Internet, we have implemented a file-mover service which we call the
   Background File Transfer Program or BFTP.

   Section 2 describes BFTP and Section 3 presents our experience and
   conclusions.  The appendices contain detailed information about the



DeSchon & Braden                                                [Page 2]

RFC 1068                                                     August 1988


   user interface language for BFTP, a description of the program
   organization, and sample execution scripts.

2. Background File Transfer Program

   2.1 General Model

      In the present BFTP design, its user interface program and its FTC
      daemon program must execute on the same host, which we call the
      BFTP control host.

      Through the user interface program, a BFTP user will supply all of
      the parameters needed to transfer a file from source host S to
      destination host D, where S and D may be different from the BFTP
      control host.  These parameters include:

      o    S and D host names,

      o    login names and passwords on S and D hosts, and

      o    S and D file names (and optionally, directories).


      The user may also specify a number of optional control parameters:

      *    Source file disposition -- Copy, move (i.e., copy and
           delete), or simply delete the source file.  The default is
           copy.

      *    Destination file operation -- Create/Replace, append to, or
           create a unique destination file.  The default is
           create/replace ("STOR").

      *    FTP Parameters -- Explicitly set any of the FTP type, mode,
           or structure parameters at S and D hosts.

      *    Multiple Transfers -- Enable "wildcard" matching to perform
           multiple transfers.

      *    Start Time -- Set the time of day for the first attempt of
           the transfer. The default is "now" (i.e., make the first
           attempt as soon as the request has been queued for the FTC
           daemon).


      Finally, the user specifies a mailbox to which a completion
      notification message will be sent, and "submits" the request to
      the FTC daemon queue.  The user can then exit the BFTP user



DeSchon & Braden                                                [Page 3]

RFC 1068                                                     August 1988


      interface program.

      If the transfer should fail permanently, the FTC daemon will send
      a notification message to the user's mailbox.  In the event of a
      temporary failure (e.g., a broken TCP connection), the FTC daemon
      will log the failure and retry the transfer after some timeout
      period.  The retry cycles will be repeated until the transfer
      succeeds or until some maximum number of tries specified has been
      reached.  In either case, a notification message will then be sent
      to the user's mailbox.

      The user can check on the progress of the transfer by reentering
      the BFTP user interface program, supplying a key that was defined
      with the request, and displaying the current status of the
      request.  The user may then cancel the request or leave it in the
      queue.

      The BFTP program includes a server-Telnet module, so it can be
      executed as a remotely-accessible service that can be reached via
      a Telnet connection to the BFTP well-known port (152).  This
      allows a user on any Internet host to perform background file
      transfers without running BFTP locally, but instead opening a
      Telnet connection to port 152 on a BFTP service host.  Of course,
      a user can also run the local BFTP user interface program directly
      on any host that supports it and for which the user has login
      privileges.

      The next section discusses how BFTP uses standard FTP servers to
      perform the transfers, while the following section covers the user
      interface of BFTP.

   2.2 File Transfer Mechanics for BFTP

      The BFTP makes use of the "third party" or "Server-Server" model
      incorporated in the Internet File Transfer Protocol [RFC-959].
      Thus, the FTC daemon opens FTP control connections to the existing
      FTP servers on source host S and destination host D and instructs
      them to transfer the desired file(s) from S to D.  The S and D
      hosts may be any two Internet hosts supporting FTP servers (but at
      least one of them must support the FTP "PASV" command).  This
      approach allows the implementation of a background file transfer
      capability for the entire Internet at a very low cost.

      Figure 1 illustrates the BFTP model of operation.  Note that the
      BFTP control host is not necessarily the same as S or D.  Figure 2
      illustrates the FTP command interchange used in a typical Server-
      Server file transfer operation; this may be compared with the
      User-Server FTP scenario illustrated in Section 7 of RFC-959.



DeSchon & Braden                                                [Page 4]

RFC 1068                                                     August 1988


      Since BFTP may be asked to transfer files between any two hosts in
      the Internet, it must support all the file types and transfer
      modes that are defined in RFC-959, not just a subset implemented
      by particular hosts.

      BFTP supports the transfer of a set of files in a single request,
      using the standard technique:

      (1)  Send an NLST command to the source host S, specifying a
           pathname containing "wildcard" characters.  The reply will
           contain a list of matching source file names.

      (2)  Execute a separate transfer operation for each file in this
           list.  The destination file name in each case is assumed to
           be the same as the source file name; this requires that these
           names be compatible with the naming conventions of D.

      It will typically be necessary to specify working directories for
      the transfers at S and D, so the file names will be simple,
      unstructured names on each system.

      This approach depends upon the wildcard matching capability of the
      source host S.  A more general implementation would acquire a
      complete list of the file names from the source host and do the
      matching in the FTC daemon, for example using a regular-expression
      matcher.  Another useful extension would be a general pattern-
      matching file name transformation capability (e.g., like the one
      included in the 4.3BSD version of FTP) to generate appropriate
      destination pathnames for multiple requests.






















DeSchon & Braden                                                [Page 5]

RFC 1068                                                     August 1988


                    Figure 1 -- BFTP Model of Operation





                            ---------                        Remote
                           |  BFTP   |      (telnet)      o    User
             Local         | Network | <---------------- -|-
             User  o       | Server  |                   / \
                  -|-       ---------
                  / \  |       |
                       |       |
                       |       |
                       v       v
                      -----------  (Submit    +---+
                     | BFTP User |  request)  |---| Request
                     | Interface | ---------> |---| Queue
                      -----------             |---|
                              .               +---+
                               .              /
                                .            /
                    (foreground  .          / (try/retry
                      request--   .        /   request)
                      see 2.3)     v      v
                                   --------                 +---+
                                  |  FTC   | -------------> |   |  User
                                  | Daemon |     Notify     |   | Mailbox
                                   --------      Message    +---+
                                  /        \
                                 /   FTP    \
                                /   Control  \
                               /  Connections \
                      HOST S  v                v  HOST D
                       --------                --------
                      |  FTP   | ===========> |  FTP   |
                      | Server |  file        | Server |
                       --------    transfer    --------













DeSchon & Braden                                                [Page 6]

RFC 1068                                                     August 1988


             Figure 2 -- Server-Server File Transfer



          Server FTP            BFTP Daemon             Server FTP
            HOST S                HOST C                  HOST D
           ----------           -----------             ----------

                      <-------- Open TCP Ctrl conn
                           Open TCP Ctrl conn -------->

                      <-------- (log in)
      (login confirm.) -------->
                                     (log in) -------->
                                             <-------- (login confirm.)

                      <-------- TYPE, STRU, MODE, CWD
       (confirmations) -------->
                        TYPE, STRU, MODE, CWD -------->
                                             <-------- (confirmations)

                      <--------  PASV command
          PASV confirm -------->
                                 PORT command -------->
                                             <-------- PORT confirm

                                  RETR file   -------->
                      <--------   STOR file
                      <------------------------------ Open TCP Data conn
                      <------------------------------ Send file
                      <------------------------------ Close Data conn
                                            <-------- RETR confirm
          STOR confirm -------->

                      <-------- QUIT command
                                QUIT command -------->
       Close Ctrl conn -------->

                                            <-------- Close Ctrl conn












DeSchon & Braden                                                [Page 7]

RFC 1068                                                     August 1988


      BFTP currently utilizes the following Server-FTP commands [RFC-
      959]: USER, PASS, ACCT, PASV, PORT, RETR, STOR, STOU, CWD, NLST,
      MODE, STRU, TYPE, and QUIT.

      The FTC daemon attempts to work around FTP servers that fail to
      support certain commands.  For example, if a server does not
      support the optional command "CWD", the FTC daemon will attempt to
      construct a complete path name using the source directory name and
      the source file name.  However, it is necessary that at least one
      of the two hosts support the FTP passive (PASV) command.  While
      many FTP server implementations support do this command, some (in
      particular, the 4.2BSD FTP) do not.  The PASV command was
      officially listed as being optional in RFC-959.

   2.3 Reliable Delivery

      The reliable delivery function of BFTP is analogous to reliable
      delivery in a transport protocol like TCP.  Both depend upon
      repeated delivery attempts until success is achieved, and in both
      cases the choice of the retry interval requires some care to
      balance overhead against unresponsiveness.

      Humans are impatient, but even their impatience has a limit.  If
      the file cannot be transferred "soon", a human will turn to
      another project; typically, there is a tendency for the transfer
      to become less urgent the longer the wait.  The FTC daemon of BFTP
      therefore starts each transfer request with a very short retry
      interval -- e.g., 10 minutes -- and then doubles this interval for
      successive retries, until a maximum interval -- e.g., 4 hours --
      is reached.  This is essentially the exponential backoff algorithm
      of the Ethernet, which is also used by transport protocols such as
      TCP, although BFTP and TCP have quite different rationales for the
      algorithm.

      We must also define the meaning of reliable transmission for a
      multiple-transfer request.  For example, the set of files selected
      by wildcard characters in a pathname is not well defined; the set
      may change while the request is pending, as files are created and
      deleted.  Furthermore, it is unreasonable to regard the entire
      multiple transfer as a single atomic operation.  Suppose that
      transferring a set of files fails part way through; for an atomic
      operation, the files which had been successfully transferred would
      have to be deleted pending the next retry of the entire set.  This
      would be ridiculously inefficient and may be impossible (since the
      communication path may be broken when it is time to issue the
      deletion requests).





DeSchon & Braden                                                [Page 8]

RFC 1068                                                     August 1988


      BFTP addresses these issues in the following manner:

      *    For a multiple file operation, the FTC daemon saves the file
           name list returned by the first successful NLST command in
           the request queue entry.  This name list determines the set
           of source files for the transfer; there can be no later
           additions to the set.

      *    The FTC daemon maintains a transfer status pointer.  On each
           retry cycle, it tries to transfer only those files that have
           not already been successfully transferred.

      *    The request is complete when all the individual file
           transfers have been successful, a permanent failure has
           occured, or when the retry limit is reached.

      *    The notification message to the user lists the status of each
           of the multiple files.


   2.4 BFTP User Interface

      The purpose of BFTP is to simplify the file transfer process and
      to place the burden of reliability on the BFTP control host.  We
      have attempted to provide a "user friendly" command interface to
      BFTP, similar in flavor to the user interface of the TOPS-20
      operating system.  This interface provides extensive prompting,
      defaulting, and help facilities for every command.

      For a list of all BFTP commands, the user may enter "?<Return>" at
      the main BFTP prompt ("BFTP>").  Entering "help<Return>" and
      "explain<Return>" will provide increasing levels of explanatory
      material.  To obtain information on a particular command, "help
      <command name><Return>" may be entered.  The 'quit' or 'exit'
      command will exit from BFTP.  Command and subcommand names may be
      abbreviated to the shortest unique sequence for that context;
      alternatively, a partial name can be automatically completed by
      typing <Return>.

      The normal procedure for a BFTP user is to set up a set of
      parameters defining the desired transfer and then submit the
      request to the FTC daemon.  To give the user the maximum
      flexibility, BFTP supports three modes of submission:

      o    Background Operation

           To request a reliable background file transfer, the user will
           issue the BFTP 'submit' command to the FTC daemon.



DeSchon & Braden                                                [Page 9]

RFC 1068                                                     August 1988


      o    Foreground Verification, Background Operation

           The BFTP 'verify' command may be used to ascertain that file
           transfer parameters are valid.  It causes BFTP to connect to
           the FTP servers on both the source and the destination hosts
           (if possible), log into both, verify the FTP parameters, and
           verify that the specified source file is present.

           Once the 'verify' command has successfully completed, the
           user can issue the 'submit' command to schedule the actual
           file transfer.


      o    Foreground Operation

           The BFTP 'transfer' command will perform the specified
           third-party transfer in foreground mode.  This is illustrated
           by the dotted path bypassing the queue in Figure 1.


      The easiest way to set up the parameters is to issue the 'prompt'
      command, which will prompt the user for all of the basic
      parameters required for most transfers.  Certain unusual
      parameters must be set with the 'set' command (see Appendix B for
      details).

      When entering any parameter, the following control characters may
      be used:

      ?    will display help text for the parameter, indicating its
           meaning, the choices, and the default, and then reprompt for
           the parameter.

      <ESC> will display the default value (or the last value set) for
           this parameter.  The user can accept this default by entering
           <Return>, or else erase it with Control-W and enter a
           different value for the parameter, followed by <Return> to
           accept the entered value.

      <Control-W>
           will erase the value typed or displayed for current
           parameter.

      <Return>
           will accept the value displayed for this parameter, and
           continue to the next parameter, if any.  If the user has not
           typed a value or used <ESC> to display the default, <Return>
           will display the default and then accept it.



DeSchon & Braden                                               [Page 10]

RFC 1068                                                     August 1988


      It is important to provide a means for a user to obtain status
      information about an earlier request or even to cancel an earlier
      request.  However, these functions, especially cancellation, must
      be controlled by some user authentication.  We did not want to
      build a user authentication database with each BFTP instance or
      require login to BFTP itself, and there is no Internet-wide user
      authentication mechanism.  We adopted the following weak
      authentication mechanism as a compromise:

      *    When the 'submit' command is issued, it prompts the user for
           a character string called a "keyword", which recorded with
           the request.

      *    This keyword can be entered later as the argument to a 'find'
           command, which will display the status of all requests with
           matching keywords.

      *    Similarly, the keyword may be used to cancel the
           corresponding request.

      If two different users happen to choose the same keywords, of
      course, this scheme will not protect each other's requests from
      accidental or malicious cancellation.  However, a notification
      message will be sent at the time that a cancellation occurs.

      To make a series of similar requests, the user needs only to
      change the individual parameters that differ from the preceding
      request and then issue a new 'submit' command, for each request.
      There are commands for individually setting each of the parameters
      that 'prompt' sets -- and 'time' -- to provide a shortcut for BFTP
      experts.  A simpler but lengthier procedure is to use the 'prompt'
      command to run through the current set of parameters, reentering
      the parameters that must change and using the sequence
      <ESC><return> to retain the previous value for each of the others.
      The same procedures may be used to correct a mistake made in
      entering a particular parameter.

      The current settings of all the BFTP parameters can be displayed
      at any time with the 'status' command, while the 'clear' command
      will return all parameters to their initial values.  Finally, the
      'request' command allows the user to save the current set of
      parameters in a file or to restore the parameters from a
      previously-saved file.

      There is also a window-based BFTP user interface for use on a Sun
      Workstation, described in Appendix A.  The complete list of BFTP
      commands is presented in Appendix B.




DeSchon & Braden                                               [Page 11]

RFC 1068                                                     August 1988


3. Experience and Conclusions

   BFTP has been available to users at ISI for some months.  Users have
   reported a number of advantages of using BFTP:

   (a)  Some users prefer the prompting style of BFTP to the user
        interface of the foreground FTP they normally use.

   (b)  The BFTP "verify" command allows the user to verify that host
        names, passwords, and filenames are correct without having to
        wait for the entire transfer to take place.

   (c)  Since results are returned through the mail system, a transfer
        can occur without tying up a terminal line, a phone line, or
        even a window.


   BFTP must be able to communicate with a variety of Server-FTP
   implementations, and we have observed much variation in the commands
   supported, error handling, and the timing in these servers.  Some of
   the problems we have encountered are:

   (1)  Some systems (e.g., 4.2BSD) do not support the PASV command.

   (2)  4.2/3BSD systems return a non-standard response to the NLST
        command.  Instead of returning a list of complete path-names,
        they use an ad hoc format consisting of a directory name
        followed by a list of files.

   (3)  4.2/3BSD systems may return a "permanent negative completion
        reply" (a 5xx FTP reply code) as a result of a communications
        failure such as a broken TCP connection.  According to RFC-959,
        the appropriate response is a "transient negative completion
        reply" (a 4xx FTP reply code), which would inform the BFTP that
        the transfer should be retried.

   (4)  A number of servers return badly formatted responses.  An
        example of this is the 4.2/3BSD response to an NLST command for
        a non-existent file name: an error string which is not preceded
        by a numerical response code.


   To diagnose problems that do occur, we have found it very useful to
   have a complete record of the interchange between the FTC daemon and
   the two FTP servers.  This record is saved and is currently always
   included in the notification message mailed to the user (see Appendix
   D for an example).  As we get more experience with this program, some
   of the details of the transfer may be omitted from this log.



DeSchon & Braden                                               [Page 12]

RFC 1068                                                     August 1988


   The use of library routines shared between modules makes it
   relatively easy to implement additional user interface programs.  We
   are currently experimenting with a window version of BFTP, the
   "bftptool", which runs in the SunView environment, and is described
   in Appendix A.  Some additional interfaces that might be useful are:

   o    A command line interface for use in shell scripts and
        "Makefiles".

   o    A more general library interface which would make it easy to
        invoke BFTP from a variety of programs.

   o    Additional full-screen form based interfaces, for example a tool
        running in X-Window system environment.


   Lastly, BFTP would benefit from the resolution of the following open
   protocol issues:

   o    There currently exist no provisions for Internet-wide user
        authentication.  In the BFTP context, this means that passwords
        required for a file transfer must be present in BFTP request
        files.  The security of these passwords is subject to the
        limitations of the file system security on the BFTP control
        host.  Anonymous file transfer provides a partial solution, but
        a more general, long term solution is needed.

   o    Better mechanisms are needed to cope with the diversity of real
        file systems in the Internet.

        For example, an extension could be made to the FTP protocol to
        allow the daemon to learn the delimiter conventions of each host
        file system.  This could allow a more flexible and powerful
        multiple-file facility in BFTP.  This could include the
        automatic transfer of directory subtrees, for example.


4. References

   [RFC-959] Postel, J., and J. Reynolds, "File Transfer Protocol
             (FTP)", RFC-959, USC/Information Sciences Institute,
             October 1985.









DeSchon & Braden                                               [Page 13]

RFC 1068                                                     August 1988


Appendix A -- BFTP Implementation Structure

   BFTP has been implemented on both a Sun workstation running Sun OS
   3.4 (based on 4.2BSD) and a VAX running 4.3BSD.  The program modules
   are: the local user interface programs "bftp", the Internet server
   program "bftpd", and the FTC daemon "fts".  BFTP makes use of the
   "at" command, a UNIX batch job facility, to submit requests and
   execute the daemon.  An additional user interface program, the
   "bftptool", is available for Sun OS 3.4, and runs in the SunView
   environment.

   BFTP keeps its state in a set of control files: request files,
   command files, and message files.  These files are stored in the home
   directory specified for the environment of the process running
   "bftp".  If a user is running "bftp" directly, this will typically be
   the user's home directory.  In the case where a user has made a
   Telnet connection to the well-known port 152 on a BFTP service host,
   "bftp" is started by "bftpd" (or "inetd", indirectly).  As a result,
   the control files will be owned by the user-id under which "inetd"
   was started, normally "root", and stored in the top level directory
   "/".  Note, however, that under BFTP all user files are written by
   the FTP servers, which are presumed to enforce the operating systems'
   access control conventions.  Hence, BFTP does not constitute a system
   integrity exposure.

   A.1  User Interface Program

      The BFTP user interface program "bftp" may be run directly via a
      UNIX shell.  Once the program has been started, the prompt "BFTP>"
      will appear and commands may be entered.  These commands are
      described in detail in Appendix B.

   A.2  Tool-Style User Interface Program

      The BFTP user interface program "bftptool" may be started from a
      shell window in the SunView environment on a Sun workstation.  The
      BFTP commands may be selected via the left mouse button.  The
      various file transfer parameters appear in a form-style interface;
      defaults and multiple-choice style parameter values can be filled
      in via menus.  An advantage of this form-style interface program
      is that it is possible to view all of the file transfer parameters
      simultaneously, providing the user with a sense for which
      parameter values might be mutually exclusive.

      Help information can be displayed in a text subwindow by
      positioning the on-screen mouse pointer over a command or a
      parameter, and clicking the center mouse button.  (No standard
      mechanism for displaying help information is currently included in



DeSchon & Braden                                               [Page 14]

RFC 1068                                                     August 1988


      the SunView package.)

      The commands used in the "bftptool" are for the most part very
      similar to the commands described in Appendix B.  Request
      submittal and the execution of the FTC daemon are identical for
      the "bftp" and the "bftptool" interface programs.

   A.3  Internet Server

      The Internet server program "bftpd" can be invoked by opening a
      Telnet connection to a well-known port, and does not require
      login.  The "bftpd" program runs under "inetd", the standard
      BSD4.x well-known port dispatcher.  When a SYN arrives for the
      BFTP well-known port, "bftpd" opens the TCP connection and
      performs Telnet negotiations.  It then passes control to the user
      interface "bftp" which allows the user to enter file transfer
      requests.

   A.4  BFTP Server Daemon

      The BFTP file transfer control daemon program is named "fts" (for
      "File Transfer Service").  This module contains code to actually
      cause a single file transfer operation using the FTP server-server
      model as shown in Figures 1 and 2.  It is invoked with the command
      "fts <request-file>".  The <request-file> contains the necessary
      parameters for the file transfer, in ASCII format, separated by
      linefeeds.  Such a request file may be created by the user
      interface program, "bftp".

      As a byproduct of the development of BFTP, "fts" represents a
      server-server FTP driver that can be run independent of the "bftp"
      program.  Parameters used in the file transfer are read from a
      request file, which is created and accessed via library routines
      which can be shared between modules.  This could be used to
      perform FTP's under program control.
















DeSchon & Braden                                               [Page 15]

RFC 1068                                                     August 1988


Appendix B: BFTP Command Summary

   B.1 Special Editing Characters

      In the "bftp" program, the special editing characters for command
      words, subcommands, and parameter fields are as follows:

        <return>    Accept current command/field.
        <escape>    Complete current command/field, or display default.
        <space>     Complete and delimit current command.
        <delete>    Erase last character.
        control-L   Refresh screen.
        control-R   Refresh line.
        control-U   Erase line.
        control-W   Erase current token.
        ?           List legal options.

   B.2 BFTP Commands

      The remainder of Appendix B consists of a list of the BFTP
      commands.  Each command should be followed by a carriage-return.
      In the description of the syntax for each command, square brackets
      "[]" are used to indicate a ssubcommand, or a list of possible
      subcommands, which are separated by the "|" character.  Angle
      brackets "<>" are used to indicate a description of a parameter
      where the choices would be too numerous to list, for example
      "<host name/number>".

   B.2.1 Clear Command


      Return all parameters to their default values.

            clear

   B.2.2 Destination Commands

      Set the destination directory.

            ddir <directory name>

      Set the destination file name.

            dfile <file name>

      Set the destination host, user, and password.

            dhost <host name/number> <login> <password>



DeSchon & Braden                                               [Page 16]

RFC 1068                                                     August 1988


   B.2.3 Explain Command

      Display a short explanation of how to use BFTP.

            explain

   B.2.4 Find Command

      Find and display a previous request.

            find

      BFTP will prompt for the request id, which is printed when the
      request is first submitted.  An example of a request id is
      "bftp583101774".  BFTP also prompts for the request keyword, which
      was determined by the user when the request was first submitted.
      If no keyword was specified, a <CR> should be typed.  If no
      request id is entered, BFTP will display all requests which
      contain a matching keyword.

            RequestID (optional): <bftp-request-id>
            RequestKeyword: <keyword>

      After BFTP has displayed a summary of a matching request, it asks
      whether the request is to be changed, or canceled.

            Do you wish to change this request? [yes | no]
            Do you wish to cancel this request? [yes | no]

      If the user indicates that the request is to be changed, BFTP will
      read in the parameters and cancel the existing request.  At this
      point the user may make any desired changes and use the "submit"
      command to requeue the request.  At this point a new request id
      will be assigned and displayed.

















DeSchon & Braden                                               [Page 17]

RFC 1068                                                     August 1988


      Although this may happen extremely rarely, if at all, it is
      possible that a system crash (or the interruption of the BFTP
      program) at a particularly inopportune moment may leave a request
      which is not queued.  When the "find" command locates such a
      request, it displays the warning:

            Your request is NOT currently queued.

      If this happens, the request may be read in and resubmitted using
      the following procedure:

            Your request is NOT currently queued.
            Do you wish to change this request? yes

              (BFTP displays the parameters that have been read in.)

            Previous request canceled.
            Use the 'submit' command to submit a new request.

   B.2.5 Help Command

      Print local help information.

            help
            help <command>

   B.2.6 Quit Command

      Clear parameters and exit the BFTP program.

            quit

   B.2.7 Prompt Command

      Prompt for commonly-used parameters.

            prompt














DeSchon & Braden                                               [Page 18]

RFC 1068                                                     August 1988


      The following are the parameters that BFTP prompts for:

            copy/move/delete: [copy | move | delete]
            ascii/ebcdic/image/local:
                  [ascii|ebcdic] [nonprint|telnet|carriage-control]
      or
                  [image]
      or
                  [local] <byte size>
      (see "set type" for additional information)

            Source --
                Host: <host name/number>
                User: <login>
                Password: <password>
                Dir: <directory including a delimiter, e.g., "/" or ">">
                     (either an absolute path, or relative to the login)
                File: <file name>

            Destination --
                Host: <host name/number>
                User: <login>
                Password: <password>
                Dir: <directory>
                File: <file name>

      Once the prompting has been completed, the current values of all
      parameters will be displayed.  Parameters not mentioned in the
      prompting will be initialized with default values, and may be
      changed via the "set" commands.





















DeSchon & Braden                                               [Page 19]

RFC 1068                                                     August 1988


   B.2.8 Request Commands

      The request commands enable the user to save a set of BFTP
      parameters in a "request-file" for future use.  Subcommands are
      provided to to list all available request-files, or to read,
      write, or delete a request-file.  All request-files are stored in
      the user's home directory.  Therefore, this facility is not
      available when the user is accessing BFTP by telneting to port
      152.

      Delete request file "bftp-save.name".

            request delete <name>

      List all bftp-save files.

            request list

      Read a request file in as the current request.

            request load <name>

      Save the current request in a file named "bftp-save.name".

            request store <name>

   B.2.9 Set Commands

      The "set" commands have complex subcommand structures and are used
      to set many of the less commonly used FTP parameters. The
      subcommands of "set" are as follows:

      Set the account for the source/destination login.

            set account [source | destination] <account string>

      Set to true to append to destination file.

            set append [true | false]

      The source file will be copied to the destination file name.

            set copy

      The source file will be deleted after the file has been moved or
      copied.

            set delete



DeSchon & Braden                                               [Page 20]

RFC 1068                                                     August 1988


      Set the mailbox to which the results will be returned.  The
      mailbox should be in standard internet format, for example:
      "deschon@isi.edu".

            set mailbox <mailbox string>

      Set the FTP transfer mode.

            set mode [stream | block | compress]

      The source file will be deleted after it has been copied.

            set move

      Set to true to transfer multiple files.

            set multiple [true | false]

      Set the port for the source/destination FTP connection.

            set port [source | destination] <port number>

      Set the FTP structure.

            set structure [file | record | page]

      Set the FTP type and format / byte size parameters.  Note that a
      normal text file is usually "ascii", and a "binary" file is often
      the same as an "image" file.

            set type [ascii|ebcdic] [nonprint|telnet|carriage-control]
      or
            set type [image]
      or
            set type [local] <byte size>

      Set to true if the STOU command is to be used.  If the STOU
      command is supported by the destination host, the file will be
      stored into a file having a unique file name.

            set unique [true | false]

      Set to true to display full FTP conversations for "verify" and
      "transfer" commands.

            set verbose [true | false]





DeSchon & Braden                                               [Page 21]

RFC 1068                                                     August 1988


   B.2.10 Source Commands

      Set the source directory.

            sdir <directory name>

      Set the source file name.

            sfile <file name>

      Set the source host, user, and password.

            shost <host name/number> <login> <password>

   B.2.11 Status Command

      Display the current parameter values.

            status

   B.2.12 Submit Command

      Submit the current request for background FTP.

            submit

      BFTP prompts for the following information:

            StartTime: <date and/or time>
            ReturnMailbox: <internet mailbox>
            RequestKeyword: <made-up keyword>

   B.2.13 Time Command

      Set the start time, the starting retry interval, and the maximum
      number of tries.

            time <date and/or time> <minutes between tries>
                 <maximum number of tries>

   B.2.14 Transfer Command

      Perform the current request in the foreground.

            transfer






DeSchon & Braden                                               [Page 22]

RFC 1068                                                     August 1988


   B.2.15 Verify Command

      Make the connections now to check parameters.

            verify














































DeSchon & Braden                                               [Page 23]

RFC 1068                                                     August 1988


Appendix C: Example BFTP User Script

   deschon.isi.edu 1% telnet hobgoblin.isi.edu 152
   Trying 128.9.0.42 ...
   Connected to hobgoblin.isi.edu.
   Escape character is '^]'.

   BFTP Server (hobgoblin.isi.edu)

   Background File Transfer: For help, type '?', 'help', or 'explain'.

   BFTP> prompt

   Copy/Move/Delete: copy

   Source --
       Host: deschon.isi.edu
       User: deschon
       Password:
       Dir: ./
       File: foo*

   Destination --
       Host: venera.isi.edu
       User: deschon
       Password:
       Dir: ./temp/
       File: foo*

   StartTime: Tue Oct  6 10:14:43 1987 (interval) 60 (tries) 5
   ReturnMailbox: deschon@isi.edu
   RequestPassword:

   BFTP> set multiple true
   BFTP> status
       Request type: COPY

       Source --
           Host: 'deschon.isi.edu'
           User: 'deschon'
           Pass: SET
           Acct: ''
           Dir: './'
           File: 'foo*'
           Port: 21

       Destination --
           Host: 'venera.isi.edu'



DeSchon & Braden                                               [Page 24]

RFC 1068                                                     August 1988


           User: 'deschon'
           Pass: SET
           Acct: ''
           Dir: './temp/'
           File:'foo*'
           Port: 21

       Structure: file, Mode: stream, Type: ascii, Format: nonprint
       Multiple matching: TRUE
       Return mailbox: 'deschon@isi.edu', Password: SET
       Remaining tries: 5, Retry interval: 60 minutes

       Start after Tue Oct  6 10:14:43 1987.

   BFTP> submit
   Checking parameters...

   Request bftp560538880 submitted to run at 10:14 Oct 6.

   BFTP> quit
   bye
   Connection closed by foreign host.
   deschon.isi.edu 2%




























DeSchon & Braden                                               [Page 25]

RFC 1068                                                     August 1988


Appendix D: Sample BFTP Notification Message

   Received-Date: Tue, 6 Oct 87 10:15:52 PDT
   Date: Tue, 6 Oct 87 10:15:47 PDT
   From: root (Operator)
   Posted-Date: Tue, 6 Oct 87 10:15:47 PDT
   To: deschon
   Subject: BFTP Results: bftp560538880

   Request bftp560538880 submitted to run at 10:14 Oct 6.

     Tue Oct  6 10:15:22 1987: starting...

       Request type: COPY
       Source: deschon.isi.edu-deschon-XXX--21-./-foo*
       Destination: venera.isi.edu-deschon-XXX--21-./temp/-
       Stru: F, Mode: S, Type: A N, Creation: STOR
       Multiple matching: TRUE
       Return mailbox: 'deschon@isi.edu', Password: SET
       Remaining tries: 5, Retry interval: 60 minutes

   Connect to: deschon.isi.edu, 21
   deschon.isi.edu ==> 220 deschon.isi.edu FTP server (Version 4.7
                           Sun Sep 14 12:44:57 PDT 1986) ready.
   Connect to: venera.isi.edu, 21
   venera.isi.edu ==> 220 venera.isi.edu FTP server (Version 4.107
                           Thu Mar 19 20:54:37 PST 1987) ready.
   deschon.isi.edu <== USER deschon
   deschon.isi.edu ==> 331 Password required for deschon.
   deschon.isi.edu <== PASS XXX
   deschon.isi.edu ==> 230 User deschon logged in.
   venera.isi.edu <== USER deschon
   venera.isi.edu ==> 331 Password required for deschon.
   venera.isi.edu <== PASS XXX
   venera.isi.edu ==> 230 User deschon logged in.
   deschon.isi.edu <== CWD ./
   deschon.isi.edu ==> 200 CWD command okay.
   venera.isi.edu <== CWD ./temp/
   venera.isi.edu ==> 250 CWD command successful.
   deschon.isi.edu <== PORT 128,9,1,56,4,106
   deschon.isi.edu ==> 200 PORT command okay.
   deschon.isi.edu <== NLST foo*
   deschon.isi.edu ==> 150 Opening data connection for /bin/ls
                           (128.9.1.56,1130) (0 bytes).
   deschon.isi.edu ==> 226 Transfer complete.
   deschon.isi.edu <== PASV
   deschon.isi.edu ==> 502 PASV command not implemented.
   venera.isi.edu <== PASV



DeSchon & Braden                                               [Page 26]

RFC 1068                                                     August 1988


   venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,200)
   deschon.isi.edu <== PORT 128,9,0,32,6,200
   deschon.isi.edu ==> 200 PORT command okay.
   deschon.isi.edu <== RETR foo
   venera.isi.edu <== STOR foo
   deschon.isi.edu ==> 150 Opening data connection for foo
                           (128.9.0.32,1736) (0 bytes).
   deschon.isi.edu ==> 226 Transfer complete.
   venera.isi.edu ==> 150 Openning data connection for foo
                           (128.9.1.56,20).
   venera.isi.edu ==> 226 Transfer complete.
   venera.isi.edu <== PASV
   venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,201)
   deschon.isi.edu <== PORT 128,9,0,32,6,201
   deschon.isi.edu ==> 200 PORT command okay.
   deschon.isi.edu <== RETR foo1
   venera.isi.edu <== STOR foo1
   deschon.isi.edu ==> 150 Opening data connection for foo1
                           (128.9.0.32,1737) (4 bytes).
   deschon.isi.edu ==> 226 Transfer complete.
   venera.isi.edu ==> 150 Openning data connection for foo1
                           (128.9.1.56,20).
   venera.isi.edu ==> 226 Transfer complete.
   deschon.isi.edu <== QUIT
   venera.isi.edu <== QUIT

     Tue Oct  6 10:15:39 1987: completed successfully.
























DeSchon & Braden                                               [Page 27]