Résumé
- La RFC 9171 sépare réception, acheminement, livraison locale, suppression et rapports d’état; chaque rapport porte sur l’état affirmé par le nœud qui le produit.
- BPv7 ne garantit pas à lui seul la livraison de bout en bout et la custody transfer n’est plus un état du protocole de base. Une réception ne prouve donc ni garde, ni traitement, ni autorité, ni résultat externe.
Les réseaux à connectivité intermittente obligent à prendre les verbes au sérieux. Il peut ne pas y avoir de dialogue continu, le délai peut être imprévisible et le prochain contact n’être qu’une hypothèse. Bundle Protocol Version 7 transporte une unité de données applicatives avec les informations qui peuvent la rendre exploitable lorsqu’elle atteindra une application. Dans ce cadre, « envoyé » et « terminé » ne décrivent pas une chaîne de preuve suffisante.
La RFC 9171 construit une grammaire plus exacte. Une transmission est une tentative du Bundle Protocol Agent, le BPA, de faire parvenir des copies. Un forwarding consiste à mobiliser un ou plusieurs adaptateurs de couche de convergence dans un effort soutenu pour qu’une copie soit reçue par un autre nœud. La livraison, elle, est locale : la charge utile et les métadonnées pertinentes ont été présentées à l’agent applicatif d’un nœud conformément à une inscription locale. Suppression, abandon et contraintes de rétention sont encore d’autres états.
Cette grammaire est une discipline de preuve. Un bundle acheminé n’est pas nécessairement reçu. Un bundle reçu n’est pas nécessairement livrable localement. Une charge utile livrée à l’agent applicatif n’est pas nécessairement traitée par cet agent. Et le rapport décrivant l’un de ces événements n’est pas nécessairement arrivé à celui qui doit agir. Réduire ces étapes à une seule étiquette « livré » rend le système plus rassurant en apparence et moins vérifiable en réalité.
La procédure de réception en montre immédiatement la raison. Lorsqu’un BPA reçoit un bundle venant d’un autre nœud, il ajoute une contrainte de rétention « Dispatch pending ». Si un rapport de réception a été demandé et si les rapports sont activés, il devrait produire un rapport vers l’endpoint report-to. Cela établit quelque chose de précis : ce nœud a commencé le traitement défini pour un bundle reçu.
Mais ce traitement peut ensuite aboutir à une suppression. Le BPA vérifie les CRC attachés. Un bundle mal formé ou dont le CRC ne correspond pas doit être supprimé, et les étapes restantes de réception sont sautées. Des blocs d’extension non pris en charge peuvent aussi entraîner un rapport, puis une suppression ou un retrait selon leurs contrôles. Un rapport de réception ne permet donc pas de conclure que le bundle conforme a été conservé, acheminé ou remis à une application.
L’acheminement a son propre domaine de validité. Le BPA choisit un ou plusieurs nœuds et les adaptateurs nécessaires, puis demande l’envoi. La détermination d’un acheminement réussi après les procédures d’envoi relève de l’implémentation; si elle échoue, une nouvelle tentative peut être lancée selon une configuration locale. Un rapport d’acheminement porte sur cet état. Il n’est ni un accusé de réception du nœud suivant, ni la preuve qu’un itinéraire perdurera, ni l’assurance que la destination finale a été atteinte.
À la destination, la limite est plus nette encore. La livraison locale dépend de l’inscription correspondant à l’endpoint de destination. Des fragments peuvent devoir être réassemblés; une inscription passive ou un échec propre à l’implémentation peut différer ou abandonner la livraison. Même lorsqu’un rapport de livraison est produit, la RFC précise qu’il dit seulement que la charge utile a été remise à l’agent applicatif, non que cet agent l’a traitée.
Pour un contrôle automatisé, cette phrase change tout. L’application peut valider, mettre en file, rejeter, différer, transformer ou ignorer les données selon ses propres règles. L’état BP ne révèle pas laquelle de ces actions a suivi. Il ne désigne pas non plus le titulaire d’une décision, ne prouve pas qu’une personne compétente a examiné le résultat et ne démontre pas l’exécution d’une instruction irréversible. Ces faits doivent être conservés par l’application et par le système qui porte la décision.
Les rapports d’état ne sont pas une piste d’audit omnisciente. Leur production doit être désactivée par défaut, car des demandes nombreuses peuvent produire un trafic excessif. Même lorsqu’elle est activée, la décision de produire un rapport demandé relève du BPA. L’heure éventuellement inscrite est fournie par l’horloge locale du nœud et relève de l’implémentation. Le rapport est donc une assertion circonscrite, transportée comme un autre bundle vers un endpoint report-to; ce n’est ni une chronologie mondiale ni la preuve que son lecteur attendu l’a reçue.
Le contraste historique autour de la custody est décisif. La RFC 5050 expérimentale définissait l’acceptation de custody et les custody signals. La table de la RFC 9171 réserve les drapeaux correspondants à la version 6 et son annexe A indique que la custody transfer a migré vers la spécification Bundle-in-Bundle Encapsulation. BPv7 de base conserve des états de rétention, d’acheminement et de livraison utiles, mais ne transforme pas une réception en prise de custody. Un engagement de conservation doit être nommé avec son mécanisme et ses conditions; il ne peut pas être déduit d’un bit de réception.
La RFC formule enfin la limite générale : Bundle Protocol n’assure pas lui-même la livraison de bout en bout. Des protocoles de convergence fiables peuvent réduire les pertes entre voisins; l’assurance de bout en bout exige des extensions BP et/ou des mécanismes applicatifs. Ce n’est pas une insuffisance cachée. C’est la limite honnête d’un protocole qui décrit ce qu’un BPA a fait à un instant donné sans s’attribuer les choix ultérieurs de systèmes, de personnes ou d’institutions.
Pour une direction, le bon réflexe n’est pas de mépriser un rapport de réception, mais de ne pas lui demander davantage qu’il ne sait. Il faut conserver séparément la réception, l’acheminement, la livraison locale, le traitement applicatif, l’accusé de réception, l’approbation et l’exécution. Chaque élément doit indiquer son auteur, sa règle, son destinataire, son horloge et sa condition d’échec. Des faits étroits et vrais se combinent; un feu vert qui prétend tout couvrir ne peut pas être audité pour devenir vrai après coup.
La distinction de Lu Heng entre représentation, décision locale et réalité en fonctionnement sert ici de discipline éditoriale. Un rapport BP représente un état protocolaire limité. Il faut le croire sur ce terrain, sans le promouvoir en preuve d’autorité ou de réussite. Une infrastructure devient plus résiliente lorsqu’elle sépare le fait observé de la conséquence qu’un autre acteur doit encore choisir et réaliser.
Sources
- RFC 9171 — Bundle Protocol Version 7
- RFC 5050 — Bundle Protocol Specification
- RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision
- Lu Heng — Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
