Résumé

  • La conformité MIXER de la RFC 2156 s’appliquait à une instance de passerelle X.400/RFC 822-MIME, et non au seul logiciel capable d’être configuré correctement.
  • Une passerelle locale pouvait entrer dans le scénario mondial lorsque des listes de diffusion ou des correspondants X.400 extérieurs élargissaient le chemin réel.
  • La preuve doit donc relier les fonctions du produit aux options actives, aux données MCGAM, à chaque conversion, au service préservé et au résultat de livraison.

Le périmètre pouvait changer sans nouvelle installation

Une démonstration commerciale montre ce que le produit peut faire. Elle ne montre pas les choix de l’instance qui recevra demain un message développé par une liste et renvoyé vers un autre domaine administratif. C’est ce déplacement du possible vers l’exécuté que la RFC 2156, publiée en janvier 1998, a rendu explicite.

Le texte décrivait deux scénarios. Dans le scénario mondial, les réseaux Internet/MIME et X.400 étaient reliés par plusieurs passerelles ; un objet pouvait franchir la frontière plusieurs fois, d’où la nécessité d’un comportement cohérent. Dans le scénario local, une passerelle raccordait une communauté fermée au réseau mondial, avec une frontière maintenue par la connectivité ou la politique d’autorisation. Une solution ressemblant à MIXER pouvait suffire localement, alors que la cartographie mondiale et d’autres détails exigeaient un effort de mise en œuvre et de déploiement.

Cette économie locale n’était pas une propriété durable. La RFC citait les passerelles fournies par un ADMD : destinées aux seuls clients, elles finissaient par traiter des chemins mondiaux à cause des listes de diffusion et des échanges avec des utilisateurs X.400 extérieurs. Le matériel restait en place ; le graphe des destinataires changeait sa fonction.

D’où la phrase centrale : la conformité à MIXER vaut pour une instanciation de passerelle, pas seulement pour une implémentation. Le binaire devait pouvoir être exploité conformément à la norme, mais cette possibilité ne décrivait pas sa configuration active.

La liste transformait une conversion en parcours

Un utilisateur X.400 pouvait écrire à une liste hébergée du côté RFC 822, être lui-même membre de cette liste, puis recevoir un message revenu à travers la frontière. Des adresses tierces et des destinataires ajoutés lors du développement créaient d’autres passages. La preuve ne pouvait donc s’arrêter à la première conversion réussie.

La RFC traitait les conversions répétées comme essentielles, notamment pour les listes. Elle cherchait la symétrie et la réversibilité afin d’éviter un double encodage inutile et de permettre à une réponse de revenir par le chemin correct. Mais elle prévenait que le service tendait vers le plus petit dénominateur commun, approximativement les services de RFC 822. Un service X.400 sans équivalent standard n’était pas présumé survivre à un trajet X.400→RFC 822→X.400.

La réversibilité d’une adresse ne garantissait donc ni la préservation de la sémantique, ni une notification intacte, ni un trace complet, ni l’action d’un destinataire. Le texte séparait aussi la récursion dans une seule passerelle du source routing à travers plusieurs passerelles. Dans le second cas, chaque opérateur pouvait posséder ses propres tables, versions et politiques de corps de message.

L’annexe de conformité décrivait l’instance

L’Appendix G interdisait la revendication de conformité si une fonction obligatoire manquait. Formats de champs, utilisation des MCGAM, cartographie du trace, accès aux trois cartographies mondiales, application de la RFC 2157 aux corps et de la RFC 2045 aux messages MIME figuraient dans la liste. La passerelle devait aussi déclarer les protocoles de transport Internet, les versions X.400 et les mécanismes d’accès aux informations mondiales. Avec SMTP, l’annexe A devenait obligatoire.

Ce sont des faits de déploiement. Un produit peut contenir le code d’accès DNS et X.500 tout en exécutant une instance reliée à une table périmée. Il peut savoir produire un trace, mais le profil observé peut ne pas le conserver.

La RFC 2157, compagnon obligatoire pour les corps, définit une fonction comme implémentée dès que le produit peut être configuré pour l’utiliser ; elle précise que le produit n’est pas tenu de rester dans cette configuration. Ainsi, même la définition de la capacité produit confirme la nécessité d’une seconde preuve au niveau de l’instance.

Cette RFC permettait en outre des choix fondés sur les capacités du destinataire, une demande de l’expéditeur, des heuristiques de contenu ou la limite du prochain saut. Deux produits capables pouvaient encapsuler, rejeter ou marquer une perte différemment. L’audit doit établir le choix effectivement exécuté pour le message.

La sortie valide ne suffisait pas

Dans le chapitre consacré à un seul passage, « supporté » avait un sens exigeant : correspondance sémantique, absence de perte significative et exécution de l’action requise. Une sortie syntaxiquement correcte qui omet un rapport attendu ne peut pas emprunter cette qualification.

Le dossier probant commence donc par le produit et ses fonctions obligatoires, puis fixe l’instance, les options, les versions et les transports. Il conserve la source et l’empreinte des MCGAM, le résultat de recherche, chaque développement de liste, les empreintes d’entrée et de sortie, la règle choisie, l’encapsulation ou la perte et le trace. L’acceptation distante, la remise en boîte, l’affichage et la lecture humaine restent des résultats séparés.

La Running-Code Primacy de Lu Heng sert ici de grille éditoriale déclarée, non d’exigence de la RFC : la norme et le produit décrivent une possibilité de compatibilité ; l’instance et le chemin montrent le fait opératoire. Minimum Initial Specification invite à maintenir chaque affirmation vérifiable à son niveau. On Reality Layers empêche enfin l’étiquette symbolique de remplacer la preuve exécutable.

La RFC 2156 ne prouvait aucun incident, aucune adoption actuelle ni la conformité d’un fournisseur nommé. Elle léguait une discipline : la question décisive n’est pas ce que le logiciel sait faire, mais ce que l’instance placée sur ce parcours a effectivement fait.

Sources