Résumé

  • RFC 1556 décrivait trois régimes de texte bidirectionnel : le compositeur préparait l'ordre visuel, l'afficheur calculait l'ordre implicite, ou des commandes insérées dans le texte dirigeaient le mode explicite.
  • Le transport MIME pouvait conserver les caractères non ASCII sans prouver l'ordre lu par le destinataire ; l'étiquette de direction, les commandes et le contexte de rendu formaient des preuves distinctes.
  • Ce document Informational de décembre 1993 n'était pas une norme Internet. Les travaux ultérieurs sur HTML, Unicode et le courrier UTF-8 montrent la permanence de la frontière, pas une filiation directe ni le déploiement des suffixes proposés.

La ponctuation avait changé de voisin

Un archiviste vérifie un vieux message. La somme de contrôle correspond, le décodage MIME restitue chaque caractère, et le fichier ne présente aucune corruption. Pourtant, lorsqu'il ouvre la même ligne dans deux lecteurs, le nom latin, le nombre et le point final ne sont plus voisins de la même façon.

Le diagnostic ne porte pas sur une perte pendant le trajet. Il porte sur une décision prise après le trajet. Une suite de caractères doit encore devenir une ligne : il faut choisir une direction de paragraphe, interpréter les caractères neutres, traiter les segments de sens contraire et décider à quel moment le retour à la ligne intervient.

C'est la question précise de RFC 1556, Handling of Bi-directional Texts in MIME. Hank Nussbacher l'a publiée en décembre 1993. La notice du RFC Editor et la fiche IETF la classent Informational ; le texte précise qu'elle ne définit aucune norme Internet.

La proposition tenait en une convention direction pour MIME. Sa portée analytique était plus grande : la fidélité de la représentation transportée n'épuisait pas la fidélité de sa présentation.

MIME avait gagné le droit de transporter d'autres caractères

RFC 1521 avait donné aux corps de messages une structure capable de décrire des médias et des jeux de caractères au-delà d'ASCII. Base64 et Quoted-Printable protégeaient les valeurs lors de leur passage dans une infrastructure encore contrainte. Sa notice historique situe cette première partie de MIME.

RFC 1522 avait étendu la représentation non ASCII à certaines zones des en-têtes. Le logiciel de rédaction créait un encoded-word ; le lecteur compatible le reconnaissait, annulait l'encodage de transport puis affichait le texte selon le charset indiqué. La notice correspondante en fixe l'identité.

Ces mécanismes répondaient à deux questions essentielles : quelles valeurs représentent le texte, et comment leur faire traverser le courrier existant ? Ils ne répondaient pas automatiquement à une troisième. Dans une ligne mélangeant ISO-8859-6 ou ISO-8859-8 avec des caractères latins, quelle position visuelle doit prendre chaque élément ?

Le charset identifie des caractères. Le transport protège leurs valeurs. L'ordre de lecture demeure une opération de présentation.

Le courrier hébreu rendait visible le choix préalable

La publication voisine, RFC 1555, signée par Nussbacher et Yehavi Bourvine, décrivait l'emploi de MIME et d'ISO-8859-8 pour le courrier hébreu. Sa notice RFC Editor la classe elle aussi Informational.

Elle déclarait le mode visuel par défaut. L'utilisateur saisissait l'hébreu de droite à gauche, mais le logiciel l'encodait dans un ordre de gauche à droite, puis MIME le transmettait ainsi. Le lecteur pouvait rester ignorant de la direction du contenu : il dessinait une rangée déjà arrangée pour lui.

Cette compatibilité déplaçait la difficulté vers l'amont. L'ordre stocké dépendait de l'écran attendu. Un logiciel ultérieur qui prend cette rangée visuelle pour un texte en ordre logique et lui applique un algorithme bidirectionnel réordonne une seconde fois ce qui l'avait déjà été.

RFC 1555 rapportait aussi un risque documentaire concret. Certains réglages de Listserv redistribuaient les messages avec des en-têtes raccourcis ; ses archives pouvaient omettre les informations MIME. Le contenu encodé subsistait, mais la convention permettant de l'interpréter disparaissait.

Le texte anticipait enfin un courrier transparent sur huit bits. Cette évolution pouvait rendre l'encodage de transfert partiellement inutile, sans supprimer le Content-Type ni la direction. Un canal plus transparent ne choisit toujours pas la lecture.

Le mode visuel confiait le résultat au compositeur

