Résumé

  • La RFC 1197 présentait ODA comme une architecture abstraite de documents composés. Un échange utile exigeait en plus un profil d’application documentaire et une correspondance entre ce profil et chaque système participant.
  • Le projet EXPRES, financé par la NSF, travailla à partir d’un profil du NIST et des fonctions d’Andrew, Diamond et Interleaf ; la RFC ne livre toutefois ni mesure de fidélité ni résultat de déploiement.
  • Les règles MIME et X.400 ultérieures transportèrent le profil et la classe séparément des octets ODA. Copier le corps sans le modifier ne prouvait ni interprétation identique, ni rendu, ni conservation de l’éditabilité.

L’expérience commençait par une proposition de recherche

Le projet EXPRES n’était pas une démonstration abstraite. La National Science Foundation voulait étudier l’envoi, par courrier électronique, de propositions de recherche encodées dans un format documentaire commun. Des équipes de Carnegie Mellon University et de l’University of Michigan travaillèrent avec McDonnell-Douglas Aerospace Information Systems, le NIST et Interleaf.

La RFC 1197, publiée par Mark Sherman en décembre 1990, résume ce cadre en deux pages. Sa notice RFC Editor et sa fiche IETF Datatracker la classent comme document Informational, non comme norme Internet.

Le choix d’un dossier réel rendait la question plus difficile. Un document de recherche n’est pas seulement un sac de caractères. Il combine hiérarchie, mise en forme, graphiques, images et possibilités de reprise. Le transporter n’avait d’intérêt que si les systèmes pouvaient reconstruire suffisamment de ces propriétés pour la tâche suivante.

EXPRES utilisa le profil d’application documentaire du NIST et les fonctions disponibles dans Andrew, Diamond et Interleaf. Ces noms attestent le périmètre de l’étude. Ils ne prouvent pas que les trois produits offraient les mêmes fonctions, que chaque page revenait intacte après un aller-retour ou qu’une proposition fut acceptée grâce à ODA. La RFC renvoie les stratégies détaillées à un livre de 1991 qui n’appartient pas au présent dossier de preuves.

ODA avait choisi un niveau plus général que l’éditeur

La RFC décrit ISO 8613 Office Document Architecture, également liée à CCITT T.410, comme une norme capable de représenter du texte à plusieurs polices, des images matricielles et des graphismes géométriques. Cette étendue répondait à l’ambition d’un format ouvert pour le courrier multimédia et l’échange de fichiers.

Mais le vocabulaire se situait au-dessus de celui des applications. Le texte cite des « composite logical object classes » et les oppose à des entités familières telles que les paragraphes. Il ne dit pas qu’ODA était physiquement incapable de porter une structure ressemblant à un paragraphe. Il dit que l’architecture générale ne livrait pas, à elle seule, l’objet commun sur lequel plusieurs éditeurs pouvaient s’engager.

Cette abstraction n’était pas une erreur de syntaxe. Elle évitait de faire d’un produit particulier la constitution de tous les autres. Elle laissait cependant ouverte une décision d’interopérabilité : parmi toutes les possibilités du modèle, lesquelles les participants allaient-ils réellement employer ?

Le profil réduisait la promesse avant que les logiciels la traduisent

La réponse de la RFC est le document application profile, ou DAP. Le profil définissait des entités communes dans le cadre ODA. Puis chaque système devait établir une correspondance entre ces entités et celles qu’il manipulait localement.

Le profil et l’adaptateur n’avaient pas le même pouvoir. Le premier délimitait la langue partagée par une communauté d’échange. Le second expliquait comment cette langue devenait un paragraphe, une zone graphique, une page ou une propriété dans un logiciel concret.

Ainsi, l’affirmation « compatible ODA » restait incomplète. Il fallait connaître le DAP, sa version, les classes effectivement utilisées, les extensions admises et la carte locale. Deux outils pouvaient reconnaître le même conteneur tout en divergeant sur une structure qui n’entrait pas dans leur intersection.

Un profil plus étroit n’appauvrissait pas nécessairement le standard. Il transformait une grande capacité théorique en contrat vérifiable. Les fonctions locales pouvaient rester plus riches, à condition de ne pas être présentées comme portables sans preuve.

MIME exposa le profil au lieu de le cacher dans le nom du format

En juin 1992, la RFC 1341 inclut application/oda dans le premier cadre MIME. Le sous-type indiquait un corps encodé selon ODA dans la représentation ODIF. La ligne Content-Type devait aussi fournir un paramètre profile, illustré par profile=Q112.

