Zusammenfassung

  • In SDXF trägt jeder Block Kennung, Flags, eine Länge von drei Bytes und seinen Inhalt. Das Lese-Beispiel in RFC 3072 ignoriert unbekannte Kennungen und geht zum nächsten Block.
  • Diese Regel erhält den Durchlauf, nicht das Verständnis: Eine Anwendung braucht weiterhin gemeinsame Bedeutung, Konvertierungstabellen, implementierte Methoden und die Befugnis, den Wert zu verwenden.

Im März 2001 beschrieb Max Wildgrube RFC 3072 als Structured Data Exchange Format (SDXF) für den plattformübergreifenden Austausch hierarchischer Daten. Das Versprechen sollte man genau lesen. Das Dokument sagt, ein Programm könne SDXF-Daten entpacken, ohne die Bedeutung jedes Elements zu kennen. Im Lese-Beispiel verarbeitet der Code jedoch nur bekannte Block-IDs in einem switch, definiert keinen Standardfall und ruft anschließend die Funktion für den nächsten Block auf. Das unbekannte Feld wird ignoriert; die Analyse läuft weiter.

Der binäre Aufbau erklärt diese mechanische Kontinuität. Ein gewöhnlicher Block besteht aus einer von null verschiedenen zweibyteigen Kennung, einem Flag-Byte, einer dreibyteigen Inhaltslänge und dem Inhalt. Ein strukturierter Block enthält weitere Blöcke, auch rekursiv. Findet der Leser anhand der geltenden Formatregeln die nächste Grenze, kann er über einen nicht interpretierten Inhalt hinweg weiterlaufen. Er weiß, wo der Block endet, aber nicht, was dessen Kennung für eine konkrete Anwendung bedeutet.

RFC 3072 schlägt für Anwendungsprotokolle auf SDXF-Basis vor, unbekannte IDs zu ignorieren und die Reihenfolge der Blöcke nicht als bedeutsam zu behandeln. Das kann älteren Lesern helfen, Erweiterungen zu tolerieren. Es entscheidet nicht, ob eine Erweiterung für die Transaktion des Senders entbehrlich ist, die Anwendungsinterpretation verändert oder durch Weglassen eine folgenreiche Aktion ändert. Weiterlaufen ist ein klar begrenztes Kompatibilitätsverhalten, keine allgemeine Aussage über die Bedeutungslosigkeit des Feldes.

Das Format macht weitere notwendige Vereinbarungen sichtbar. RFC 3072 normiert Binärzahlen auf Big Endian, schlägt ISO 8859-1 als interne Zeichendarstellung vor, erlaubt Übersetzungstabellen und definiert daneben einen UTF-8-Datentyp. Kompression und Verschlüsselung hängen von Flags, Methodennummern und Funktionen ab. Werden beide eingesetzt, kommt Kompression zuerst; Verschlüsselung benötigt einen Schlüssel. Ein Block kann also strukturell lesbar sein, während dem Empfänger Zeichentabelle, Methode, Implementierung oder Schlüssel für seine Auswertung fehlen.

Die aktuellen SDXF-Register der IANA führen RUN-LENGTH und DEFLATE als Kompressionsmethoden sowie AES als Verschlüsselungsmethode 01. Ein Registereintrag belegt die Zuweisung, nicht die Implementierung beim Empfänger oder die korrekte Verarbeitung eines bestimmten Inhalts. RFC 3072 ist Informational und kein Internet-Standard. Die herangezogenen Quellen belegen weder Einführung noch Verbreitung; ein Formatvorschlag ist kein Produktionsbericht über Interoperabilität.

Die entscheidende Trennung betrifft die Belege: Die Länge begrenzt Bytes nach der Formatregel. Die Kennung verweist auf eine von der Anwendung definierte Bedeutung. Tabellen wandeln Zeichen um; eine Methodennummer wählt eine Operation, deren Ausführung Code und Schlüssel erfordern. Eine Berechtigungsregel entscheidet nochmals separat, ob der extrahierte Wert eine Wirkung haben darf. Running-Code Primacy dient hier als spätere analytische Linse: tatsächliches ausführbares Verhalten beobachten, nicht aus einem Dokumentnamen ableiten. Reality Layers trennt symbolische Bedeutung von überprüfbarer Wirkung.

Beides wird Wildgrube nicht zugeschrieben.

Quellen