Summary

  • In 1975, James E. White’s RFC 707 proposed a common Procedure Call Protocol and a run-time environment to reduce the repeated command-and-reply work of application-specific ARPANET protocols.
  • The paper reports a prototype for a PDP-10 running TENEX, then warns that remote calls still require interprocess messages, cost more than local calls and cannot represent every useful form of communication.

The extra conversation inside a command

A file rename could be expressed as a single intention and still require a small conversation on the wire. The 1973 FTP specification says a client sends RENAME FROM and then RENAME TO. Each step belongs to a command-and-response exchange; the application has to manage the dialogue as well as the operation it wants. Remote Job Entry had its own stream of commands and replies, including replies that reported progress while work continued.

RFC 707, A High-Level Framework for Network-Based Resource Sharing, treated this repetition as a design problem. Written by James E. White at SRI’s Augmentation Research Center, it argued that application protocols were repeatedly rebuilding a discipline for requests, parameters, results and replies. The proposal was not to eliminate those messages. It was to give programmers a more uniform way to describe the operation above them.

A procedure call with a network beneath it

The proposed Procedure Call Protocol (PCP) paired CALL and RETURN messages, associated exchanges with transaction identifiers, and provided for arguments, results and more than one outstanding request. A run-time environment at each installation would marshal the call, communicate with the remote side and deliver the result to the caller. RFC 707 also allowed for blocking and nonblocking calls and for a remote server to call back to its client.

That abstraction changed the programming surface. Instead of spelling every service as its own command grammar, an application could describe a procedure and its parameters. But the division of responsibility remained visible: PCP handled a call-shaped exchange, while lower-level interprocess communication stayed available for interactions that did not fit that shape.

What one TENEX prototype proves

The RFC says ARC began its research in July 1974, made three design iterations over 12 months, and designed, documented and implemented a prototype run-time environment for a PDP-10 running TENEX. It reports that the TENEX environment implemented the specification and provided a superset of the described capabilities. This is unusually concrete evidence for a proposal: a named system and a reported implementation, not only a diagram.

Its reach is equally specific. The record establishes a prototype in one operating environment. It does not provide an installation census, cross-vendor interoperability results, an adoption count or evidence that every ARPANET host could use PCP. The RFC Editor now classifies RFC 707 as Legacy with status UNKNOWN; the Datatracker notes that it predates the formal source record and has no standing in today’s IETF standards process. Neither label tells us how widely the prototype was used in 1975.

Distance survives the abstraction

RFC 707’s own warning is the most useful part of its design argument: local procedure calls are cheap; remote ones are not. A remote call still uses IPC messages. Programmers need discretion, distributed programs may continue asynchronously, and some communication patterns are not naturally procedures. For those cases, the underlying IPC mechanism must remain accessible.

That caveat prevents a common historical overstatement. RFC 707 did not claim that a network could be made to behave like a local machine, and the available sources do not establish that it became the origin of later RPC systems. It documents a narrower experiment: move repetitive request-and-reply mechanics into a shared run time, test that idea on TENEX, and leave the costs and limits of communication in view.

Sources

  • James E. White, RFC 707, A High-Level Framework for Network-Based Resource Sharing.
  • RFC Editor, RFC 707 record; IETF Datatracker, RFC 707 status.
  • RFC 542, FTP command and rename sequence; RFC 360, Remote Job Entry command/reply dialogue.
  • RFC 592 is earlier SRI resource-sharing context; Heng Lu’s Note 65 is a later editorial lens only, not evidence of 1970s intent or adoption.