Pour RFC 1556, visual était le mode par défaut. Il conservait le nom ISO-8859 sans suffixe. L'application d'affichage suivait une direction principale unique, de gauche à droite, et traitait le texte comme un flux unidirectionnel. Le logiciel de composition devait préparer les caractères dans l'ordre qui produirait l'image correcte ; aucun contrôle directionnel et aucun algorithme de réordonnancement n'intervenaient ensuite.

L'avantage était opérationnel : un terminal simple pouvait montrer une ligne qu'il ne savait pas analyser. Mais cette simplicité n'était pas gratuite. La décision vivait dans la préparation du message et dans l'hypothèse que le destinataire n'essaierait pas de l'améliorer.

L'édition révèle la dette. Déplacer le curseur, insérer un mot latin, rechercher une séquence, modifier la largeur de fenêtre ou copier la phrase oblige à manipuler un ordre construit pour une image donnée plutôt qu'un ordre logique durable.

Dans ce régime, le compositeur est responsable. Le lecteur ne réussit qu'en restant volontairement peu informé.

Le mode implicite transformait le contexte en calcul

Les noms ISO-8859-6-i et ISO-8859-8-i désignaient le mode implicit. L'ordre de présentation devait être déterminé par un algorithme à partir du type des caractères, de leur position relative à leurs voisins et d'une direction principale. RFC 1556 renvoyait à ECMA TR/53 pour la procédure complète.

Le texte pouvait conserver une structure plus logique, mais le destinataire héritait de nouvelles obligations. Il devait reconnaître le mode, employer des propriétés directionnelles compatibles, connaître la direction de base et délimiter correctement le paragraphe. Les chiffres, la ponctuation et les caractères neutres empruntent une part de leur comportement au contexte. Le point où la ligne est coupée devient donc une donnée d'exécution.

Un algorithme partagé réduit l'ambiguïté ; il ne supprime pas le besoin de preuve. Deux rendus peuvent partir de la même suite et diverger si leur version, leur direction de base, leurs limites de balisage ou leurs coupures de ligne diffèrent.

La somme de contrôle du message ne permet pas de reproduire cette décision. Il faut aussi conserver l'environnement qui l'a prise.

Le mode explicite confiait une seconde moitié au destinataire

Les suffixes ISO-8859-6-e et ISO-8859-8-e indiquaient le mode explicit. Des séquences de contrôle étaient mêlées au texte afin d'établir la direction. L'auteur pouvait déclarer un changement de contexte plutôt que de s'en remettre uniquement aux types de caractères.

La déclaration explicite créait pourtant deux devoirs. Les commandes devaient survivre à la transmission et aux transformations ; l'afficheur devait en comprendre la portée. Un filtre pouvait supprimer ces caractères invisibles, un convertisseur pouvait les préserver sans savoir les exécuter, et une portée mal fermée pouvait affecter davantage de texte que prévu.

Selon RFC 1556, le rapport ECMA TR/53 définissait trois nouvelles fonctions de contrôle et modifiait 22 fonctions d'ECMA-48. Ce volume dément l'image d'un simple marqueur « lire vers la droite ». La direction touchait les positions actives, les mouvements et la relation entre la composante de données et celle de présentation.

L'expéditeur choisissait donc les commandes ; le destinataire devait préserver puis exécuter leur machine d'état. Conserver les seules lettres visibles ne conservait pas le contrat.

Une position de données n'était pas une position à l'écran

Le modèle d'ECMA TR/53 décrivait un dispositif recevant caractères graphiques et fonctions de contrôle, puis produisant une image lisible selon les conventions d'écriture. Il séparait une composante de données d'une composante de présentation et pouvait suivre une position active dans chacune.

Cette séparation explique pourquoi le problème n'était pas celui de la police. Une police dessine un glyphe. Le modèle de présentation décide où le placer, comment le curseur avance et à quelle position s'appliquent un retour chariot ou un effacement.

RFC 1556 traduisait cette architecture dans le vocabulaire MIME. Le destinataire devait savoir si le flux contenait une rangée visuelle déjà préparée, une suite attendant un calcul implicite ou un texte muni d'ordres explicites. Perdre ce renseignement revenait à injecter des données exactes dans la mauvaise machine.

Quatre incidents sans caractère manquant

Premier incident : une passerelle transforme ISO-8859-8-i en ISO-8859-8, ou l'archive perd le Content-Type. Les caractères restent présents, mais le sélecteur de mode disparaît.

Deuxième incident : le compositeur a créé un ordre visuel et le lecteur suppose un ordre logique. L'algorithme implicite réordonne une seconde fois. Chaque composant respecte son propre contrat ; leur composition est fausse.

