Zusammenfassung

  • Ein unbekanntes Erweiterungselement kann vollständig wohlgeformtes XML sein; erst der Protokollvertrag bestimmt Ignorieren, Bewahren, Weiterleiten, Ablehnen oder Verstehen-Müssen.
  • Der belastbare Nachweis trennt empfangene Bytes, Parserkonfiguration, Infoset, Validierung, Namespace-Dispatch, Signaturumfang, Autorisierung und tatsächliche Wirkung.

Der ältere Empfänger verstand den Hauptteil der Nachricht. Das zusätzliche Element kannte er nicht. Er entfernte es, serialisierte den Rest neu und leitete die Nachricht weiter.

Jeder Schritt konnte gültiges XML erzeugen. Trotzdem hatte das Zwischenstück möglicherweise die Bedingung gelöscht, unter der die Operation überhaupt ausgeführt werden durfte. Der Fehler lag nicht in der Grammatik, sondern in einer fehlenden Erweiterungsregel.

RFC 3470 erschien im Januar 2003 als Best Current Practice 70. Es erklärt XML nicht zum bevorzugten Format aller IETF-Protokolle. Es richtet sich an Entwürfe, die XML bereits gewählt haben, und zwingt sie, die Politik jenseits der Syntax offenzulegen.

Wohlgeformt bedeutet lesbar, nicht zulässig

Ein wohlgeformtes Dokument erfüllt die grundlegenden XML-Regeln. Ist es nicht wohlgeformt, darf ein Protokollteilnehmer laut RFC 3470 nicht einfach die verständlichen Fragmente auswerten. Wiederholung oder Abbruch können sinnvoll sein; Teilinterpretation erzeugt divergierenden Zustand.

Aus der konkreten Syntax erzeugt der Parser ein XML Information Set. Dabei verarbeitet er Zeichenkodierung, Zeilenenden, Entitäten, Namespaces und Normalisierung. Der Anwendungsbaum ist daher kein unverändertes Abbild der empfangenen Oktette.

Der erste Beleg bewahrt Byte-Hash, Transport, Medientyp, Zeitpunkt und Kodierung. Der zweite nennt Parser, Version, Konfiguration, externe Zugriffsregeln und das Wohlgeformtheitsurteil. Erst danach folgt das Infoset.

Eine XML-Deklaration sollte stets akzeptiert werden. Erlaubt das Protokoll andere Kodierungen als UTF-8 und UTF-16, wird sie zur nötigen Koordinate.

Erweiterbarkeit braucht ein Verb

„Das Protokoll ist erweiterbar“ sagt nicht, was ein Empfänger tun soll. Eine brauchbare Regel benötigt ein Verb für jedes unbekannte Konstrukt: ignorieren, bewahren, unverändert weiterleiten, ablehnen oder als zwingend verständlich markieren.

Ohne solche Regeln entscheiden Bibliotheken und Gateways zufällig. Ein Parser verwirft fremde Knoten, ein anderer behält sie, ein dritter stoppt. Alle können XML-konform sein und dennoch nicht miteinander arbeiten.

Besonders kritisch ist ein Vermittler. Wenn er unbekannte Elemente entfernt und neu serialisiert, kann die Endstelle nicht erkennen, dass ihr eine Bedingung fehlte. Deshalb müssen Weiterleitungs- und Erhaltungsregeln genauso spezifiziert werden wie lokale Verarbeitung.

Verarbeitungsanweisungen und Kommentare eignen sich nicht als verborgener Erweiterungskanal. Normale Protokollverarbeitung soll sie ignorieren können, ohne normative Bedeutung zu verlieren.

Der Namespace benennt das Vokabular

XML-Namespaces trennen Namensräume. Ihre URI-förmigen Namen sind Bezeichner und nicht automatisch abrufbare Regelwerke. Eine Domain im Namen beweist auch keine institutionelle Handlungsvollmacht.

Der Standard-Namespace gilt für unpräfixierte Elemente, nicht für unpräfixierte Attribute. Wer aus der visuellen Verschachtelung dieselbe Zugehörigkeit ableitet, kann ein lokales Attribut als autoritative Protokollanweisung lesen.

Ein Dispatch-Beleg enthält daher den expandierten Namen, die erkannte Version, die gewählte Erweiterungsregel und den Handler. Präfixe allein reichen nicht, weil sie beliebig umbenannt werden können.

Authentifizierung und Autorisierung bleiben getrennt. Ein bekanntes Vokabular identifiziert weder den Absender noch sein Recht auf eine Operation.

Ein Schema kann die Erweiterung beschreiben, nicht ihre Wirkung beweisen

DTD, XML Schema und andere Formalismen drücken verschiedene Strukturregeln aus. RFC 3470 stellt klar, dass zusätzliche syntaktische und semantische Bedingungen zwangsläufig in Prosa und Anwendungscode bleiben.

Die Validierung muss Profil, Version, Quelle und Optionen nennen. Ein Schema kann Standardattribute einfügen, die nie übertragen wurden. Dann sehen Paketmitschnitt und Anwendung unterschiedliche Daten. Diese versteckte Ergänzung erschwert Signaturen und forensische Vergleiche, weshalb das RFC davon abrät.

Ein Typ kann korrekt und der Wert trotzdem falsch, veraltet oder unzulässig sein. Eine validierte Erweiterung ist noch keine autorisierte Erweiterung und noch kein erfolgreicher Zustandswechsel.

Der Beleg muss außerdem zeigen, welche Schema-Version das unbekannte Element bekannt gemacht hat. Sonst erscheint ein Versionswechsel fälschlich als Änderung der Nachricht.

