Summary

  • Early Internet designers were trying to avoid a tangle of separate transfer protocols. RFC 114 tested how much a file protocol might do, including execute.
  • RFC 171/172 drew a different boundary: applications could share a transfer layer, while FTP had no standard procedure for remote execution.

In 1971, network designers faced a standardization problem: should each application devise its own way to move data, or could several share one transfer protocol while defining their own commands? RFC 114 makes the stakes visible in a single verb. Its list runs from retrieve and rename to execute—a request for another computer to do work. Within months, RFC 171 proposed a common transfer protocol for several applications; RFC 172 put FTP on top of it and left remote execution without a standard procedure. The argument is about where shared infrastructure ends and application behavior begins, a design question that still appears in modern services.

In RFC 114, a file could contain instructions, data, or both. That is why execute appeared beside retrieval and storage. It was a limited transaction, not a general remote shell. The heading is dated 16 April 1971; the RFC Editor catalogue lists 1 April. The proposal describes cooperating processes using another host’s file system through transactions. Its operation list ranged from identify and retrieve to store, append, rename, delete, open, close and lookup. It also included execute.

That request was not a general remote shell. RFC 114 describes sending input, running a program or subroutine on the serving host, then returning output. It also narrows the promise: the using process was expected to know the conventions for arguments and responses. The protocol sketched a controlled exchange around a program file, not an all-purpose command line or a security model.

The proposal was tied to a concrete but bounded setting. RFC 114 says its protocol was developed for immediate implementation on two MIT hosts, GE 645/Multics and PDP-10/DM/CG-ITS, with a possible Harvard host. An interim version with limited capabilities was in debugging. That is evidence of a specific implementation effort; it does not show that every listed transaction worked or that the protocol spread across the network.

The subsequent design documents clarify the boundary. RFC 171, dated June 1971, proposed a common Data Transfer Protocol for several applications, including file transfer, remote job entry, mail, graphics and remote program execution. Its argument was architectural: separating transfer from application functions could make implementations more flexible, reduce complexity and avoid proliferating protocols.

RFC 172, the companion File Transfer Protocol, used that shared DTP for moving data and defined file operations as its application. It allowed hosts to implement subsets of commands. It also said FTP could be extended for remote program execution, but suggested no standard procedure for doing so. The possibility remained visible while the standard FTP procedure did not absorb it.

RFC 141’s contemporaneous comments make the practical questions concrete: local file access, command subsets, and the possibility that executing a job could involve a long wait. Read alongside RFC 172’s permission to implement only some commands, they show how much an application protocol could leave to each host.

The design bargain in RFC 171 was economy: one reusable transfer protocol could serve several applications and reduce protocol proliferation. RFC 172 shows the other side of that bargain. DTP could move the data, while FTP command subsets and application-specific procedures still varied by host. RFC 114 records a limited implementation effort; these documents do not establish how widely its execute transaction was used.

That boundary is the story: by June, remote execution remained imaginable, but FTP had no standard procedure for it.

Sources