Troisième incident : un assainisseur retire les contrôles explicites parce qu'ils sont invisibles. Une comparaison des lettres imprimables conclut à tort que les textes sont équivalents.

Quatrième incident : deux afficheurs implicites emploient une direction de base, une coupure de ligne, une limite de style ou une révision d'algorithme différente. La suite décodée est identique, la suite visuelle ne l'est pas.

Les nombres et la ponctuation rendent ces écarts moins décoratifs qu'ils n'en ont l'air. Un identifiant peut sembler correct et être copié dans un autre ordre. Un signe peut s'attacher au mauvais montant. La présence de tous les caractères ne prouve pas la préservation des relations entre eux.

Les mécanismes ultérieurs témoignent d'une frontière, pas d'une généalogie

En 1997, RFC 2070 a introduit dans HTML des outils d'internationalisation tels que l'attribut DIR et l'élément d'override BDO. Sa notice appartient au balisage Web. Elle ne démontre pas que HTML a directement déployé la convention de RFC 1556.

Une version ancienne de l'algorithme bidirectionnel Unicode distinguait l'ordre logique en mémoire de l'ordre d'affichage et expliquait que les codes directionnels agissaient sur ce dernier. L'UAX #9 actuelle a beaucoup évolué et définit également le rôle possible des protocoles de niveau supérieur.

En 2012, RFC 6532 a permis l'emploi direct d'UTF-8 dans les valeurs d'en-têtes d'un environnement de courrier compatible de bout en bout. Sa notice en fixe la portée. Simplifier l'accès au répertoire de caractères ne fusionne toujours pas l'ordre stocké et l'ordre rendu.

Ces textes montrent que le même type de frontière demeure. Ils ne prouvent ni l'adoption des suffixes -i et -e, ni une descendance unique allant de RFC 1556 à Unicode, HTML ou SMTPUTF8.

Trois reçus pour une phrase

Le reçu de transport conserve les octets d'origine, leur empreinte, l'encodage de transfert et la suite de points de code obtenue. Il répond à la question du changement pendant le trajet.

Le reçu d'interprétation conserve Content-Type, charset, mode de direction, contrôles explicites, direction de base, balisage, style, moteur de rendu et version d'algorithme. Il explique quelles règles le destinataire croyait appliquer.

Le reçu de présentation conserve les coupures de lignes, l'ordre visuel résolu, une capture et le résultat d'un copier-coller ou d'un aller-retour. Il montre ce qui a été vu dans un environnement déterminé.

Une capture sans entrée n'établit qu'une image passée. Une empreinte sans sortie n'établit qu'une suite. Les jeux d'essai doivent mêler arabe ou hébreu, latin, chiffres, ponctuation, caractères neutres, contextes imbriqués et plusieurs largeurs. Lors d'une migration, les anciens et nouveaux rendus doivent rester comparables jusqu'à l'explication de leur différence.

La publication ne remplaçait pas l'exécution

La primauté du code en fonctionnement de Heng Lu fournit aujourd'hui une discipline utile : le document coordonne, mais l'implémentation, l'exploitation et l'usage déterminent la réalité opérationnelle. La publication de RFC 1556 prouve une convention documentée, pas son adoption par les clients de messagerie.

Le principe de spécification initiale minimale, décision future localisée et adoption volontaire demande quelles règles communes sont déterministes et vérifiables localement. Ici, l'égalité des caractères transmis était un invariant trop faible ; le mode, le contexte et la procédure de présentation devaient aussi entrer dans la preuve.

La discipline des couches de réalité empêche le reçu du transport de parler au nom du rendu. Ce vocabulaire est postérieur et ne démontre pas l'intention de Nussbacher ou d'ECMA. Il borne notre propre récit.

« Livré » n'avait pas un seul propriétaire

En mode visuel, le compositeur avait déjà agi. En mode implicite, l'algorithme du lecteur devait agir. En mode explicite, l'expéditeur fournissait des commandes que le lecteur devait exécuter. Ignorer quel acteur était intervenu suffisait à rendre une implémentation consciencieuse incorrecte.

L'histoire de RFC 1556 n'est donc pas celle d'un MIME incapable de transporter l'hébreu ou l'arabe. MIME avait permis le voyage. Le court mémo avait refusé de prendre le billet d'arrivée pour un certificat de lecture.

Une empreinte prouve la conservation de la suite. Un mode déclaré et des contrôles préservés prouvent le contexte d'interprétation. Un rendu nommé et testé prouve un résultat visible. Il faut les trois avant que « le message est bien arrivé » signifie autre chose que « ses octets sont ici ».

Sources