Summary

  • RFC 1068 placed FTP parameters in a persistent control-host queue, then let a daemon schedule and retry ordinary server-to-server transfers after the user had left. Submission made the instruction durable; it did not move the file.
  • For multiple files, BFTP froze the first successful name list, remembered each successful member and retried only the rest. A request could be called complete after total success, permanent failure or retry exhaustion, so the per-file report—not the word “complete”—carried the outcome.

The important object in RFC 1068 is a request that remains after its author has gone away. Before that experiment, the memo says, Internet file transfer was normally foreground work. A person started FTP, watched it and reissued the command if the attempt failed. That was tolerable when hosts and paths were lightly loaded and generally available. Congestion, delay and outages made the human presence part of the failure model.

BFTP moved that presence into stored state. Its user interface collected the desired operation. A file transfer control daemon—FTC—carried it out later. The memo introduced no new wire protocol. It composed a queue, a scheduler, ordinary FTP control conversations and a notification channel into a service whose instruction could survive the interactive session.

Three hosts could hold three different roles

The source host, destination host and BFTP control host did not have to be the same machine. A user supplied the two host names, login names and passwords, source and destination file names, and optional choices about copying, moving, deleting, replacing, appending or creating a unique file. FTP type, mode and structure could be selected. A wildcard could name several files. A start time could defer the first attempt.

Finally, the user supplied a mailbox and issued submit. At that point the interface could exit. What existed was a queue entry: parameters, schedule, notification address and later progress. The source file had not thereby reached the destination. The distinction matters because the attractive phrase “background transfer” combines an instruction with an outcome that still depended on two remote servers and a path.

The user could also run verify. BFTP would try to reach both FTP servers, log in, check parameters and confirm that the named source existed. If a remote host was down, some checks were impossible. Even a successful verification preceded a separate submit and a later attempt. It proved that selected facts were true during the check; it did not reserve future reachability, credentials, destination state or delivery.

The controller directed bytes it did not carry

BFTP used the third-party, or server-server, model already defined by RFC 959. The FTC daemon opened one control connection to the source FTP server and another to the destination. It used PASV on one side, supplied that endpoint through PORT to the other, then paired RETR and STOR. The data connection ran between the two FTP servers. The control host received replies and made decisions while the file bytes bypassed it.

That topology separates three kinds of evidence. The queue showed what the controller intended. The two control channels showed which commands the servers accepted or rejected. The data connection carried the file. RFC 959 required the control connections to remain open during transfer and instructed the controller to wait for terminal 226 or 250 replies before issuing another transfer command. A connected socket, a preliminary reply or a closed data path was therefore not enough by itself to settle the file result.

BFTP needed at least one server to implement PASV. It also needed both implementations to agree on types, modes, path names, reply syntax and failure classes. The paper reports missing PASV, irregular NLST output, malformed replies and servers that returned permanent 5xx results for broken connections that should have appeared as transient 4xx. A retry engine can be no more accurate than the failure vocabulary it receives.

Reliability lived above one FTP session

For a temporary failure, the daemon logged the event and tried again after a timeout. RFC 1068 gives an illustrative schedule: start around ten minutes, double successive intervals and stop increasing at about four hours. Those figures described one implementation, not constants assigned to the Internet.

This was reliability above the FTP session. The queue remembered the desired operation across separate control and data connections. It also imposed an end: success, a permanent failure or a configured retry limit. The daemon then sent mail. Notification meant that the controller had reached a terminal workflow state. Whether that state was good or bad remained in the report.

The distinction between RFC 959's 4yz and 5yz classes was therefore operational. A 4yz answer said the requested action had not occurred but could be tried again without changing the request. A 5yz answer discouraged the exact repetition. Misclassifying a broken connection as permanent did not merely choose the wrong label; it changed whether the daemon would ever make another attempt.

A directory could change while the request waited

Wildcards forced BFTP to say which files belonged to a durable job. If the source directory kept changing, repeating NLST on every retry could silently add files that were absent at submission or remove files that the user expected. BFTP therefore saved the list returned by the first successful NLST. That list became the request's membership boundary. Later arrivals were outside it.

The transfer was deliberately non-atomic. If four files succeeded and the fifth failed, BFTP did not delete the four destination copies so that the entire set could begin again. A status pointer remembered which members had succeeded, and later cycles attempted only the incomplete ones. Persistence prevented needless repetition, but it also meant the request could contain a mixed history.

RFC 1068 names the request complete in three cases: every individual transfer succeeded, a permanent failure occurred, or the retry limit was reached. Completion thus meant that the daemon had stopped scheduling work. It did not mean that every destination copy existed. The notification listed the status of each file because only that ledger could distinguish all-success from partial or total failure.

Status and cancellation rested on a weak keyword

A user could return, provide a keyword stored with the request, find matching jobs and cancel one. The authors explicitly called this weak authentication. If two users selected the same keyword, one could inspect or cancel the other's request. A cancellation generated mail, but notification after the act did not create prior authority.

This weakness is part of the historical control surface, not an invitation to judge it by an authentication system the memo did not have. It tells us that durable work creates durable powers: inspect, retry, cancel, delete a source after copying, overwrite a destination and decide when failure is final. Each power needs an owner even when the transfer protocol remains unchanged.

Later, RFC 2577 documented how proxy FTP's PORT authority could be abused to direct a server toward another service—the bounce attack—and discussed restrictions that sacrificed proxy capability. That later warning does not establish a BFTP incident. It does show why “the controller only arranged the connection” cannot be treated as “the controller had harmless authority.”

Sources and limits

RFC 1068 records an implementation used at ISI for some months and reports local experience. It does not establish broad adoption or a direct lineage to modern job queues, cloud transfers or workflow engines. RFC 959 supplies the FTP control/data split and terminal reply semantics. RFC 2577 supplies a later security boundary for third-party targeting. None proves a named transfer, present deployment, credential safety or successful application outcome.

The durable lesson is narrower. Making intent persistent can improve reliability, but it creates a second system whose records must not be mistaken for the thing they command. The queue can say try. Only the per-file evidence can establish the outcome.