The rest of this RFC discusses what we feel to be some of the shortcomings of a procedure call protocol. We feel that a request and reply protocol along with suitably manipulated communication paths between processes forms a model better suited to the situation in which the network places us. In a network environment one has autonomous computing entities which have agreed on their cooperation, rather than a master process forcing execution of a certain body of code to fulfill its computing needs. Procedure calling is most often a very primitive operation whose implementation often requires only a single machine instruction. In addition, it is usually true that procedure calling is usually not within the domain of the operating system.
Message sending is always an interprocess action, and requires system intervention always.
There is not as substantial a difference between the IPC of local processes and the IPC of remote processes, as between local and remote procedure calling. PCP is suggestive of a model in which processes exist that span machine boundaries to provide inter-machine subroutine calling. Yet the PCP documentation has not advocated the notion of a process that spans machine boundaries, and rightfully so since such a creation would cause innumerable problems. Since procedure calling is more suitable as an intra-process notion, it seems to be a better idea to take the interprocess communication framework and extend it to have a uniform interpretation locally and remotely, rather than to extend the procedure calling model. It is also our contention that a model which relies on procedure calling for its basis does not take into account the special nature of the network environment, and that such an environment can be more suitably handled in a message passing model.