Résumé

  • La RFC 1357 donnait aux éditeurs un format lisible et analysable pour envoyer par e-mail les références de rapports techniques. Elle définissait le message, pas l’inscription automatique dans les catalogues qui le recevaient.
  • Une révision portait un numéro supérieur et renvoyait la notice entière. Le retrait suivait ce mécanisme : l’éditeur pouvait vider le titre, mais le destinataire devait encore traiter la nouvelle version.

Avant la recherche dans une base de données, il y avait une besogne moins glorieuse : apprendre qu’un rapport venait de paraître. Une annonce postale arrivait sur papier, parfois trop tard, et il fallait ensuite recopier ses éléments bibliographiques. Dans la RFC 1357, publiée en juillet 1992, Danny Cohen proposa d’expédier cette annonce sous la forme d’un petit enregistrement textuel par e-mail. La vitesse gagnée à l’envoi rendait plus aiguë une vieille question : qui avait le droit de modifier la fiche une fois reçue ?

La réponse se lit dans l’ossature même du format. BIB-VERSION, ID, ENTRY et END étaient obligatoires, dans cet ordre. L’identifiant associait un symbole d’éditeur sous son contrôle à son numéro de rapport, séparés par //. Autour de ce noyau pouvaient venir TITLE, AUTHOR, RETRIEVAL et ABSTRACT. Le destinataire disposait donc d’une clé pour retrouver la fiche ; l’éditeur disposait d’un moyen de désigner la fiche qu’il voulait corriger.

La correction n’était pas un minuscule erratum à appliquer au hasard d’une boîte aux lettres. REVISION indiquait un entier croissant et une explication ; la nouvelle transmission devait reprendre la notice complète. Si la révision 2 arrivait sans le premier e-mail, la bibliothèque pouvait tout de même lire une notice entière. Si un ancien message arrivait en retard, le numéro rendait visible le conflit d’ordre. Le format évitait de faire dépendre la vérité locale d’une chaîne parfaite de courriers.

Le retrait concentrait cette tension. L’éditeur pouvait envoyer une révision avec les champs obligatoires, expliquer le retrait dans NOTES et laisser TITLE vide ou absent. L’exemple publié par la RFC montre cette forme, sans prouver qu’une bibliothèque réelle ait effacé un rapport déterminé. Le message transportait l’intention de l’éditeur ; la décision de conserver, remplacer ou signaler l’ancienne fiche appartenait au catalogue destinataire. Un retrait parfaitement transmis pouvait cohabiter avec un vieux titre toujours consultable.

Le document prévoyait aussi les faux départs. Une version préfixée par X signalait un essai ; DUMMY, TEST et les symboles d’éditeur commençant par X ne devaient pas nourrir une collection permanente. Ce n’était pas une preuve cryptographique d’origine. C’était une consigne de tri, utile seulement si l’importateur la respectait. Les lignes en ASCII imprimable, limitées à 79 caractères, les champs répétables et les lignes de continuation facilitaient la manipulation du texte par des systèmes très différents.

La notice n’était pas le rapport. RETRIEVAL pouvait indiquer où demander ou télécharger le document ; une référence trouvable ne garantissait pas que le fichier serait encore disponible. La RFC 1807, qui remplaça la première spécification, ajouta notamment HANDLE, OTHER_ACCESS, KEYWORD et WITHDRAW, et cita les usages de Cornell Dienst et Stanford SIFT. Elle témoigne de la poursuite du travail de catalogage, pas du sort de chaque message de 1992.

L’e-mail faisait voyager une déclaration plus vite que la poste. Il ne donnait pas à l’expéditeur les clés du catalogue d’autrui. Entre « retiré » dans une boîte de réception et « retiré » dans une recherche publique, il restait un acte institutionnel à accomplir.

Sources : RFC 1357 ; RFC 1807 ; fiche officielle de la RFC 1357.