Résumé

  • RFC 1314 définit TIFF-B pour l’échange d’images de type fax : fichiers multipages, une bande TIFF par page, MMR lorsque possible et alternatives encadrées.
  • Il sépare le format de fichier de son acheminement : FTP ou SMTP peuvent porter le fichier sans devenir une propriété de ses octets.
  • Numérisation, stockage, manipulation, communication, affichage, impression et sortie fax restent des faits distincts. Un fichier conforme ne les prouve pas.

Une image devenue objet

Le fax classique réunissait dans un même geste l’entrée du papier, l’encodage, une conversation en temps réel, le décodage et la sortie du papier. Dire qu’un fax était envoyé pouvait donc faire disparaître les étapes intermédiaires. RFC 1314 propose une autre grammaire : une image est numérisée dans un fichier, ou créée par logiciel ; elle peut être conservée, transformée ou communiquée ; elle peut ensuite être affichée ou imprimée.

Les verbes du texte ne sont pas des synonymes. Une image peut venir d’un scanner, d’un logiciel ou d’un télécopieur, puis être partagée, dupliquée, affichée, imprimée ou faxée. Le télécopieur devient un appareil d’entrée ou de sortie entre papier et fichiers, non le réseau lui-même. Le document peut attendre dans un stockage, passer par plusieurs moyens ou être rendu sur un autre périphérique.

Cette séparation est aussi une discipline de preuve. Un fichier existe indépendamment de son voyage. Un voyage est différent d’un décodage. Un décodage n’est pas encore un affichage, et un affichage n’est pas une preuve de lecture. Le RFC ne promet pas de répondre à toutes ces questions ; il les laisse visibles.

Le contrat TIFF-B

Le RFC choisit TIFF comme cadre et le contraint pour l’échange. TIFF-B prend en charge les fichiers multipages avec une bande TIFF par page. Il recommande MMR lorsque possible. MH, MR et l’absence de compression restent permis ; pour MH ou MR, les lignes doivent être alignées sur des octets. Le texte recommande aussi 600, 400 ou 300 dpi, ou les résolutions Group 3 indiquées, afin de favoriser l’interopérabilité.

Ces règles définissent ce qu’une implémentation peut raisonnablement offrir au point d’échange. Elles ne sont pas un reçu universel. Un TIFF-B peut établir une structure de fichier, un nombre de pages et une méthode d’encodage. Il n’identifie ni le scanner d’origine, ni l’expéditeur, ni le transport réellement choisi. Il ne prouve pas que les octets sont arrivés, que le destinataire a accepté la compression ou qu’une page a été rendue correctement.

Le RFC distingue aussi l’échange du stockage local. Un hôte n’est pas obligé de conserver ses images au format spécifié ; il peut convertir entre son format interne et le format d’échange. Si le destinataire ne sait pas traiter une compression, une conversion peut être nécessaire. Le texte ne dit ni qui l’effectue ni quel algorithme l’exécute. Ce n’est pas une lacune à combler par supposition : un contrat de représentation ne crée pas la chronologie des opérations internes.

Le transport reste ailleurs

RFC 1314 dit explicitement que le format du fichier et la manière de communiquer les fichiers sont des questions distinctes. FTP ou SMTP sont des moyens possibles. Le même TIFF-B peut emprunter des porteurs différents ; les journaux, garanties et défauts pertinents appartiennent alors à ces porteurs, pas au fichier.

Le document note les difficultés alors rencontrées par SMTP avec le binaire et la taille. Cette remarque n’établit rien sur les messages ultérieurs. Surtout, citer FTP ou SMTP ne démontre pas qu’un fichier concret a utilisé l’un d’eux. Un type de fichier ne remplace ni un journal de transfert, ni une vérification d’intégrité, ni une preuve séparée de réception.

Le même raisonnement vaut pour une archive locale. L’image conservée par un hôte, la forme proposée à l’échange et les octets transmis peuvent être liés sans être identiques. Les confondre transforme une capacité d’interopérer en récit fictif de possession, de livraison et de résultat.

Défaire le mot « fax »

Le RFC nomme quatre questions que le fax traditionnel assemble : présentation et compression, transmission des données, entrée de l’image depuis le papier et sortie de l’image vers le papier. Une page créée par logiciel peut être stockée avant toute communication. Une image scannée peut être dupliquée vers plusieurs lieux. Un fichier peut être affiché plutôt qu’imprimé. Rien de cela n’est obligatoire parce que le fichier a la bonne forme.

Une carte fax ou un modem peut négocier avec le télécopieur destinataire ; si la compression n’est pas gérée, il faudra peut-être convertir. Négocier, convertir et imprimer sont des événements ultérieurs avec leurs propres conditions. Les loger rétroactivement dans le fichier reviendrait à prendre un conteneur pour témoin de toute l’opération.

Une chaîne honnête conserve : fichier créé, fichier préparé pour l’échange, transport tenté, octets acceptés ou refusés, image décodée, image rendue, sortie d’un périphérique et réponse éventuelle. Certaines traces manqueront. Leur absence ne donne pas à la trace voisine le droit de parler pour toutes.

Sources et limites de preuve

Cette analyse repose sur RFC 1314, A File Format for the Exchange of Images in the Internet (avril 1992). Il étaye TIFF-B, les règles de compression et de résolution, la séparation format/transport/stockage et le modèle numériser ou créer, conserver/manipuler/communiquer, afficher/imprimer. Il ne prouve aucun transfert, expéditeur, destinataire, conversion, affichage, impression, télécopie, lecture, déploiement actuel ou résultat commercial.