Résumé

  • Lorsque reportAfter arrivait à échéance, RFC 3342 produisait un rapport transitoire puis transmettait quand même les données au relais suivant.
  • noLaterThan pouvait arrêter la livraison, tandis que returnTrip limitait le retour du rapport final : alerte, blocage, reçu et résultat applicatif restaient quatre faits.

Le point de départ est un service de datagrammes applicatifs immédiat et au mieux. Sans option, un relais indisponible pouvait conduire à une perte silencieuse. Le paquet d’options de RFC 3342 ajoutait de l’attente contrôlée et des rapports, mais sans inventer un état unique qui aurait voulu dire à la fois « lent », « arrêté », « reçu » et « réussi ».

Cette retenue est remarquable. Dans beaucoup de systèmes d’exploitation, le premier voyant rouge devient aussitôt un verdict. Une alerte fait passer un travail en échec, déclenche une nouvelle tentative ou ordonne une compensation. Ici, le protocole disait explicitement que le seuil d’observation n’affectait pas la livraison.

Un seuil qui signale sans commander

Chaque relais traitait dataTiming, d’où l’obligation de viser tous les sauts avec targetHop="all" et d’exiger la compréhension de l’option. Avant de transférer les données, le relais retranchait de reportAfter le temps consacré localement à chercher le prochain relais, établir la liaison et se préparer à l’envoi.

Si le solde atteignait zéro, le relais le fixait à zéro, appelait le service de rapport et envoyait malgré tout l’élément de données. Au dernier saut, l’absence de ok de l’extrémité pendant le même délai déclenchait également le rapport. Le statusResponse reprenait l’identifiant de transaction et associait le destinataire à un code 350, succès transitoire.

Ce code n’annulait rien. Il attestait que le délai de notification avait été franchi. Le message pouvait arriver plus tard, et cette arrivée ne rendait pas l’alerte mensongère. Inversement, l’alerte exacte ne prouvait ni la perte ni l’échec métier. Elle décrivait un intervalle consommé à un endroit du chemin.

Le délai dur changeait l’action

noLaterThan possédait une autre sémantique. Lui aussi diminuait à chaque relais selon le temps de traitement local. Mais lorsqu’il devenait nul ou négatif avant le saut suivant, les données n’étaient pas envoyées. Avec reportErrors, le service de rapport pouvait alors produire une erreur de temporisation.

Au dernier saut, le relais attendait l’acquittement de l’extrémité dans le budget restant. Son absence constituait une erreur. On voit la frontière : reportAfter disait « prévenez-moi à partir d’ici et continuez » ; noLaterThan disait « ne poursuivez pas au-delà ». Un tableau de bord qui range les deux événements sous le même statut détruit l’information de contrôle.

Même l’arrêt n’expliquait pas toute la cause. Le budget pouvait être consommé par le traitement local, une liaison lente, un relais absent, une extrémité non attachée ou de la congestion. Le fait vérifié était plus étroit : cette tentative n’avait pas franchi cette étape dans la limite restante.

Le rapport devait lui aussi être livré

Après une transmission réussie au destinataire, un returnTrip non nul demandait un rapport de dernier saut. Ce rapport n’apparaissait pas magiquement chez l’émetteur. Il repartait comme une nouvelle opération APEX, avec un dataTiming.noLaterThan égal au returnTrip initial.

La livraison principale et la livraison de sa preuve formaient donc deux trajets. Les données pouvaient arriver, le rapport pouvait être créé, puis se perdre sur le retour. À l’expiration du délai, l’émetteur pouvait présumer le rapport perdu. Il ne pouvait pas en déduire rétroactivement que les données n’étaient jamais arrivées.

Un registre honnête conserverait séparément l’acceptation initiale, le budget d’alerte restant, la création du rapport transitoire, la poursuite du message, le budget dur, le point d’arrêt ou l’acquittement, la création du rapport final, son budget de retour, sa réception et le résultat observable par l’application. Le mot « statut » ne suffit pas à cette chronologie.

File d’attente, nombre de sauts et remplacement

Avec hold4Endpoint, un relais pouvait conserver des données tant que l’extrémité destinataire n’était pas attachée. Sans borne supérieure, la file pouvait durer indéfiniment. Le texte relevait le risque de déni de service et suggérait des limites administratives, notamment un noLaterThan bref. Le stockage temporaire était une exposition à gouverner, pas une promesse d’issue.

dataHopping ajoutait de son côté un compteur proche du TTL IP afin de détecter les boucles. Il comptait les relais, non le temps. Une donnée pouvait respecter le nombre de sauts tout en épuisant son délai, ou consommer rapidement ses sauts en restant dans le budget temporel. Là encore, deux limites ne créaient pas la même preuve.

attachOverride autorisait enfin une nouvelle application à remplacer l’ancienne pour une même extrémité. La question de propriété d’une réponse tardive appartient au mécanisme de RFC 3340 et à un article distinct. Elle confirme seulement qu’un rapport temporel ne désigne pas, à lui seul, l’application qui possède encore l’action.

Ce que l’histoire permet de dire

RFC 3342 a été publié en juillet 2002 sur la voie de normalisation. Il est aujourd’hui Historic et la recherche RFC Editor ne présente aucun erratum correspondant. L’historique IETF du 29 juillet 2012 indique, avec la réserve « à la connaissance de l’IETF », qu’aucune mise en œuvre des RFC 3340 à 3343 n’avait été déployée et que leurs fonctions étaient assurées par XMPP, largement déployé selon RFC 6120 et RFC 6121.

Cette note ne prouve pas que les temporisations ont causé cette trajectoire. Elle ne fournit ni incident, ni mesure, ni jugement d’implémentation. Le texte avertissait aussi que dataTiming pouvait révéler la topologie privée ; un administrateur pouvait donc le réserver aux frontières d’un domaine. L’observabilité avait un coût et n’acquérait pas, par sa précision, un pouvoir illimité.

La leçon durable tient dans trois questions. Quel délai ne fait qu’observer ? Quel délai modifie effectivement le traitement ? Quel délai protège le retour de la preuve ? Tant que les réponses restent distinctes, une alerte peut être utile sans usurper le résultat.

Sources