Résumé

  • Daté de décembre 1974, le RFC 675 nomme Vinton Cerf, Yogen Dalal et Carl Sunshine comme auteurs. Ses dispositions et ses remerciements permettent de reconnaître des contributions précises, mais pas de distribuer entre eux l’ensemble des décisions de conception. Source : RFC 675.
  • L’Internet Society distingue l’éventail de services envisagé par Cerf et Bob Kahn du service plus limité assuré par la première implémentation de TCP. Ce contraste ne désigne ni un décideur unique ni la version exacte du texte à laquelle cette implémentation correspondait. Source : récit historique de l’Internet Society.

Trois auteurs, un objet technique identifiable

Pour situer la contribution de Vint Cerf, il est plus utile de partir d’un document déterminé que d’une formule célébrant un inventeur. Le RFC 675, intitulé Specification of Internet Transmission Control Program et daté de décembre 1974, porte les noms de Vinton Cerf, Yogen Dalal et Carl Sunshine. C’est une attribution positive et précise : Cerf figure parmi les auteurs d’une spécification technique, avec deux coauteurs qu’un récit centré sur sa personne ne doit pas effacer. RFC 675.

La portée de cette attribution mérite toutefois d’être respectée. Trois noms ne prouvent pas trois contributions identiques. Ils ne disent pas qui a rédigé chaque disposition, tranché chaque désaccord ou dirigé une réalisation logicielle. Inversement, l’impossibilité de reconstituer cette répartition ne rend pas la participation de Cerf indéterminée : son rôle de coauteur est bien documenté. L’enjeu consiste à conserver ce fait sans le transformer en autorité exclusive sur tout ce qui a suivi.

Le document fournit aussi une prise concrète sur le travail auquel son nom est associé. Il ne se contente pas d’énoncer l’ambition de relier des systèmes. Il décrit notamment comment distinguer les interlocuteurs et les flux d’une communication. Cette précision technique donne du contenu à l’attribution d’auteur ; elle n’autorise pas à attribuer personnellement à Cerf la règle choisie.

Nommer les échanges sans confondre les niveaux

Dans la présentation du RFC 675, la communication en réseau est une communication entre processus. Un processus peut disposer de plusieurs ports pour distinguer ses flux de communication avec d’autres processus. Pour obtenir un nom unique, la spécification décrit un nom de socket associant trois éléments : un identifiant de réseau, un identifiant TCP et un nom de port. Dispositions de nommage du RFC 675.

Le mécanisme est intelligible sans le remplacer par une description des protocoles actuels. Le processus est l’interlocuteur ; plusieurs ports permettent de différencier ses communications ; le nom composé apporte le contexte nécessaire à son identification. Les trois éléments doivent donc être lus ensemble. Substituer silencieusement à cette terminologie celle d’une architecture ultérieure ferait perdre la spécificité du document de 1974.

L’intérêt de cette règle, dans une analyse de la contribution de Cerf, est sa matérialité. Une convention explicite peut être discutée, comparée à une autre proposition et confrontée à une réalisation. Elle fournit un objet de travail partagé, au-delà d’une intention générale. Mais la présence de la règle dans une spécification ne prouve pas, à elle seule, qu’un programme l’exécutait correctement, que plusieurs programmes étaient compatibles ou que des exploitants l’avaient adoptée. Ce sont des questions différentes, qui appellent d’autres traces.

Les remerciements rendent d’autres contributions visibles

Le RFC 675 ne limite pas le crédit technique à ses trois auteurs. Ses remerciements attribuent à R. Tomlinson la procédure de poignée de main en trois échanges et la sélection des numéros de séquence initiaux. Ils nomment également D. Belsnes, J. Burchfiel, M. Galland, R. Kahn, D. Lloyd, W. Plummer et J. Postel pour leurs idées et leurs conseils sur la conception du protocole. Remerciements du RFC 675.

Le texte reconnaît aussi l’aide de R. Metcalfe, A. McKenzie, H. Zimmerman, G. LeLann et M. Elie dans la clarification de problèmes rencontrés au début du travail de conception. Crédits relatifs aux premiers travaux dans le RFC 675.

Ces mentions ne sont pas toutes de même nature. Le crédit à Tomlinson est associé à deux éléments techniques identifiables ; d’autres remerciements portent sur des idées, des conseils ou la clarification de difficultés. Les fondre dans une liste indistincte ferait disparaître une partie de l’information. Les convertir en pourcentages de contribution, en organigramme ou en preuve d’invention exclusive irait, au contraire, au-delà de ce qu’elles établissent.

La conséquence pour un portrait de Cerf est nette. Son rôle peut être reconnu sans annexer les idées que la spécification crédite à d’autres. La précision de l’attribution ne diminue pas sa contribution : elle permet de la décrire dans un travail collectif dont certaines composantes sont nommées, tandis que la répartition complète demeure ouverte.

Une ambition de service n’est pas encore un service disponible

Un second texte éclaire cette limite sous un autre angle. Dans son récit A Brief History of the Internet, l’Internet Society indique que Cerf et Bob Kahn envisageaient pour TCP un éventail de services allant d’une livraison fiable et ordonnée à un service de datagrammes. Dans ce dernier cas, les applications auraient pu utiliser le réseau sous-jacent malgré la possibilité de pertes, de corruption des données ou de changements dans leur ordre d’arrivée. Il s’agit ici de la description de leur intention par ce récit historique. Internet Society.

Le même récit précise que la première implémentation de TCP ne prenait en charge que des circuits virtuels. Il présente ce service comme adapté au transfert de fichiers et à la connexion à distance, mais moins adapté à des applications réseau avancées. L’écart ainsi décrit se situe entre la gamme envisagée et celle effectivement prise en charge par cette première réalisation. Récit de l’Internet Society sur l’implémentation initiale.

Il serait tentant d’en tirer une histoire personnelle de choix, d’erreur puis de correction. Ces éléments ne la démontrent pas. Ils ne précisent ni l’équipe de cette implémentation, ni sa date exacte, ni la décision individuelle de Cerf qui aurait déterminé son périmètre. Ils ne suffisent pas davantage à identifier cette réalisation à une version particulière du RFC 675. Le rapprochement entre les deux sources sert donc à distinguer les types de contribution, non à reconstituer une séquence causale absente des éléments présentés.

La conclusion peut rester substantielle tout en étant bornée. Cerf a participé, comme coauteur, à une spécification comportant des règles concrètes et des crédits explicites. Dalal et Sunshine partagent l’attribution d’auteur ; les contributeurs remerciés doivent rester visibles selon les termes du document. Quant à la réalisation logicielle et aux résultats d’un déploiement, ils ne se déduisent pas d’une liste d’auteurs. Reconnaître précisément le travail écrit est plus solide que lui faire porter, à lui seul, toute l’histoire d’un système.