Résumé

  • RFC 3080 permettait à plusieurs échanges indépendants de partager une session BEEP. Le canal zéro administrait les voies ; seul le profil accepté définissait le langage et le sens d’un canal applicatif.
  • Une connexion ouverte, un message d’accueil valide, une capacité annoncée, un canal créé et un résultat réel constituaient cinq constats distincts.

Un fil disponible sans application commune

Le cas limite est simple. Deux pairs établissent leur transport, échangent correctement leurs messages d’accueil sur le canal zéro, puis refusent tous les profils proposés pour le premier canal utile. La connexion fonctionne. La gestion de session fonctionne. Pourtant, aucune application n’a commencé à parler.

Publié en mars 2001 dans la filière normative, RFC 3080 définissait le noyau de BEEP, un cadre pour des interactions asynchrones orientées connexion. Son objet n’était pas d’attribuer une application entière à une socket. Il organisait plusieurs échanges simultanés et indépendants sous une même identité applicative.

Le transport restait un contrat séparé. RFC 3081 a décrit le placement d’une session BEEP sur une seule connexion TCP. Cette connexion attestait donc le support, pas la conversation. Il fallait encore qu’une capacité soit annoncée, proposée puis acceptée.

Le canal zéro n’exécutait pas le métier

Au démarrage, seul le canal zéro existait. Il portait le profil de gestion : accueil, liste des profils disponibles, création et fermeture des canaux, libération finale de la session.

L’accueil disait ce qu’un pair pouvait servir. Il ne liait aucun profil à un canal. La nuance est importante : une capacité publiée n’est pas une décision. De même, les deux pairs émettaient leur accueil indépendamment ; l’ordre apparent d’un exemple n’imposait pas une hiérarchie cachée.

La création passait par start. Un pair proposait un numéro et un ou plusieurs URI de profil. Le destinataire en choisissait un dans une réponse positive, ou refusait l’ensemble. Le véritable engagement se trouvait là : profil choisi, numéro donné, pair donné, session donnée.

La répartition des numéros évitait une autorité centrale. L’initiateur utilisait les nombres impairs, l’écouteur les nombres pairs. Chacun pouvait ouvrir une voie sans collision. La règle commune restait minimale et vérifiable localement.

Une voie ne suffisait pas à donner du sens

Le profil définissait la syntaxe et la sémantique. Le noyau offrait des formes d’échange : MSG pour commencer, RPY ou ERR pour une réponse unique, ANS puis NUL pour plusieurs réponses. Les numéros de message organisaient les échanges ; les numéros de séquence comptaient les octets de charge sur le canal.

Des trames de canaux différents pouvaient s’entrelacer. En revanche, les fragments d’un même message restaient ordonnés sur leur canal, sauf entrelacement contrôlé de plusieurs réponses ANS. Cette simultanéité n’était ni une garantie d’équité ni une preuve de terminaison. Elle indiquait seulement quelles progressions pouvaient coexister sans perdre leur identité.

Les profils ultérieurs montrent le partage des responsabilités. RFC 3195 a donné à syslog ses règles de livraison fiable. RFC 4227 a ajouté à SOAP ses URI et son passage de l’amorçage à l’état prêt. RFC 4744 a placé NETCONF sur BEEP en maintenant la différence entre initiateur/écouteur et gestionnaire/agent. Le cadre transportait ; le profil expliquait.

La sécurité obligeait à recommencer les preuves

RFC 3080 séparait les canaux de réglage initial des canaux continus. TLS ou SASL pouvaient modifier l’identité et la confidentialité avant les échanges durables, et un seul canal de réglage devait être actif à la fois.

Après une négociation TLS réussie, les informations mises en cache avant la protection devaient être abandonnées : un intermédiaire actif aurait pu les modifier. Le chiffrement nouveau ne blanchissait pas l’ancien état. Il fallait obtenir un nouvel accueil et reconstruire la confiance dans le nouvel environnement.

L’identité ne valait pas non plus autorisation générale. Chaque canal devait appliquer le contrôle d’accès adapté à l’identité authentifiée et au niveau de confidentialité. Connaître le pair n’obligeait ni à accepter son profil ni à exécuter son opération.

Une connexion partagée devait partager sa capacité

RFC 3081 révélait la contrepartie matérielle du modèle. TCP régulait le flux par connexion ; BEEP avait besoin de fenêtres par canal pour éviter qu’un lecteur lent ou gourmand ne bloque les autres. Chaque canal commençait avec 4096 octets et pouvait élargir son autorisation par une trame SEQ.

Ce mécanisme ne réparait pas les pertes : TCP s’en chargeait déjà. Il attribuait la capacité disponible à l’intérieur de la session. L’indépendance logique demandait donc une comptabilité opérationnelle ; un simple numéro de canal n’aurait pas suffi.

Le temps n’a pas confondu spécification et adoption

Syslog, SOAP et NETCONF ont chacun obtenu un profil. Plus tard, RFC 9900 a libéré les ports de NETCONF sur BEEP et de NETCONF sur SOAP tout en conservant les noms de service.

Ce retrait ne prouve pas que l’architecture était fausse, pas plus que la publication originale ne prouvait son adoption. Il fournit une autre leçon de couches : le texte normatif, le nom de registre, le port, le logiciel déployé et l’usage courant ont leur propre chronologie.

La contribution historique de RFC 3080 tient à cette discipline. Une réponse positive sur le canal zéro prouvait une liaison de profil. Elle ne prouvait pas l’autorisation métier, la persistance d’une configuration, l’écriture d’un journal ou l’effet attendu par l’utilisateur.

Sources

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/