Externe Abhängigkeiten verlagern die Protokollgrenze

Externe Entitäten, entfernte Schemas und relative Verweise können Daten einführen, die nicht in der Nachricht standen. Der Parser kann dafür Netzwerkzugriffe aus seiner eigenen, möglicherweise privilegierten Umgebung auslösen.

RFC 3470 empfiehlt, Entitätsdeklarationen in Protokollen zu vermeiden und bei unvertrauenswürdigem XML keinen beliebigen externen Zugriff zuzulassen. Die fünf vordefinierten Entitäten und numerische Zeichenreferenzen bleiben lokal und sollen unterstützt werden.

Bei xml:base muss das Protokoll das Verhältnis zur Basis des Transports oder Containers festlegen. Unterschiedliche Priorität führt denselben relativen Verweis zu unterschiedlichen Objekten.

Für Reproduzierbarkeit werden Richtlinie, aufgelöste URIs und exakte Inhalte oder der Nachweis gesperrten Zugriffs gespeichert. Ein späterer Abruf derselben Adresse ist kein Replay.

Signaturen übernehmen keine Erweiterungspolitik

Canonical XML nach RFC 3076 erzeugt eine reproduzierbare Serialisierung eines Knotensatzes. XML Signature nach RFC 3275 definiert Referenzen und Transformationen. Eine erfolgreiche Prüfung gilt nur für diesen Umfang.

Wird eine Erweiterung vor der Signatur entfernt oder liegt sie außerhalb der Referenz, sagt die gültige Signatur nichts über ihren Inhalt. Liest die Anwendung zusätzlich einen ungeschützten Knoten, ist auch dieser Entscheidungsteil nicht gedeckt.

Der kryptografische Beleg nennt Referenzen, Auflösung, Transformationen, Kanonisierung, Schlüssel und Identität. Danach folgt ein Vergleich mit den tatsächlich genutzten Daten.

Eine authentische Identität kann weiterhin unbefugt handeln. Semantik, Autorisierung, vorheriger Zustand, Commit und Ergebnis brauchen eigene Belege.

Whitespace und Attributreihenfolge folgen nicht dem Bildschirm

Whitespace kann Zeicheninhalt sein, wenn das Protokoll keine andere Behandlung festlegt. Pretty-Printing darf daher Werte oder Signaturinput verändern.

Die Reihenfolge von Attributen hat dagegen keine XML-Bedeutung; Attributwerte können normalisiert werden. Wer die Ausgabe des eigenen Serialisierers zur einzigen zulässigen Form erklärt, schafft ein proprietäres Subset.

Das Protokoll muss Whitespace, gemischten Inhalt, Elementreihenfolge, Attribute und Erhaltung unbekannter Knoten ausdrücklich regeln. Sichtbare Ähnlichkeit ist kein Interoperabilitätsbeleg.

Der Parser benötigt harte Ressourcenregeln

XML bringt keine eingebaute Vertraulichkeit, Integrität, Authentifizierung oder Autorisierung mit. Parsercode verarbeitet fremd gesteuerte Tiefe, Länge, Entitäten und Verweise. Ressourcenverbrauch und Implementierungsfehler bleiben eigene Risiken.

Größen-, Tiefen-, Expansions-, Zeit-, Speicher- und Netzwerkgrenzen gehören in die Betriebsbelege. Auch syntaktisch korrektes XML kann unzulässige Arbeit verlangen.

RFC 8996 aktualisierte später den Transportkontext, indem TLS 1.0 und 1.1 verworfen wurden. Ein moderner Kanal entscheidet dennoch nicht, ob eine Erweiterung verstanden werden musste.

Die Belegkette für eine unbekannte Erweiterung

Bewahre Oktette und Kodierung, Parser und Konfiguration, Wohlgeformtheit und vollständiges Fehlerverhalten. Erfasse Entitäten, Basis, externe Ressourcen und Infoset. Benenne Schema und Validierung.

Protokolliere expandierte Namen, Erweiterungsentscheidung und jede Transformation. Danach folgen Kanonisierung, Signaturreferenzen und authentifizierte Identität. Semantische Prüfung, Autorisierung, Ausgangszustand, Commit und verifiziertes Ergebnis schließen die Kette.

Für Interoperabilität wird derselbe Mitschnitt ohne externe Zugriffe und mit einer zweiten konformen Implementierung abgespielt. Abweichende Erweiterungsentscheidungen sind ein Vertragsfehler, kein Parserdetail.

Evidenzgrenze

Dieser Artikel schreibt keinem Produkt, Parser oder Betreiber einen Vorfall zu. Er behauptet nicht, unbekannte Erweiterungen müssten immer abgelehnt werden. Entscheidend ist die explizite und getestete Politik.

Er wiederholt nicht den bestehenden YANG/XML-Beitrag von BTW über effektiven YANG-Baum, Defaults, Schema-Revisionen, Mount-Kontext, Datastore und Netzwirkung. Hier geht es um generische XML-Erweiterungsgovernance.

Heng Lus Prinzipien der minimalen Anfangsspezifikation und des laufenden Codes dienen als offengelegte redaktionelle Linse. Sie verlangen gemeinsame Regeln an der Interoperabilitätsgrenze und Beobachtungen aus dem Betrieb, ohne eine Implementierung vorzuschreiben.

Das knappe Urteil lautet: Eine Erweiterung wird nicht dadurch harmlos, dass der Parser sie lesen kann. Ihr Verhalten muss der Protokollvertrag besitzen.

Sources