Summary

  • Das co_repair-Format aus RFC 5225 schützt die gesamte rekonstruierte unkomprimierte Headerkette mit CRC-7 und die anwendbaren Kontrollfelder separat mit CRC-3. Diese Felder müssen an der gerade erfolgreichen Dekompression nicht beteiligt gewesen sein.
  • Ergebnisannahme, Fortschreiben dauerhaften Zustands und positives Feedback sind getrennte Führungsentscheidungen. Jede darf nur auf Evidenz beruhen, deren Umfang den autorisierten Gegenstand tatsächlich einschließt.

Ein grüner Vorgang mit zwei Wahrheiten

Der Dekompressor rekonstruiert den Header, CRC-7 stimmt, das Paket ist verwendbar. Dieselbe Nachricht kann jedoch Kontrollfelder transportieren, die den gemeinsamen Kontext verändern. Das sichtbare Ergebnis gilt jetzt; der veränderte Kontext beeinflusst Pakete, die noch nicht eingetroffen sind.

Deshalb enthält co_repair zusätzlich control_crc3_encoding. CRC-7 wird über die vollständige rekonstruierte unkomprimierte Headerkette berechnet. Der Kontroll-CRC-3 bezieht sich auf die Verkettung der anwendbaren Kontrollfelder. Es sind keine zwei Sicherheitsstufen desselben Urteils, sondern Prüfungen verschiedener Objekte.

RFC 5225 begründet die Trennung ausdrücklich. Aktualisierte Kontrollfelder werden nicht immer zur Dekompression des tragenden Headers benutzt und liegen dann außerhalb dessen, was CRC-7 schützt. Ohne die zweite Prüfung kann die Dekompression gelingen, positives Feedback versandt werden und der Kontrollzustand dennoch falsch fortgeschrieben sein.

Kontext ist eine Verpflichtung gegenüber späteren Paketen

ROHC spart Wiederholung, indem Kompressor und Dekompressor gemeinsamen Kontext halten. Was im Paket fehlt, muss aus diesem Zustand zuverlässig ableitbar sein. Eine Zustandsänderung ist deshalb kein nebensächlicher Schreibvorgang, sondern eine Verpflichtung für künftige Interpretation.

Im Repair Context können Pakete erfolgreich dekomprimiert worden sein, obwohl der Dekompressor dem vollständigen Kontext noch nicht vertraut. Ein Paket mit der vorgesehenen CRC-7- oder CRC-8-Prüfung kann Full Context wiederherstellen. Ein in der Sequenz spätes Paket kann erfolgreich dekomprimiert werden, ohne den Zustand zu aktualisieren, und ohne ACK bleiben. Die Erkennung von Kontextschäden ist implementierungsabhängig.

Das Protokoll bewahrt damit Unsicherheit, statt sie als Erfolg zu kaschieren. Entscheidend ist nicht nur, ob etwas funktionierte, sondern welcher Zustand daraus abgeleitet werden durfte.

Jede Prüfung braucht einen benannten Gegenstand

„CRC bestanden“ ist für sich keine vollständige Aussage. Auditierbar wird sie erst mit den Daten, die in die Berechnung eingingen. Bei co_repair spricht CRC-7 über den rekonstruierten Header, CRC-3 über die Kontrollfelder. Keiner ist eine kryptografische Signatur oder ein Beleg für Herkunft, Anwendungszustellung, Dienstqualität oder Fehlerfreiheit eines benannten Produkts.

Ein brauchbarer Nachweis nennt Prüfobjekt, vorherigen Zustand, vorgeschlagene Felder, Rechenumfang, Ergebnis und freigegebene Aktion. Ohne diese Angaben wird ein enger Befund zur allgemeinen Erlaubnis.

Der verspätete Fehler erbt das Etikett Erfolg

Ist das aktuelle Ergebnis falsch, liegen Ursache und Symptom meist nah beieinander. Ist nur der Zustandsübergang falsch, kann der Ausfall viele Pakete später auftreten. Bis dahin hat positives Feedback beide Seiten womöglich darin bestärkt, von einer falschen gemeinsamen Voraussetzung aus weiterzuarbeiten.

Die Untersuchung beginnt beim sichtbaren Fehler und übersieht den früheren, als erfolgreich archivierten Vorgang. Detaildaten können gelöscht, Abweichungen durch Wiederholungen vertieft und abgeleitete Zustände von einem Code-Rollback unberührt geblieben sein.

Gefordert ist daher kausale Nachvollziehbarkeit: Welche Evidenz erlaubte die aktuelle Ausgabe, welche andere Evidenz den Zustandswechsel, und wer genehmigte das Weiterlaufen?

Annahme, Mutation und Bestätigung entkoppeln

Für eine Operation mit sichtbarer Ausgabe und verborgenem Zustand sind drei Antworten möglich. Darf die Ausgabe genutzt werden? Darf der dauerhafte Zustand fortschreiten? Darf positives Feedback gesendet werden?

Ein Ergebnis kann brauchbar sein, während begleitendes Lernen, Cache-, Richtlinien- oder Kontrollzustandsupdate abgelehnt wird. Ein intern konsistentes Update beweist umgekehrt kein Nutzerergebnis. Ein gemeinsames Erfolgsbit macht Automatisierung einfacher, aber Verantwortung undeutlich.

Grenzen der Aussage

RFC 5225 dokumentiert keinen Fehler eines bestimmten Endgeräts, Modems, Mobilfunknetzes, Anbieters oder einer Implementierung. Es enthält keine aktuelle Verbreitungszahl, keinen Vorfall, keinen realen Paketmitschnitt und kein Qualitätsresultat. Das IANA-Register belegt Kennungen, nicht Einsatz.

Auch beweist die zusätzliche Prüfung nicht, dass jedes Reparaturpaket einen Fehler trägt. Sie zeigt, dass die erste Prüfung einen anderen Gegenstand hat. Eine entworfene Schutzmaßnahme ist kein Ereignisbericht.

Einen zweiteiligen Erfolgsbeleg führen

Der Ausgabebeleg hält Eingabe, Rekonstruktion, exakten Prüfumfang, Ergebnis und Zustellgrenze fest. Der Übergangsbeleg hält die Kennung des alten Zustands, geänderte Felder, unabhängige Prüfung, angenommene oder verworfene Mutation, Feedback, neue Zustandskennung und den verantwortlichen Entscheider fest.

Auch erfolgreiche Ausgabe mit verworfenem Update, gültiges Update ohne Zustellbeleg, verspätete Eingabe ohne Zustandsfortschritt, zurückgehaltenes ACK, angeforderte Reparatur und wiederhergestellter Kontext gehören in die Akte. Sie definieren, wo Erfolg endet.

Lu Hengs wirklichkeitsorientierter Maßstab verlangt laufende Evidenz und zuordenbare Verantwortung. Ein Protokoll- oder Institutionsname kann die Entscheidung nicht tragen, heutige Evidenz zur Grundlage des morgigen Zustands zu machen.

Sources

Ergänzende Standardnachweise

  1. RFC 5225 als Klartext
  2. Informationsseite zu RFC 5225
  3. Datatracker-Eintrag zu RFC 5225
  4. Historie von RFC 5225
  5. Errata zu RFC 5225
  6. Inline-Errata zu RFC 5225