Zusammenfassung

  • RFC 9713 macht im IANA-Register der Bundle Administrative Record Types die BP-Version ausdrücklich sichtbar; ein BPv7-Verwaltungselement darf nur Einträge verwenden, deren Versionsspalte eine 7 enthält.
  • Für BPv7 sind 64384–64511 als experimentell und 64512–65535 für private Nutzung reserviert. Das verhindert Kollisionen mit zentralen Zuweisungen, schafft aber keine gemeinsame Bedeutung zwischen Organisationen.
  • Belastbare Betriebsnachweise trennen Registerzuweisung, Versionsbereich, referenzierte Spezifikation, Implementierungsfähigkeit, lokale Konvention, Empfang, Freigabe, Handlung und beobachtetes Ergebnis.

Die Abfrage braucht nun zwei Koordinaten

RFC 7116 richtete das Register für das vier Bit breite Typfeld von BPv6 ein. RFC 9171 definierte den BPv7-Verwaltungsdatensatz später als zweiteiliges CBOR-Array: zuerst ein vorzeichenloser Typcode, danach der typspezifische Inhalt. Die gemeinsame Tabelle zeigte jedoch nicht eindeutig, ob ein Eintrag zu BPv6, BPv7 oder beiden gehörte.

Dadurch wirkte eine Zahl verbindlicher, als sie war. Wert 2 bezeichnete in BPv6 ein Custody signal; BPv7 übernahm diesen Custody-Mechanismus nicht. Wert 1, der Bundle status report, gilt dagegen für beide Versionen. Die Auskunft „2: Custody signal“ konnte historisch richtig und als Verarbeitungsgrundlage für BPv7 dennoch falsch sein.

RFC 9713 fügte links die Spalte Bundle Protocol Version hinzu. Ein BPv7-Verwaltungselement muss dort die 7 finden und darf einen belegten Code nicht als generationsübergreifend behandeln. Der öffentliche Koordinationsschlüssel besteht damit aus Nummer und Protokollversion.

Die Referenz verwahrt die Semantik

Auch dieses Paar ist noch keine vollständige Anweisung. RFC 9713 legt weder die Interoperabilität von BPv6 und BPv7 beim selben Codepunkt fest noch unterstellt es eine gleiche Auslegung. Die Spezifikation jedes Typs muss dessen Verhältnis zu den BP-Versionen erklären.

Das aktuelle IANA-Register macht die Arbeitsteilung sichtbar. Eintrag 1 verweist auf RFC 5050 und RFC 9171. Hinzu kommen für BPv7 die CCSDS-Signale 13 und 14 sowie ACME Node ID Validation unter 255. Das Register verzeichnet Zuweisung und Referenz; erst RFC 9891 definiert CBOR-Strukturen, Token, Prüfungen und Verarbeitung für 255. Die Zahl ist ein Index zur semantischen Quelle, keine Kurzfassung ihres Inhalts.

Im Betrieb gehören Registerstand, Versionszelle und genaue Revision der Referenz in denselben Beleg. Fehlt diese Bindung, kann ein Parser „registriert“ melden und gleichzeitig eine veraltete Struktur, die Bedeutung einer anderen Version oder eine lokale Ersatzkonvention verwenden.

Private Bereiche koordinieren den Verzicht auf zentrale Zuweisung

RFC 9713 reserviert 64384–64511 für experimentelle und 64512–65535 für private BPv7-Nutzung. IANA wird daraus keinen öffentlichen Typ zuteilen, der einen lokal gewählten Wert unerwartet verdrängt.

RFC 8126 begrenzt diese Zusage. Private Use wird lokal definiert; IANA führt keine einzelnen Zuweisungen. Zwei Standorte dürfen denselben Wert inkompatibel verwenden. Auch Experimental Use ist keine Grundlage für allgemeine Interoperabilität. Reserviert wird ein Raum, nicht ein Wörterbuch.

Zwei Betreiber können 65000 wählen und Unterschiedliches kodieren. Übernahme, Roaming, Notkopplung oder Lieferantenwechsel können die zuvor getrennten Konventionen zusammenführen. Das erste gemeinsam übertragene Bundle entscheidet nicht, welches private Wörterbuch gilt. Dafür braucht es eine externe Vereinbarung zu Eigentümer, Geltungsbereich, Revision, Ablauf, Rückfall und Konfliktverhalten.

Zustellung und Verarbeitung bleiben getrennte Tatsachen

RFC 9713 zieht eine nützliche Fehlergrenze. Erhält ein Verwaltungselement eine fehlerhafte Dateneinheit oder einen nicht verarbeitbaren Typ, muss es den Datensatz ignorieren. Die Zustellung des umschließenden Bundles bleibt trotzdem wahr; auch andere Abläufe des Bundle Protocol Agent, etwa Statusberichte, werden nicht umgedeutet.

So löscht ein Anwendungsfehler nicht den Transporterfolg, und der Transporterfolg wird nicht zum Beweis des Verstehens. Ein sauberes Journal trennt mindestens: Bundle zugestellt; Verwaltungsdatensatz erkannt; Typcode gelesen; Versionsgeltung bestätigt; Spezifikation und lokale Konvention aufgelöst; Inhalt geparst; Herkunft und Integrität geprüft, sofern konfiguriert; Richtlinienfreigabe entschieden; Handlung versucht; Zustand verändert; Wirkung beobachtet.

„Empfangen“ kann wahr sein, obwohl alle folgenden Schritte falsch oder unbelegt sind. Das ist nicht dieselbe These wie Empfang oder Custody nach RFC 9171, sondern die Frage, welcher Bedeutung und welcher Handlung ein bereits zugestellter Datensatz tatsächlich entspricht.

Das Register koordiniert, es steuert nicht fern

RFC 9713 änderte das Verfahren Specification Required nicht und führte keine neuen Sicherheitsstrukturen ein. Die Sicherheitserwägungen von RFC 9171 bleiben bestehen. Verbessert wurden die gemeinsame Tabelle und ihre Leseregel. Vertrauen in den Absender, Sicherheit des Parsers, lokale Zustimmung und erfolgreiche Wirkung werden nicht bescheinigt.

Gerade weil es öffentliche Kollisionen verhindert und Versionsannahmen prüfbar macht, ist das Register wichtig. Seine Autorität endet jedoch bei den Angaben, die seine Zeile tatsächlich enthält.

Heng Lus Texte zu Running-Code Primacy, Minimum Initial Specification und Reality Layers dienen hier als offengelegte redaktionelle Perspektive: gemeinsame Aufzeichnungen sollten eng und lokal prüfbar bleiben; spätere Annahme gehört zu laufenden Systemen; ein symbolischer Eintrag darf kein Ausführungsergebnis beanspruchen, das er nicht enthält. Das ist Analyse, keine Aussage über Absichten der IETF.

Quellen