Résumé

  • RFC 2223 faisait de l’ASCII le document de référence et du PostScript une présentation secondaire soumise au contrôle du RFC Editor.
  • L’ordre de publication permettait d’ajouter des schémas sans laisser deux fichiers raconter deux RFC différentes.

Le fichier qui rend le mieux sur papier n’est pas toujours celui qui fait foi. En octobre 1997, RFC 2223 a tranché la question : le texte ASCII était la version principale ; le PostScript pouvait venir ensuite comme présentation secondaire ou alternative. Une page plus élégante n’obtenait pas, par sa seule apparence, le même rang que le texte publié.

Jon Postel et Joyce Reynolds ont écrit ce guide pour les auteurs qui soumettaient des documents à la série RFC. Le problème était très concret : les fichiers étaient copiés, affichés et imprimés sur des équipements variés. Certains lecteurs cherchaient une phrase à l’écran ; d’autres avaient besoin de graphiques lisibles sur papier. Une même publication devait supporter ces usages sans perdre son identité en route.

RFC 2223 décrivait les deux avantages. Beaucoup de lecteurs utilisaient emacs ou grep pour retrouver un passage, puis en reprenaient quelques lignes dans un courriel. Le PostScript ne se prêtait pas encore à ces habitudes. Les outils de production variaient aussi : certains programmes censés créer du PostScript produisaient des fichiers non conformes. Mais le format imprimé présentait mieux les dessins et les diagrammes. Le choix ne se résumait donc pas à opposer un vieux texte à une belle mise en page. Il fallait décider si la seconde pouvait embellir le document sans modifier le texte public.

La procédure suivait un ordre précis. Le RFC Editor traitait d’abord le manuscrit ASCII jusqu’à sa publication comme RFC. L’auteur pouvait ensuite envoyer une version PostScript. Pour qu’elle rejoigne les dépôts RFC et soit annoncée à la communauté, le RFC Editor devait juger qu’elle était « la même » que la version ASCII. Le PostScript était facultatif ; l’accord de l’éditeur, lui, ne l’était pas.

Les auteurs et l’éditeur ne faisaient pas le même travail. Les premiers devaient fournir un original éditable. Le RFC Editor pouvait reformater le texte, insérer le numéro définitif, demander des corrections ou renvoyer le document pour reprise. Dans le cas d’une copie PostScript, il gardait aussi la décision finale sur son admission comme représentation du texte principal. Un fichier ne pouvait pas s’auto-certifier par sa seule extension.

Le guide encadrait également la fabrication. Il précisait le format de page, les marges, la taille minimale des caractères et quelques polices courantes. Les schémas devaient utiliser un PostScript assez sobre pour fonctionner sur des imprimantes ordinaires. Cette prudence n’était pas décorative : une page qui s’imprime mal ne devient pas plus accessible parce que son code est sophistiqué.

La pagination créait un autre piège. Le nombre de pages et la place d’une section pouvaient différer entre ASCII et PostScript après recomposition. RFC 2223 recommandait donc de citer les numéros de section plutôt que les pages. C’est une petite règle qui protège les références : le lecteur peut changer de présentation sans perdre le passage visé.

RFC 1111 avait posé une partie du cadre dès 1989. Il autorisait les formats ASCII et PostScript et plafonnait l’ASCII à 58 lignes par page et 72 caractères par ligne. RFC 2223 a conservé ce socle étroit tout en expliquant plus clairement pourquoi une version imprimée devait rester liée au texte principal.

RFC 7322 a remplacé RFC 2223 en 2014. Le guide ultérieur rattache les conventions fondamentales de la série aux années 1970 et à Jon Postel, premier RFC Editor. La technologie d’affichage a changé ; l’archive a toujours besoin de désigner une version de référence. Les RFC décrivent le contrôle d’équivalence, mais ne donnent ni le nombre de versions PostScript contestées ni leur fréquence d’utilisation.

Sources officielles