RFC 114 is the genesis document of file transfer on the internet — written in April 1971, more than a decade before TCP/IP went live on the ARPANET. Every ftp command anyone has ever typed traces its lineage back to this 19-page memo from a graduate student at MIT.

The problem. By 1971 the ARPANET had a handful of sites running heterogeneous mainframes — Multics, TENEX, the IBM 360, the SDS 940 — each with its own filesystem, character set, record structure, and login model. Researchers wanted to ship files between them, but every pair of hosts required an ad-hoc convention. Abhay Bhushan, working under J.C.R. Licklider at MIT, set out to define a single protocol so that "a person, or a program operating on his behalf, can use the network to deal with file systems at remote hosts."

Key design decisions that still shape FTP today.

• Two connections, not one. Bhushan separated a persistent control link (for commands and responses) from one or more data links (for the bytes of the file). That bifurcation — odd by modern standards and the reason FTP is famously NAT-hostile — was deliberate: it let the user keep typing commands while a long transfer ran, and let third-party transfers happen between two remote hosts without bouncing through the client.
• User-level protocol over NCP. There was no TCP yet. RFC 114 runs on top of the Network Control Program using ARPANET socket numbers (control on socket 3, data negotiated dynamically). The text actually defines sockets in terms of the host's 32-bit AEN — a reminder of how much plumbing we now take for granted.
• Typed data. The protocol introduced data types (ASCII, binary, EBCDIC) and structures (file, record). This survived almost verbatim into RFC 959 and is why your FTP client still has an ascii/binary toggle that, in 2026, nobody understands.
• Human-readable commands. Bhushan chose ASCII command verbs like RETRIEVE, STORE, APPEND, DELETE, RENAME. The choice — controversial at the time, since binary opcodes were faster — set the precedent for SMTP, HTTP, IMAP, and the entire family of text-based internet protocols.
• Third-party transfer. A user at host A could tell host B to send a file directly to host C. This "FXP" capability still exists in RFC 959 and was a security nightmare in the 1990s (the "FTP bounce attack").

Interesting history. Bhushan presented this work at the 1971 Spring Joint Computer Conference. RFC 114 was revised in RFC 141, then thoroughly rewritten as RFC 172 (1971), RFC 354 (1972), RFC 542 (1973), and finally RFC 765 (1980) when it was ported to TCP. RFC 959 in 1985 is the version most engineers know, but its structure — control channel, data channel, ASCII commands, three-digit reply codes — is recognizably the 1971 design. Bhushan also wrote the first Telnet spec and went on to a career at Xerox PARC.

Why it still matters. Aside from FTP itself (which refuses to die — anonymous FTP mirrors still serve Debian and the kernel sources), RFC 114 established the shape of an application protocol: a stateful conversation in human-readable ASCII over a reliable byte stream, with a separate data path for bulk transfer. SMTP (1982), NNTP (1986), HTTP (1991), and IMAP (1988) all inherited that template. Even today, when you debug an HTTP/1.1 connection with telnet host 80, you are using a design pattern Bhushan picked in 1971 because punching commands by hand made the protocol easier to learn.