Zusammenfassung

  • Benutzerdefinierte Subobjekte in USER_ERROR_SPEC folgen einem gemeinsamen TLV-Rahmen, doch Type, Format und Bedeutung des Werts werden im jeweiligen Enterprise- und Sub-Org-Namensraum festgelegt.
  • Sichere strukturelle Verarbeitung beweist weder semantisches Verständnis noch die Berechtigung, eine betriebliche Aktion auszulösen.

Ein generischer Parser liest Type und Length, prüft mindestens vier Byte sowie das Vierer-Raster und springt exakt zum nächsten Subobjekt. Die Nachricht bleibt intakt. Im Protokollstapel tritt kein Fehler auf. Trotzdem weiß der Parser nicht, ob der Wert eine Ressource, eine Testphase oder eine herstellerspezifische Bedingung bezeichnet.

Das ist kein Mangel des Formats. Es ist die beabsichtigte Grenze von RFC 5284. Die Spezifikation schafft einen transportfähigen Container für benutzerdefinierte RSVP-Fehler. Sie standardisiert, wie unbekannte Daten abgegrenzt und erhalten werden. Sie überträgt der IETF oder IANA nicht die Bedeutung jedes privaten Feldes.

Diese Unterscheidung ist für Automatisierung entscheidend. Ein syntaktisch gültiges Objekt darf sicher protokolliert oder weitergeleitet werden. Erst ein passender, versionierter Namensraum kann es interpretieren. Danach entscheidet eine lokale Richtlinie, ob eine Handlung zulässig ist. Und erst eine unabhängige Beobachtung kann zeigen, ob diese Handlung die Ausgangslage verändert hat.

Der Standardrahmen bleibt obligatorisch

PathErr und ResvErr benötigen nach dem Basis-RSVP ein ERROR_SPEC; RSVP-TE verlangt es auch für Notify. RFC 5284 fügt USER_ERROR_SPEC hinzu, statt den vorhandenen Fehlerrahmen zu ersetzen.

Passt ein bestehender Fehlercode, kann das private Objekt zusätzliche Einzelheiten tragen. Passt keiner, dient Error Code 33, User Error Spec, als Verweis auf das Begleitobjekt; Subcode 0 bezeichnet weitere Details darin. Code 33 ohne USER_ERROR_SPEC macht die Nachricht fehlerhaft.

Auch der Nachrichtentyp gehört zur Gültigkeit. Das Objekt darf in PathErr, ResvErr oder Notify auftreten. Auf anderen Nachrichten muss es als fehlerhaft behandelt werden. ResvConf enthält zwar ein ERROR_SPEC, verwendet dessen Codes und Werte aber nicht in der für diese Erweiterung erforderlichen Weise.

Der Empfänger erhält somit zwei prüfbare Schichten. Die Standardschicht bewahrt den RSVP-Kontext. Die private Schicht liefert Namensraum und Detailwert. Wer nur eine Schicht speichert, kann die andere später nicht seriös rekonstruieren.

Enterprise Number und Sub Org sind Teil der Identität

USER_ERROR_SPEC beginnt mit einer 32-Bit Private Enterprise Number aus dem IANA-Register. Ein 8-Bit-Feld Sub Org kann innerhalb einer Organisation getrennte Werteräume schaffen, etwa für parallel arbeitende Teams; ohne diesen Bedarf soll es null sein. Danach folgt der 16-Bit User Error Value.

Eine nackte 31 ist deshalb kein globaler Fehlercode. Organisation A kann 31 anders definieren als Organisation B. Zwei Unterorganisationen desselben Unternehmens können ebenfalls verschiedene Bedeutungen verwenden. Erst das vollständige Tripel benennt den privaten Schlüssel.

Die IANA-Zuteilung macht den oberen Namensraum eindeutig. Sie beglaubigt keine konkrete Nachricht, veröffentlicht nicht automatisch alle darunterliegenden Wörterbücher und erteilt keine Handlungsbefugnis. RSVP-Nachrichtenschutz, Wörterbuchauswahl und lokale Autorisierung bleiben getrennte Prüfungen.

Hinzu kommt die Version. Ein privates Wörterbuch kann sich mit Softwareständen ändern. Ein belastbarer Beleg speichert Originalbytes, Tripel, angewandte Wörterbuchversion, interpretierende Komponente und Zeitpunkt. Andernfalls liest eine spätere Analyse alte Werte mit neuer Semantik.

Gemeinsame Grammatik, private Typen

Jedes benutzerdefinierte Subobjekt hat einen 8-Bit-Type und eine 8-Bit-Length. Die Länge umfasst beide Felder, beträgt mindestens vier Byte und ist durch vier teilbar. Dadurch kann eine Implementierung die Sequenz prüfen und einen unbekannten Eintrag überspringen, ohne den Rest zu verlieren.

Die Nummer des Typs und der Inhalt des Werts werden jedoch von der im übergeordneten Objekt genannten Organisation beziehungsweise Unterorganisation bestimmt. Ein allgemeiner Decoder kann die Hülle korrekt behandeln und den Inhalt dennoch völlig missverstehen, wenn er eine fremde Definition annimmt.

