Résumé

  • RFC 2351 ajoutait au-dessus de TCP une session MATIP chargée d’accorder le type de trafic, le multiplexage, la présentation et le périmètre des terminaux.
  • L’Open Confirm attestait une configuration de communication, non la réservation d’un siège, l’émission d’un billet ou la remise finale d’un message Type B.
  • La possibilité de répéter une requête Type A restée sans réponse révèle une ambiguïté durable : le silence ne dit pas à quel étage la preuve s’est perdue.

Dans un bureau de voyage, l’absence de réponse impose une décision avant de fournir une explication. RFC 2351 indiquait qu’une requête Type A pouvait être perdue et que l’utilisateur pouvait alors la renouveler. Il ne disait pas que la première opération n’avait produit aucun effet.

La demande a pu disparaître avant le serveur central. Elle a pu être refusée. Elle a pu modifier l’inventaire, puis perdre sa réponse sur le chemin du retour. Une nouvelle émission est donc tantôt une reprise, tantôt une répétition sans effet, tantôt une seconde tentative sur une opération déjà engagée. Ce choix ne peut être tranché par l’état de la liaison.

Le problème résolu par RFC 2351 se trouvait en amont. Des milliers de terminaux et d’applications aériennes utilisaient des protocoles antérieurs à TCP/IP. Leur remplacement immédiat était irréaliste. MATIP proposait une enveloppe commune afin que ces systèmes continuent de fonctionner sur un réseau moins coûteux et plus largement disponible.

Deux familles de trafic, une même discipline

Le Type A couvrait la conversation interactive et les échanges entre hôtes : consultation, réservation, émission de billets. Le Type B portait des messages moins pressés, mais davantage protégés, avec plusieurs destinataires et quatre niveaux de priorité. Les formats métier détaillés demeuraient du ressort des règles IATA et des accords bilatéraux.

MATIP s’insérait entre TCP et l’application aérienne. Les ports 350 et 351 séparaient les deux familles. Après l’établissement TCP, Session Open et Open Confirm fixaient le sous-type, le multiplexage, l’en-tête, la représentation des caractères et, selon le cas, la liste des unités de contrôle de terminaux. Des ensembles de paramètres distincts nécessitaient des sessions distinctes.

La fiche du RFC Editor classe ce texte comme Informational. Il ne s’agissait ni d’imposer un standard Internet à l’aviation, ni de certifier un déploiement. Le texte donnait à des systèmes hétérogènes une manière commune de décrire le canal qu’ils s’apprêtaient à utiliser.

L’accord de session reste un accord de session

Pour le Type A conversationnel, Open Confirm pouvait accepter, refuser ou accepter sous conditions. Il pouvait désigner les ASCU configurées ou rejetées. Cette réponse avait une portée exacte : elle montrait que les deux extrémités partageaient une configuration utilisable.

Elle ne contenait pas de reçu universel de réservation, de version d’inventaire, de garantie tarifaire ou d’écriture comptable de billet. Le sens du contenu restait porté par l’application. MATIP pouvait transmettre un message correctement formé sans pouvoir affirmer ce que l’application avait décidé.

Un autre détail renforce cette séparation. Lorsqu’un nouveau Session Open arrivait sur une session déjà ouverte, la configuration associée était effacée et remplacée. La connexion TCP pouvait sembler continue tandis que l’identité opérationnelle de la session changeait. Continuité de transport, continuité de session et continuité de transaction ne se déduisent pas l’une de l’autre.

Le Type B gardait la même limite. Sa poignée de main vérifiait que les systèmes s’accordaient sur les caractéristiques du trafic. Le contenu devait encore respecter le service Type B appelé. Une session acceptée ne prouvait ni la livraison à chaque destinataire, ni l’acte métier ultérieur.

La fiabilité de TCP n’est pas l’exactitude du billet

RFC 793 définit un flux d’octets fiable et ordonné entre processus. Un accusé de réception TCP renseigne ce flux. Il ne sait pas si l’application a autorisé la demande, réservé le siège ou inscrit l’émission dans ses comptes.

Après une rupture, deux incertitudes symétriques apparaissent. Les octets peuvent avoir atteint la pile distante sans avoir été validés par l’application. L’application peut aussi avoir validé l’opération avant que la réponse ne disparaisse. Une exécution métier effectivement unique suppose un identifiant durable, un état de validation et un moyen de relire cet état. Les adresses de terminal et identifiants de session de MATIP ne deviennent pas automatiquement des clés de transaction.

Le texte évoquait aussi la configuration statique, les identifiants et mots de passe, les pare-feu et IPsec optionnel. Son avertissement de sécurité précisait pourtant que le protocole ne résolvait pas suffisamment ces questions. Même un canal bien protégé ne fusionne pas intégrité du transport, admission du pair, autorisation applicative et résultat final.

Une migration réussie ne change pas le propriétaire du fait

Les sources ne permettent pas d’affirmer qu’une compagnie déterminée utilisait MATIP, que le protocole est répandu en 2026 ou qu’un incident réel a produit un doublon. Elles documentent une manière de moderniser le transport sans déplacer silencieusement l’autorité métier.

La thèse de Lu Heng sur la primauté du code opérationnel éclaire cette retenue : un signal commun vaut par ce que des systèmes indépendants peuvent réellement vérifier, non par les conséquences qu’on lui attribue. Son principe de spécification initiale minimale invite à normaliser le strict nécessaire à l’interopérabilité et à laisser les choix locaux à ceux qui en portent les effets.

RFC 2351 a donné une route IP aux anciennes conversations aériennes. La route n’a jamais détenu le registre des sièges.