Résumé

  • Dans la révision 00 de DTPC, une fonction fournie par l’application peut retirer d’une file sortante une donnée jugée obsolète avant qu’elle ne soit agrégée et transmise.
  • Les champs décrits pour les PDU de données et d’acquittement ne consignent ni la raison de cette élision ni le lien entre l’élément supprimé et son remplaçant : cette décision doit donc avoir son propre reçu local.

Une économie de bande passante qui engage le sens

Le 27 septembre 2026, le projet individuel Delay-Tolerant Payload Conditioning a proposé une couche de service placée entre l’application et BPv7. Il n’appartient à aucun flux de publication et ne bénéficie d’aucune approbation formelle de l’IETF.

Le mécanisme répond à une contrainte concrète. Selon le texte de la révision 00, DTPC regroupe des unités de données partageant destination et profil, puis déclenche l’envoi à une limite de taille ou à l’expiration d’un temporisateur. Il ajoute aussi séquencement, acquittements, retransmissions et suppression des doublons.

L’élision intervient plus tôt. Par dtpc_open, un client devient le gestionnaire d’un Topic ID et enregistre une fonction elisionFn. À l’arrivée d’une nouvelle donnée, cette fonction peut chasser de la file un PDU ancien ou remplacé. Aucun routeur n’a perdu ce contenu : l’application a décidé qu’il ne méritait plus le trajet.

Cette distinction empêche une règle trop facile. Une nouvelle position peut rendre l’ancienne inutile, mais un nouvel ordre n’annule pas nécessairement le précédent. Une alarme, un compteur ou une écriture financière peut être cumulative. Le profil de transport ne connaît pas seul cette différence.

Le numéro de séquence ne raconte pas l’effacement

La PDU de données décrite par le projet contient type, indicateurs, Topic ID, Profile ID, numéro de séquence, longueur et charge utile. La PDU Ack expose des plages de séquences. Rien dans cette liste ne nomme le motif d’élision, la règle utilisée, l’objet antérieur ou son remplaçant.

RFC 9171 distingue réception, transfert et remise d’un bundle. Ces événements commencent trop tard pour observer une donnée éliminée avant la création du bundle. RFC 9172 protège l’intégrité ou la confidentialité des blocs transmis, non la justesse d’une suppression préalable. De même, le contexte de registre de RFC 9758 ne transforme pas la demande du numéro de service 129 en validation du protocole.

Il faut donc un reçu sobre, conservé au point de décision : identifiant de file, clé sémantique, politique et version, prédécesseur, remplaçant, heure et application responsable. Ce reçu peut contenir des empreintes plutôt que les charges utiles, afin de ne pas convertir l’audit en archive indiscrète.

La primauté du code en fonctionnement impose ensuite de vérifier séparément la file réelle, la PDU envoyée et l’état accepté à destination. La logique de spécification minimale et de décision localisée permet un format commun sans retirer à l’application son jugement. Enfin, la réflexion sur l’autorité et la croyance rappelle qu’un acquittement ne doit pas recevoir l’autorité d’une preuve qu’il ne contient pas.