Ein guter Datenpfad kennzeichnet diese Zwischenlage ausdrücklich: strukturell gültig, semantisch unbekannt. Er verwirft das Objekt nicht und erfindet keine Standardbedeutung. Später kann ein genehmigtes Wörterbuch die Interpretation ergänzen, ohne die ursprünglichen Bytes umzuschreiben.

Die Grenze eignet sich auch für Risikoabstufungen. Neue Typen dürfen zunächst nur beobachtet werden. Nach Dokumentations- und Herkunftsprüfung kann ein Teil davon in Analysen einfließen. Automatische Aktionen erhalten eine nochmals engere Freigabe. Syntaxakzeptanz wird nicht zum Hintereingang für Befehlsgewalt.

Class 194 hält die Hülle auf dem Weg

Das Hauptobjekt verwendet Class 194 und C-Type 1. Die Klasse liegt im RSVP-Bereich 192–247, dessen unbekannte Objekte von Implementierungen unverändert weitergeleitet werden. Ein alter Knoten kann den privaten Inhalt daher erhalten, ohne seinen Typenkatalog zu erweitern.

Diese Eigenschaft beweist nur Transportkontinuität. Der Knoten muss weder Enterprise Number noch Wert verstehen, weder Text anzeigen noch eine Aktion ausführen. Ein am Ziel vollständig angekommenes Objekt kann eine Reihe semantisch blinder Zwischenstationen durchlaufen haben.

Auch Wiederholungen werden begrenzt. Zusätzliche USER_ERROR_SPEC-Vorkommen sollen ignoriert und beim Weiterleiten unverändert erhalten werden. Mehrere Kopien sind kein Quorum und keine standardisierte Schwereangabe. Sie können als Formanomalie erfasst werden, aber ihre operative Wirkung darf nicht einfach multipliziert werden.

So entsteht echte schrittweise Kompatibilität: Transport kann zuerst funktionieren, Protokollierung später folgen, Interpretation auf ausgewählten Empfängern beginnen und eine Aktion erst nach eigener Freigabe entstehen. Kein Schritt behauptet rückwirkend, die vorherigen hätten bereits dieselbe Bedeutung geteilt.

Der Beschreibungstext ist bewusst nachrangig

Die Error Description nutzt UTF-8/Net-Unicode und wird mit Nullbytes auf ein Vielfaches von vier aufgefüllt; ihre Längenangabe schließt das Padding aus, null ist zulässig. Wenn praktikabel, empfiehlt RFC 5284 eine einzelne Zeile druckbaren US-ASCII, damit mehr Empfänger sie problemlos anzeigen können.

Weil nicht jede Implementierung jeden Zeichensatz anzeigen kann, soll der Text nur ergänzen. Betriebsnotwendige Information gehört in den numerischen Wert. Systeme ohne UTF-8-Fähigkeit sollen nach RFC 5137 escapen.

Damit taugt die Beschreibung nicht als heimliche Programmierschnittstelle. Sprache, Zeichensetzung, Escaping und Formulierung können wechseln. Maschinen sollten das versionierte Tripel auswerten; Menschen erhalten den erklärenden Text.

Die Darstellung ist zugleich eine Sicherheitsgrenze. Protokollierte Zeichenketten können Steuerzeichen oder Überlängen enthalten. Originaldaten sollten beweissicher erhalten bleiben, während Bedienoberflächen eine bereinigte Repräsentation nutzen. Eine bereinigte Ansicht ersetzt nicht das Original, und Originaltreue rechtfertigt keine ungefilterte Terminalausgabe.

Interpretation, Handlung und Wirkung brauchen eigene Belege

RFC 5284 empfiehlt, mindestens Enterprise Number, Suborganisation, Wert und Beschreibung zu protokollieren. Eine Implementierung, die den Inhalt interpretieren kann, soll weitere Maßnahmen anhand des gemeldeten Fehlers ergreifen. Zwischen diesen beiden Sätzen liegen mehrere Kontrollentscheidungen.

Zunächst muss die Nachricht gültig sein. Danach werden Objekt und Namensraum gespeichert. Ein benanntes Wörterbuch erzeugt eine Interpretation. Eine Richtlinie entscheidet über eine Maßnahme. Ein Aktor versucht sie. Ein unabhängiger Sensor beobachtet die technische Bedingung, und eine weitere Messung kann die Dienstwirkung bestätigen.

Jeder Übergang kann scheitern, ohne den vorherigen zu leugnen. Ein korrekt verstandener Fehler kann aus Sicherheitsgründen ohne Aktion bleiben. Ein erfolgreich angenommener Befehl kann wirkungslos sein. Eine technische Änderung kann das Nutzerergebnis verfehlen.

Ein einziges Feld bearbeitet zerstört diese Diagnosefähigkeit. Ein Beleggraph mit Akteur, Eingabe, Richtlinienversion, Zeit und Ergebnis macht sichtbar, wo die Kette endet. Das private Objekt bleibt ein Informationsangebot, kein automatisch importierter Herrschaftsanspruch.