Résumé

  • James E. White proposait dans la RFC 707 un protocole d’appel de procédure commun et un environnement d’exécution afin de réduire les dialogues commande-réponse répétés dans les protocoles applicatifs de l’ARPANET.
  • Le texte rapporte un prototype pour un PDP-10 sous TENEX, mais précise que les appels distants exigent toujours des messages IPC, coûtent plus cher que les appels locaux et ne conviennent pas à toutes les communications.

Une intention simple, plusieurs échanges

Renommer un fichier semble être une seule opération. Dans la spécification FTP de 1973, le client doit pourtant envoyer RENAME FROM puis RENAME TO. Le protocole organise ainsi une succession de commandes et de réponses autour de l’action attendue. Le Remote Job Entry avait lui aussi son flux de commandes et de réponses, avec des indications de progression lorsque le travail continuait. Chaque application devait porter à la fois sa logique métier et sa propre grammaire de dialogue.

La RFC 707, A High-Level Framework for Network-Based Resource Sharing, identifie cette duplication. James E. White, du centre de recherche Augmentation de Stanford Research Institute (SRI), propose de placer une partie de cette mécanique dans un protocole d’appel indépendant des applications. L’objectif est d’exprimer une opération comme une procédure et ses paramètres, plutôt que de réinventer chaque fois une séquence de commandes.

Le protocole ne remplace pas le réseau

Le Procedure Call Protocol (PCP) décrit des messages CALL et RETURN, des identifiants de transaction, des arguments et des résultats, avec la possibilité de laisser plusieurs requêtes en cours. Un environnement d’exécution local à chaque installation devait préparer l’appel, échanger avec l’autre extrémité puis remettre le résultat au programme. Le modèle envisage des appels bloquants ou non bloquants, ainsi que des rappels du serveur vers le client.

Le changement porte donc sur la surface de programmation. Le run-time uniformise l’enveloppe ; il ne supprime pas les messages qu’elle transporte. White maintient l’IPC de plus bas niveau accessible, car un flux asynchrone ou une autre interaction utile ne se laisse pas toujours réduire à un appel de procédure.

Un prototype, pas un déploiement général

La RFC indique que les travaux du centre ont commencé en juillet 1974, qu’ils ont traversé trois itérations en douze mois et qu’un prototype d’environnement d’exécution a été conçu, documenté et implémenté pour un PDP-10 sous TENEX. Le texte affirme que cette version de TENEX implémentait la spécification et offrait un sur-ensemble des capacités décrites.

Cette déclaration fournit un ancrage matériel : un système nommé et une implémentation rapportée par le projet. Elle ne démontre pas l’interopérabilité entre matériels différents, le nombre d’installations, ni une adoption à l’échelle de l’ARPANET. La RFC est aujourd’hui classée Legacy avec un statut UNKNOWN par l’éditeur des RFC ; le Datatracker précise qu’elle précède l’enregistrement formel des sources et n’a pas de statut formel dans le processus IETF actuel. Ces métadonnées présentes ne constituent pas un recensement historique.

Le coût que l’abstraction laisse derrière elle

La mise en garde de RFC 707 est nette : un appel local est peu coûteux, un appel distant ne l’est pas, puisqu’il nécessite des messages IPC. Les programmeurs doivent choisir avec discernement ; les programmes distribués peuvent se poursuivre de manière asynchrone ; toutes les communications utiles ne sont pas des procédures. L’interface plus commode ne change ni la distance ni les modes de défaillance.

La portée historique est donc étroite mais intéressante : RFC 707 décrit une tentative de mutualiser le travail répétitif des dialogues applicatifs, testée dans un environnement TENEX identifié. Les sources disponibles ne montrent ni un déploiement général, ni une filiation avec les systèmes RPC ultérieurs. Il s’agit d’un modèle et d’un prototype documentés, avec leurs limites explicitement énoncées.

Sources