Summary

  • BBN's December 1980 RFC 775 added four experimental FTP commands for creating, removing and navigating directories during remote site maintenance.
  • Its sharpest rule was that a successful create operation returned the server's usable absolute pathname. On TOPS-20, the short name supplied to create a directory could fail when used to enter it.

XMKD MYDIR succeeded. XCWD MYDIR failed. If a computer had a sense of humor, this was a fairly dry one. RFC 775 placed that sequence at the center of a practical problem: how do you copy a tree of directories between machines that disagree about what a directory name looks like?

The memo came out of BBN's Remote Site Maintenance project. BBN installed and maintained software on several DEC PDP-11s running UNIX. The UNIX tree made directories easy to manipulate, so the engineers expanded their FTP servers to create and remove them. But the ARPANET also held TOPS-20 and Multics hosts with tree-like storage. A transfer program could not assume that a path copied from one machine would be meaningful to the next.

The four additions were compact. XMKD child made a directory; XRMD child removed one; XPWD reported the working directory; XCUP climbed to its parent. The parent command mattered because different systems named the parent differently. A transfer program needed an action it could request without knowing every host's local punctuation. The memo treated XCUP as a special case of the existing XCWD change-directory command.

Creation exposed the harder mismatch. A client might send XMKD MYDIR while connected to <DFRANKLIN> on a TOPS-20 server. The server could create the child as <DFRANKLIN.MYDIR>. Trying to enter MYDIR alone could then fail. The command's input had described an operation, but it was not necessarily a reusable address for the result. The server was the party that knew its file system. The client had to listen to the reply.

RFC 775 therefore proposed that success return a 257 line with the created directory's full name in double quotes. Its UNIX example used 257 "/usr/dm/child" directory created. The TOPS-20 case used the host's own bracketed, dotted form. Even a quotation mark inside a name had a rule: double it inside the quoted reply. That small parsing instruction prevented a directory named foo"bar from breaking the client that read the server's answer.

This was an early version of a familiar engineering lesson: do not invent a resource's identity from the request you sent. Use the identity the authority returned. The authority here was prosaic—a remote FTP server and its local file system—but the failure was concrete. A program copying subtrees needed to create a child, retain the returned absolute path, enter it, fill it, and navigate back. Guessing the path from a UNIX habit could leave the program standing outside a directory it had successfully made.

The proposal also specified what a failed create should look like. BBN treated an already existing child as an error and showed a 521 response that took no action. The memo matched the other commands' replies to related file or directory operations. It even printed two sets of code numbers: its implemented older FTP replies and proposed counterparts for the newer RFC 765 protocol. The 257 answer was new in the older set; the proposed newer counterpart was 251. That distinction matters when reading a protocol during a transition, rather than imagining one clean version sweeping the network overnight.

The prior specification had declared an ambitious aim: FTP should shield users from differences among host file systems. It also acknowledged that FTP did not yet define a standard pathname convention. RFC 775 attacked that gap from the operating end. It did not need all hosts to rename their directories. It needed the server to state, in a parseable reply, what it had actually created.

Five years later, RFC 959 listed MKD, RMD, PWD and CDUP among its new optional commands. The experimental X prefixes had gone. The underlying problem remained recognizable: remote file work required more than moving file bytes. Someone had to keep track of where the files lived, and the machine holding the directory got the last word on its name.