Zusammenfassung

  • RFC 3080 ließ mehrere unabhängige Austausche eine BEEP-Sitzung teilen. Kanal null verwaltete die Sitzung; das gewählte Profil bestimmte Syntax und Semantik jedes Anwendungskanals.
  • Transportaufbau, Greeting, angebotene Fähigkeit, geöffneter Kanal, Protokollantwort und äußere Wirkung waren getrennte Belege.

Die Leitung stand, die Anwendung noch nicht

Zwei Peers können den Transport herstellen, ihre Greetings auf Kanal null verstehen und dennoch jedes angebotene Profil ablehnen. Die Leitung funktioniert, die Sitzungsverwaltung auch. Ein gemeinsames Anwendungsgespräch gibt es nicht.

Diese Grenze machte RFC 3080 im März 2001 zum Ausgangspunkt. Der Standards-Track-RFC beschrieb den BEEP core als generischen Kern für verbindungsorientierte, asynchrone Interaktionen. Mehrere Austausche durften unter einer Anwendungsidentität gleichzeitig und unabhängig laufen. Die Verbindung erhielt aber nicht automatisch einen einzigen Zweck.

Selbst die Transportabbildung stand außerhalb des Kerns. RFC 3081 legte eine BEEP-Sitzung auf eine TCP-Verbindung. TCP-Erfolg war somit nur ein Trägerbeleg, keine Profilwahl und keine Arbeitserlaubnis.

Kanal null verwaltete Räume, nicht Ergebnisse

Zu Beginn existierte nur Kanal null. Er übertrug Greetings, angebotene Profile, Start- und Schließanträge sowie die Freigabe der Sitzung.

Ein URI im Greeting war eine Ankündigung. Für eine Bindung brauchte es start mit Kanalnummer und einem oder mehreren Profilen. Der Empfänger wählte eines positiv aus oder lehnte alle ab. Erst die Antwort machte aus Nummer und URI einen Kanal mit Bedeutung.

Die Nummernregel vermied eine zentrale Vergabe. Der initiierende Peer nutzte positive ungerade Zahlen, der lauschende positive gerade. Beide konnten lokal entscheiden, ohne miteinander zu kollidieren.

Das Profil besaß die Sprache

Der Kern lieferte Austauschformen. MSG begann; RPY oder ERR beendeten eins-zu-eins; ANS brachte mehrere Antworten und NUL schloss deren Reihe. Nachrichtennummern trennten Austausche, Nutzlast-Sequenznummern liefen über alle Frames eines Kanals.

Frames verschiedener Kanäle durften sich abwechseln. Fragmente derselben Nachricht blieben auf ihrem Kanal geordnet; mehrere ANS konnten mit Antwortnummern ineinandergreifen. Das ermöglichte Parallelität, garantierte aber weder Fairness noch Abschluss.

Spätere Profile hielten die Trennung aufrecht. RFC 3195 definierte zuverlässiges syslog. RFC 4227 gab SOAP eigene Profil-URIs und einen boot/ready-Zustand. RFC 4744 unterschied NETCONF-manager/agent von BEEP-initiator/listener. Transportrolle war keine Anwendungsautorität.

Nach TLS galt die alte Erinnerung nicht

RFC 3080 trennte anfängliche Tuning-Kanäle von kontinuierlichen Datenkanälen. TLS und SASL konnten Privatsphäre und Identität verändern; jeweils nur ein Tuning-Kanal durfte aktiv sein.

Nach erfolgreichem TLS mussten zuvor gespeicherte Sitzungsinformationen verworfen werden. Ein aktiver Angreifer konnte sie verändert haben. Neue Verschlüsselung machte alte Beobachtungen nicht nachträglich vertrauenswürdig.

Authentisierung war ebenfalls keine Blankovollmacht. Jeder Kanal sollte vor einer Aufgabe die zur Identität und Vertraulichkeit passende Zugriffskontrolle anwenden.

Gemeinsamer Transport brauchte lokale Budgets

TCP regelte den Fluss pro Verbindung. RFC 3081 führte deshalb gleitende Fenster pro Kanal ein, damit ein langsamer Kanal seine Nachbarn nicht aushungerte oder blockierte. Jeder Kanal begann mit 4096 Oktetten; SEQ meldete die nächste erwartete Sequenz und den verfügbaren Raum.

TCP blieb für zuverlässige Übertragung zuständig. Das BEEP-Fenster verteilte Kapazität innerhalb der Sitzung. Unabhängigkeit erforderte eigene Zählung und eigenen Fortschritt.

Auch Portnummern haben einen Lebenszyklus

Für syslog, SOAP und NETCONF entstanden BEEP-Profile. Später gab RFC 9900 die Ports für NETCONF über BEEP und NETCONF über SOAP frei, während die Dienstnamen erhalten blieben.

Veröffentlichung bewies keine dauerhafte Verbreitung; Freigabe widerlegte nicht die Architektur. Spezifikation, Registry-Eintrag, Implementierung und Betrieb besitzen verschiedene Lebensläufe.

Der bleibende Wert von RFC 3080 liegt in der Beweisgrenze. Greeting war Anzeige. Ein angenommenes start war Bindung. RPY war Protokollantwort. Ob eine Konfiguration bestand, ein Log gespeichert oder ein Dienst verändert wurde, musste außerhalb dieser Ebene beobachtet werden.

Quellen

  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/