Résumé

  • RFC 2126 a gardé TPKT version 3 pour protéger la base RFC 1006, mais ce numéro commun ne prouvait plus l’accord sur Class 0, Class 2 ou les options de données accélérées.
  • Une confirmation bien formée, un second canal négocié ou un motif de déconnexion « normal » restaient des preuves partielles : acceptation, ordre et livraison exigeaient leurs propres reçus.

Le compromis historique de RFC 2126 tient dans une absence de changement. En mars 1997, le document a étendu le transport ISO sur TCP à IPv4 et IPv6, raffiné Class 0 et ajouté Class 2. Il voulait élargir le service sans exclure les implémentations RFC 1006 qui exigeaient déjà TPKT version 3.

Le numéro fut donc conservé. Ce choix protégeait l’interopérabilité de l’enveloppe ; il réduisait en même temps la force probante du numéro. Une version identique ne signifiait plus un ensemble identique de capacités.

La confirmation pouvait être correcte et inacceptable

RFC 2126 reconnaissait que certaines anciennes implémentations RFC 1006 ne savaient pas négocier la classe. Un initiateur pouvait envoyer un Connect Request pour Class 2 sans classe alternative. Un ancien pair pouvait néanmoins répondre par un Connect Confirm Class 0. Le TPDU était lisible, TCP fonctionnait, et la réponse devait être rejetée selon ISO 8073.

Quatre faits se séparaient alors. La version indiquait une enveloppe compatible. Le CR déclarait la préférence de l’initiateur. Le CC déclarait le choix du répondant. La décision locale disait si ce choix satisfaisait la demande. Un tableau de bord qui résumait tout en « connexion établie » supprimait le désaccord essentiel.

Le champ réservé de TPKT suivait la même discipline. RFC 2126 lui attribuait une valeur, mais demandait de ne pas agir sur une valeur reçue et de l’ignorer pour l’interopérabilité RFC 1006. Ce champ ne devenait pas un canal implicite de capacité.

Deux canaux ne donnaient pas automatiquement un ordre

Class 2 pouvait transporter les données accélérées dans le canal normal. Les pairs pouvaient aussi négocier une procédure Forward ou Reverse afin de créer une connexion TCP distincte. Cette seconde connexion empêchait un canal normal occupé de bloquer le trafic accéléré. Elle devait relier la même paire d’hôtes, appartenir à une seule Transport Connection et fermer avec elle.

Cette liaison répondait à une question de périmètre, pas à toutes les questions de service. Elle ne disait pas quand le second canal serait ouvert. RFC 2126 laissait ce moment au choix de l’implémentation pour la procédure Forward. Elle ne prouvait pas non plus l’ordre entre les deux flux.

Le texte distinguait expressément indépendance et synchronisation. Forward ou Reverse fournissait l’indépendance. Expedited Data Acknowledgement ou Non-blocking Expedited Data pouvait fournir la discipline nécessaire à la synchronisation. L’indépendance sans synchronisation assouplissait la définition ISO du service et n’était pas conforme à ISO 8072.

Le détail est historiquement précieux : ajouter un chemin ne crée pas par magie un service ordonné. La négociation autorise une possibilité ; l’ouverture du socket, son rattachement, le mécanisme d’ordre et la livraison sont des événements différents.

Le même motif « normal » cachait deux fins

Class 0 liait la déconnexion du transport à la fermeture TCP : elle était disruptive. Class 2 ajoutait une déconnexion explicite et deux modalités. Dans les deux cas, DR et DC étaient échangés.

Avec Disruptive Disconnect, les TPDUs encore à la source n’avaient pas à être envoyés avant la fermeture. Le motif DR était 80 hexadécimal, normal. Avec Non-Disruptive Disconnect, chaque TPDU déjà remis au fournisseur local devait parvenir à l’utilisateur de transport distant. Le motif restait 80, mais Additional Information 80 portait la différence.

Le mot « normal » ne suffisait donc pas. Il fallait connaître le mode et la frontière de garde. Remettre un TPDU au fournisseur local créait une obligation ; cela ne constituait pas encore un reçu de livraison distante.

Le registre ne prouvait pas le déploiement

RFC 2126 réservait le port TCP 102 sans l’imposer à toutes les connexions. Le registre IANA conserve iso-tsap sur 102 et décrit Class 0. Il prouve une coordination de numéro, pas un service actif, une classe négociée ou une application réussie.

La section sécurité refusait aussi l’exagération : aucune question nouvelle n’était traitée, et le protocole n’était ni plus ni moins sûr que TCP et ISO 8073. Une version, un CC ou deux sockets ne prouvaient ni identité, ni autorisation, ni confidentialité.

Les essais de Lu Heng offrent ici une grille déclarée. La primauté du code en fonctionnement limite l’affirmation à l’état observable ; la spécification initiale minimale laisse les décisions futures là où elles peuvent encore varier ; les couches de réalité empêchent de confondre un symbole avec son résultat exécutable.

RFC 2126 n’a pas échoué en conservant la version 3. Il a réussi à préserver une base installée, à condition de payer la dette par de meilleurs reçus : version, classe demandée, classe choisie, acceptation, canal secondaire, synchronisation, garde locale et livraison distante.

Sources