Résumé

  • RFC 3340 donnait deux portées aux identifiants de transaction : ceux du canal BEEP mouraient avec lui, tandis que ceux incorporés aux données d’un service APEX pouvaient lui survivre.
  • Une nouvelle application rattachée à la même extrémité pouvait recevoir l’ancienne réponse; ni le nom stable ni l’identifiant imprévisible ne suffisaient à prouver la propriété de la requête.

Le scénario de la section 6.1.1 commence par une opération banale. Une application se rattache au maillage APEX sous une identité d’extrémité, envoie à un service des données qui contiennent un identifiant de transaction, puis se détache. Plus tard, une deuxième application se rattache sous la même identité et émet ses propres demandes. La réponse du service à la première demande peut alors parvenir à cette seconde application avec l’identifiant créé par la première.

Rien n’oblige à qualifier ce résultat d’erreur de routage. L’extrémité est joignable et l’identifiant corrèle correctement réponse et demande. Pourtant, le processus qui reçoit n’est plus celui qui a formulé l’intention. La continuité du nom masque une rupture de génération. C’est précisément la situation où un reçu techniquement exact risque de devenir une autorisation qu’il n’a jamais portée.

Le canal disparaît, la corrélation demeure

APEX reposait sur BEEP. Dans les échanges entre extrémité et relais, ou entre relais, l’identifiant de transaction n’avait de sens que durant la vie du canal BEEP. La fermeture de la connexion supprimait le canal et mettait fin au rattachement. L’identifiant d’une opération attach ne constituait donc pas un droit durable.

Les services APEX introduisaient une autre durée. L’identifiant pouvait être placé dans les données relayées et continuer à circuler pendant que le service travaillait. RFC 3340 le disait « potentiellement de longue durée ». Pour réduire les ambiguïtés, les applications devaient produire des valeurs qui paraissent imprévisibles.

Cette précaution protège la corrélation, pas la filiation. Une valeur difficile à deviner ne nomme pas le processus qui l’a générée. Elle n’atteste ni que la demande reste souhaitée, ni que le successeur a accepté les tâches en cours, ni que les pouvoirs de l’ancien processus lui ont été transférés. Le registre nécessaire comprend donc au moins l’identité logique, le pair authentifié, le canal, la génération de rattachement, le processus demandeur et le détenteur de la réponse.

Un ok avant le traitement des destinataires

La chronologie du relais renforce cette discipline. Selon la section 4.4.4.1, le relais vérifie d’abord que le client BEEP peut agir pour l’origine annoncée, puis traite les options qui s’appliquent aux données. Il renvoie ensuite ok. Le traitement des options propres à l’origine et celui de chaque destinataire viennent après.

Pour une autre zone administrative, un destinataire est déclaré traité lorsque le relais suivant a accepté les nouvelles données. Pour une extrémité locale, la politique d’accès doit autoriser l’échange, l’extrémité doit être rattachée et l’application doit renvoyer ok après son traitement propre. Ces accusés n’ont pas la même portée. Le premier ne raconte rien sur la fin du parcours; le dernier ne démontre toujours pas un résultat économique, humain ou opérationnel.

L’option statusRequest permettait d’obtenir des statusResponse ultérieures auprès des relais concernés. Avec targetHop=all, l’émetteur pouvait tracer le passage dans le maillage. Cette chaîne d’observations complétait l’accusé initial sans le transformer. Elle pouvait aussi révéler la topologie privée; RFC 3342 envisage donc de désactiver l’option ailleurs qu’aux frontières d’entrée et de sortie d’un domaine.

Ce que l’authentification ne réunissait pas

Les relais étaient découverts au moyen de DNS SRV. RFC 3340 liait ainsi l’intégrité du relayage au DNS et à son emploi par les applications, tout en ajoutant l’authentification du listener BEEP comme assurance possible. Une politique pouvait autoriser un pair authentifié à se rattacher sous une identité d’extrémité. La signature du contenu restait le moyen proposé pour une authentification de bout en bout.

Chaque mécanisme a son objet : atteindre le bon relais, connaître un pair, autoriser l’usage d’un nom, protéger le contenu. Aucun ne prouve que l’application actuellement rattachée a hérité de la requête ancienne. Même une réponse authentique et intacte peut devoir être mise en quarantaine si son nouveau destinataire ne présente pas le reçu d’adoption correspondant.

Un dossier exploitable conserve séparément l’identité d’extrémité, le pair et le canal, la génération, l’identité du workload, l’identifiant et sa méthode de création, l’empreinte de la demande, le reçu durable du service, les accusés des relais, les rapports d’état, le détachement, le rattachement suivant, l’empreinte de la réponse, la décision de consommation, l’état d’idempotence et le résultat constaté. Les clés communes relient ces pièces; elles ne les remplacent pas.

Historic, sans réécrire la causalité

RFC 3340 fut publié sur la voie de normalisation en juillet 2002, avec trois textes complémentaires : service d’accès, options et présence dans RFC 3341 à RFC 3343. L’historique Datatracker du 29 juillet 2012 explique leur reclassement en Historic. À la connaissance de l’IETF, aucune mise en œuvre n’avait été déployée, tandis que les fonctions d’APEX étaient assurées par XMPP, largement déployé et documenté dans RFC 6120 et RFC 6121.

Cette notice établit un résultat d’adoption, pas sa cause détaillée. Elle n’attribue pas l’absence de déploiement au problème des identifiants durables et ne documente aucun incident. Il serait donc faux de convertir le statut Historic en verdict technique. Le cas de succession reste utile parce qu’il décrit une limite toujours présente dans les files de travaux, rappels asynchrones et identités de service modernes.

Une réponse tardive peut être bonne, authentique et pertinente. La question supplémentaire est : à qui appartient-elle maintenant ? Si la réponse dépend d’un nom stable et d’un identifiant correspondant, la preuve est incomplète. Il faut aussi le reçu qui relie l’ancienne intention à la nouvelle génération.

Sources