Cette paire de champs est révélatrice. Le type identifiait la famille de représentation ; le profil identifiait le sous-ensemble applicatif choisi. Si le mot ODA avait suffi à déterminer l’interprétation utile, le second identifiant aurait été superflu.

Il restait néanmoins une assertion, pas un constat. Un agent pouvait choisir un traitement à partir du type et du profil. L’en-tête ne démontrait pas que ce traitement implémentait correctement Q112, qu’il connaissait toutes les entités présentes, ni que le rendu correspondait à celui de l’expéditeur.

La RFC 1341 est aujourd’hui obsolète. Elle sert ici de source historique sur la séparation des responsabilités, non de guide pour un service MIME contemporain.

La copie d’octets ne transportait pas toute la signification

La RFC 1494 régla ensuite des équivalences entre des corps X.400 de 1988 et MIME. Pour ODA, le type de conversion du corps était « Byte copy ». Le relais pouvait donc conserver les données ODA sans les réécrire.

Autour de cette copie, il devait pourtant mapper séparément l’identifiant X.400 du profil vers le paramètre MIME profile, ainsi que la classe documentaire vers formatted, processable ou formatted-processable. La conservation des octets et la conservation des déclarations utilisaient des règles différentes.

Cette distinction fixe la portée de « sans perte ». Le relais pouvait prouver qu’il n’avait pas transformé le corps. Il ne prouvait pas que le destinataire savait en tirer le même modèle natif. La classe disait si le document promettait plutôt un résultat formaté, une structure traitable ou les deux ; le profil limitait le vocabulaire ; l’implémentation restait responsable du passage vers ses objets.

En l’absence de paramètres, la RFC 1494 prescrivait Q112 et formatted-processable par défaut. Elle permettait au relais de chercher les caractéristiques dans le document, sans l’y obliger car ces caractéristiques internes étaient optionnelles.

La valeur par défaut rendait le comportement reproductible, mais ne révélait pas une intention jamais déclarée. Un historique fiable doit donc distinguer trois provenances : valeur annoncée, valeur extraite et valeur ajoutée par la règle.

L’extension rendait la sécurité mobile

La RFC 2161 rassembla en janvier 1998 les définitions ODA pour MIME et X.400. Elle était Experimental et déclarait expressément ne constituer aucune norme Internet. Elle conserva le profil, la classe, Q112 et les trois valeurs de classe.

Son tableau indiquait « Conversion: None » pour les données. Ce mot ne signifiait pas qu’aucune interprétation n’était nécessaire. Il signifiait que le corps demeurait en ODA tandis que les paramètres et les identifiants d’enveloppe continuaient d’être mappés ou complétés.

La section sécurité ajoutait que les corps ODA pouvaient contenir des structures complexes dont les capacités étaient difficiles à déterminer. L’architecture étant extensible, de nouvelles portions de contenu pouvaient modifier la menace au fil du temps. La même section précisait qu’aucun risque propre à ODA n’était alors connu : elle justifie une inspection prudente, pas l’invention rétrospective d’un incident.

Une mention de format reste donc stable alors que le profil, les extensions, l’analyseur et la carte locale évoluent. L’état professionnel utile n’est pas « ODA pris en charge », mais « tel profil, telle classe et telles extensions ont produit ce résultat avec ces versions ».

Le document reçu devait encore être observé

L’échelle de preuves ne s’arrêtait pas au décodage. Elle commençait avec les octets, continuait par le type, le profil, la classe, l’action du relais, la capacité du lecteur et la correspondance locale. Venaient ensuite le rendu, la structure conservée, l’éditabilité, l’aller-retour et la réussite du dépôt ou de la revue.

Chaque échelon répond à une question légitime. Une empreinte contrôle l’identité du fichier. Un profil borne le contrat attendu. Une version d’adaptateur aide à expliquer une perte. Une comparaison visuelle ou structurelle mesure le résultat. Aucun de ces éléments ne mérite d’être promu au rang suivant sans observation.

Le paragraphe absent du vocabulaire général est ainsi moins une faiblesse qu’un rappel institutionnel. Le centre commun doit rester assez mince pour être appliqué par des systèmes indépendants. Le profil choisit la convention. Les extrémités assument la traduction. Le destinataire garde le pouvoir de décider si le document obtenu suffit à sa tâche.

Sources et limites

Ces sources ne mesurent ni adoption, ni qualité de produit, ni fidélité globale d’EXPRES, ni incident de sécurité, ni usage actuel.