Résumé

  • La RFC 733 normalisait la forme des messages textuels transmis entre hôtes ARPANET ; elle ne définissait ni un service de messagerie complet ni son interface utilisateur.
  • Cette grammaire commune est arrivée alors que l’envoi reposait toujours sur FTP, après des propositions antérieures et des analyseurs locaux qui avaient créé des attentes différentes.

Analyse

La solution rapide restait dans FTP

En 1973, le courrier réseau circulait déjà par deux commandes du File Transfer Protocol : MAIL et MLFL. Ce mécanisme pouvait déposer un message dans le système local du destinataire, mais il ne garantissait pas l’uniformité des en-têtes. Un hôte pouvait transmettre l’auteur, le titre ou la date sous une forme qu’un autre ne reconnaissait pas correctement. Pour FTP, le message entier — en-tête compris — restait une donnée.

La RFC 524 proposait un protocole de courrier plus riche dans l’espace de commandes de FTP. Son auteur expliquait aussi pourquoi ce choix s’appuyait sur FTP : celui-ci était largement implémenté, contrairement au protocole unifié au niveau utilisateur envisagé. La RFC 561 a choisi une solution provisoire plus rapide. Au lieu d’attendre de nouvelles commandes de remise, quatre auteurs ont proposé une convention textuelle pour les messages déjà envoyés par MAIL ou MLFL. From, Date et Subject recevaient une forme reconnaissable, tandis que d’autres champs restaient possibles. Les auteurs présentaient explicitement cette voie comme plus rapide à mettre en œuvre qu’une modification du protocole de courrier.

L’intervention était limitée. La RFC 561 ne remplaçait pas le transport ; elle cherchait à rendre ses données plus intelligibles aux lecteurs et aux logiciels. Sa souplesse laissait toutefois une lacune : la catégorie des champs « divers » pouvait s’étendre, mais les destinataires et d’autres éléments n’avaient pas encore de syntaxe commune.

Le titre d’un RFC pouvait dépasser son contenu

Publiée en 1975 sous le titre « Message Transmission Protocol », la RFC 680 ajoutait des champs au message. Son texte définit des en-têtes et leur sens ; il ne définit pas le mécanisme qui transfère un message entre hôtes. La RFC 724, qui proposait une révision, explique que la RFC 680 avait été peu diffusée et n’avait pas été formellement adoptée comme norme officielle de l’ARPANET. Certains développeurs l’auraient néanmoins traitée comme telle.

La RFC 724 décrit une autre source d’autorité, plus concrète : les logiciels déjà utilisés. Selon ses auteurs, les systèmes TENEX émettaient davantage de messages réseau que les autres types d’hôtes, et leur syntaxe To et Cc était devenue une convention de fait. Les lecteurs TENEX s’attendaient alors à cette forme. Multics avait essayé d’autres formats et, d’après le rapport, des utilisateurs s’étaient plaints que leurs messages ne soient pas analysés par les systèmes TENEX. Il s’agit du témoignage contemporain d’un comité, pas d’un recensement de tous les hôtes. Il montre toutefois pourquoi le titre officiel d’un document ne suffisait pas à fixer le format : les messages et les analyseurs déjà en circulation façonnaient les attentes.

La RFC 733 normalisait la frontière

Publiée en novembre 1977, la RFC 733 a remplacé les RFC 561 et 680 ainsi que la proposition RFC 724. Elle organisait la syntaxe des messages textuels de l’ARPANET, notamment les formes d’adressage des destinataires et les références à des listes stockées. Son préambule indique que le travail s’est nourri d’une année de discussions dans l’environnement de messagerie lui-même, avec plus de vingt participants. C’est la trace d’un processus de travail, pas la preuve que chaque système a adopté le résultat.

Le texte délimite explicitement son rôle. Il définit le format du contenu transmis entre hôtes. Il ne dicte ni les fonctions qu’un système local doit prendre en charge ni l’apparence des logiciels servant à composer et lire les messages. La syntaxe autorisait des champs structurés, mais chaque hôte pouvait choisir ceux qu’il traiterait automatiquement. Les auteurs espéraient que ce format commun répondrait aux besoins immédiats et laisserait aux développeurs le temps de concevoir « correctement » un protocole distinct de transmission du courrier.

Le compromis était pragmatique : rendre commune d’abord la forme du message, tout en laissant ouverte la conception du service local. Un expéditeur pouvait utiliser un système et son destinataire un autre sans partager la même interface. Cela ne rendait pourtant pas toutes les implémentations compatibles par décret. Il fallait toujours écrire les analyseurs ; l’adoption dépendait des hôtes qui les exécutaient.

Les normes ultérieures ont rendu la séparation plus visible

En 1982, la RFC 821 a défini le Simple Mail Transfer Protocol comme un mécanisme de transfert entre hôtes sur un flux fiable et ordonné. La RFC 822 a séparément défini le format des messages textuels de l’Internet ARPA et a explicitement remplacé la RFC 733. Leur lecture conjointe distingue mieux deux questions : comment déplacer un message et comment structurer son contenu.

Les documents permettent donc une histoire circonscrite, pas d’affirmer que la RFC 733 a inventé le courrier électronique ou unifié immédiatement tous les systèmes. La RFC 724 rapporte une convention d’en-tête informelle mais largement employée ; la RFC 733 fournit une syntaxe formelle et en précise le périmètre ; les RFC 821 et 822 documentent plus tard des normes distinctes pour le transfert et le contenu. Aucun de ces textes ne mesure, à lui seul, combien d’hôtes ont appliqué chaque règle ni à quel moment un système donné a changé.

Sources et limites des éléments disponibles

Les sources primaires sont les RFC 524, 561, 680, 724, 733, 821 et 822. Le récit de la RFC 724 sur TENEX et Multics lui est attribué ; il n’est pas transformé en statistique d’adoption pour tout le réseau. Les idées ultérieures de la Note 64 de Heng Lu — spécification initiale minimale, décisions futures locales et adoption volontaire — servent uniquement de grille d’analyse. Elles ne prouvent pas l’intention des auteurs des années 1970.

Sources