Zum Hauptinhalt springen

3. Erstellung CBOR-basierter Protokolle

Datenformate wie CBOR werden häufig in Umgebungen verwendet, in denen es keine Formataushandlung gibt. Ein ausdrückliches Designziel von CBOR ist es, kein enthaltenes oder angenommenes Schema zu benötigen: Ein Decoder kann ein CBOR-Element nehmen und es ohne weiteres Wissen dekodieren.

Natürlich werden der Encoder und der Decoder in realen Implementierungen eine gemeinsame Vorstellung davon haben, was in einem CBOR-Datenelement enthalten sein sollte. Beispielsweise könnte ein vereinbartes Format lauten: "das Element ist ein Array, dessen erster Wert eine UTF-8-Zeichenfolge ist, dessen zweiter Wert eine ganze Zahl ist und dessen nachfolgende Werte null oder mehr Gleitkommazahlen sind" oder "das Element ist eine Map, die Byte-Zeichenfolgen als Schlüssel hat und mindestens ein Paar enthält, dessen Schlüssel 0xab01 ist".

Diese Spezifikation legt CBOR-basierten Protokollen keine Einschränkungen auf. Ein Encoder kann in der Lage sein, so viele oder so wenige Arten von Werten zu kodieren, wie es das Protokoll erfordert, in dem er verwendet wird; ein Decoder kann in der Lage sein, so viele oder so wenige Arten von Werten zu verstehen, wie es die Protokolle erfordern, in denen er verwendet wird. Dieses Fehlen von Einschränkungen erlaubt den Einsatz von CBOR in extrem eingeschränkten Umgebungen.

Dieser Abschnitt erörtert einige Überlegungen bei der Erstellung CBOR-basierter Protokolle. Er ist ausschließlich beratend und schließt ausdrücklich jede Sprache aus RFC 2119 aus, mit Ausnahme von Wörtern, die im Sinne von RFC 2119 als "MAY" interpretiert werden könnten.

3.1. CBOR in Streaming-Anwendungen​

In einer Streaming-Anwendung kann ein Datenstrom aus einer Sequenz von CBOR-Datenelementen bestehen, die unmittelbar aneinandergereiht sind. In einer solchen Umgebung beginnt der Decoder sofort mit der Dekodierung eines neuen Datenelements, wenn nach dem Ende eines vorherigen Datenelements Daten gefunden werden.

Möglicherweise sind nicht alle Bytes, aus denen ein Datenelement besteht, dem Decoder sofort verfügbar; manche Decoder puffern zusätzliche Daten, bis ein vollständiges Datenelement der Anwendung bereitgestellt werden kann. Andere Decoder können der Anwendung Teilinformationen über ein Datenelement der obersten Ebene bereitstellen, etwa die verschachtelten Datenelemente, die bereits dekodiert werden konnten, oder sogar Teile einer Byte-Zeichenfolge, die noch nicht vollständig eingetroffen ist.

Hinweis: Manche Anwendungen und Protokolle werden die Kodierung mit unbestimmter Länge nicht verwenden wollen. Die Kodierung mit unbestimmter Länge erlaubt es einem Encoder, nicht alle Daten zum Zählen zusammenführen zu müssen, erfordert aber von einem Decoder, zunehmend Speicher zu allozieren, während er auf das Ende des Elements wartet. Dies mag für manche Anwendungen in Ordnung sein, für andere nicht.

3.2. Generische Encoder und Decoder​

Ein generischer CBOR-Decoder kann alle wohlgeformten CBOR-Daten dekodieren und sie einer Anwendung bereitstellen. CBOR-Daten sind wohlgeformt, wenn sie die Anfangsbytes sowie die Byte-Zeichenfolgen und/oder Datenelemente, die durch deren Werte impliziert werden, in der von CBOR definierten Weise verwenden und keine überzähligen Daten folgen (Anhang C).

Obwohl CBOR versucht, diese Fälle zu minimieren, sind nicht alle wohlgeformten CBOR-Daten gültig: Beispielsweise schließt das Format einfache Werte unter 32 aus, die mit einem Erweiterungsbyte kodiert sind. Auch können bestimmte Tags semantische Einschränkungen vorgeben, die verletzt werden können, etwa indem ein Tag in einem Bignum-Tag eingeschlossen wird oder indem innerhalb eines Datums-Tags eine Byte-Zeichenfolge folgt. Schließlich können die Daten ungültig sein, etwa ungültige UTF-8-Zeichenfolgen oder Datumszeichenfolgen, die nicht [RFC3339] entsprechen. Es gibt keine Anforderung, dass generische Encoder und Decoder unnatürliche Entscheidungen für ihre Anwendungsschnittstelle treffen, um die Verarbeitung ungültiger Daten zu ermöglichen. Es wird erwartet, dass generische Encoder und Decoder einfache Werte und Tags weiterleiten, selbst wenn deren spezifische Codepoints zum Zeitpunkt der Erstellung des Encoders/Decoders noch nicht registriert sind (Abschnitt 3.5).

Generische Decoder bieten Möglichkeiten, wohlgeformte CBOR-Werte, sowohl gültige als auch ungültige, einer Anwendung bereitzustellen. Die diagnostische Notation (Abschnitt 6) kann verwendet werden, um wohlgeformte CBOR-Werte Menschen darzustellen.

Generische Encoder bieten eine Anwendungsschnittstelle, die es der Anwendung erlaubt, einen beliebigen wohlgeformten Wert anzugeben, einschließlich einfacher Werte und dem Encoder unbekannter Tags.

3.3. Syntaxfehler​

Ein Decoder, der auf ein nicht wohlgeformtes CBOR-Datenelement trifft, kann im Allgemeinen wählen, die Dekodierung vollständig scheitern zu lassen (einen Fehler auszugeben und/oder die Verarbeitung ganz einzustellen), die problematischen Daten und Datenelemente nach einer decoder-spezifischen Konvention zu ersetzen, die deutlich anzeigt, dass ein Problem aufgetreten ist, oder eine andere Maßnahme zu ergreifen.

3.3.1. Unvollständige CBOR-Datenelemente​

Die Darstellung eines CBOR-Datenelements hat eine bestimmte Länge, die durch seine Anfangsbytes und durch die Struktur etwaiger in den Datenelementen enthaltener Datenelemente bestimmt wird. Wenn weniger Daten verfügbar sind, kann dies als Syntaxfehler behandelt werden. Ein Decoder kann auch inkrementelles Parsen implementieren, das heißt das Datenelement so weit dekodieren, wie es verfügbar ist, und die bisher gefundenen Daten bereitstellen (beispielsweise in einer ereignisbasierten Schnittstelle), mit der Option, die Dekodierung fortzusetzen, sobald weitere Daten verfügbar sind.

Beispiele für unvollständige Datenelemente sind:

  • Ein Decoder erwartet eine bestimmte Anzahl von Array- oder Map-Einträgen, trifft aber stattdessen auf das Ende der Daten.

  • Ein Decoder verarbeitet das, von dem er erwartet, dass es das letzte Paar in einer Map ist, und gelangt zum Ende der Daten.

  • Ein Decoder hat gerade ein Tag gesehen und trifft dann auf das Ende der Daten.

  • Ein Decoder hat den Anfang eines Elements mit unbestimmter Länge gesehen, trifft aber auf das Ende der Daten, bevor er den "break"-Stoppcode sieht.

3.3.2. Fehlerhafte Elemente mit unbestimmter Länge​

Beispiele für fehlerhafte Datenelemente mit unbestimmter Länge sind:

  • Innerhalb einer Byte- oder Text-Zeichenfolge mit unbestimmter Länge findet ein Decoder ein Element, das nicht vom passenden Haupttyp ist, bevor er den "break"-Stoppcode findet.

  • Innerhalb einer Map mit unbestimmter Länge trifft ein Decoder unmittelbar nach dem Lesen eines Schlüssels auf den "break"-Stoppcode (der Wert fehlt).

Ein weiterer Fehler besteht darin, einen "break"-Stoppcode an einer Stelle in den Daten zu finden, an der es kein unmittelbar umschließendes (nicht abgeschlossenes) Element mit unbestimmter Länge gibt.

3.3.3. Unbekannte Werte der zusätzlichen Informationen​

Zum Zeitpunkt der Erstellung dieses Dokuments sind einige Werte der zusätzlichen Informationen nicht zugewiesen und für künftige Versionen dieses Dokuments reserviert (siehe Abschnitt 5.2). Da die allgemeine Syntax für diese Werte der zusätzlichen Informationen noch nicht definiert ist, kann ein Decoder, der einen Wert der zusätzlichen Informationen sieht, den er nicht versteht, das Parsen nicht fortsetzen.

3.4. Andere Dekodierungsfehler​

Ein CBOR-Datenelement kann syntaktisch wohlgeformt sein, aber ein Problem bei der Interpretation der darin kodierten Daten im CBOR-Datenmodell aufweisen. Allgemein gesprochen kann ein Decoder, der ein Datenelement mit einem solchen Problem findet, eine Warnung ausgeben, die Verarbeitung ganz einstellen, den Fehler behandeln und den problematischen Wert der Anwendung als solchen bereitstellen oder eine andere Art von Maßnahme ergreifen.

Solche Probleme können umfassen:

Doppelte Schlüssel in einer Map: Generische Decoder (Abschnitt 3.2) stellen der Anwendung Daten unter Verwendung des nativen CBOR-Datenmodells bereit. Dieses Datenmodell umfasst Maps (Schlüssel-Wert-Abbildungen mit eindeutigen Schlüsseln), keine Multimaps (Schlüssel-Wert-Abbildungen, bei denen mehrere Einträge denselben Schlüssel haben können). Daher wird ein generischer Decoder, der ein CBOR-Map-Element mit doppelten Schlüsseln erhält, zu einer Map dekodieren, die nur eine Instanz dieses Schlüssels enthält, oder er könnte die Verarbeitung ganz einstellen. Andererseits kann ein "Streaming-Decoder" dies unter Umständen nicht einmal bemerken (Abschnitt 3.7).

Unzulässiger Typ beim Wert, der auf ein Tag folgt: Tags (Abschnitt 2.4) legen fest, welcher Typ von Datenelement auf das Tag folgen soll; beispielsweise sollen die Tags für positive oder negative Bignums auf Byte-Zeichenfolgen gesetzt werden. Von einem Decoder, der das markierte Datenelement in eine native Darstellung dekodiert (in diesem Beispiel eine native große ganze Zahl), wird erwartet, dass er den Typ des markierten Datenelements prüft. Selbst Decoder, die in ihrer Umgebung keine solchen nativen Darstellungen zur Verfügung haben, können die Prüfung bei den ihnen bekannten Tags durchführen und angemessen reagieren.

Ungültige UTF-8-Zeichenfolge: Ein Decoder kann, muss aber nicht, überprüfen, ob die Byte-Folge in einer UTF-8-Zeichenfolge (Haupttyp 3) tatsächlich gültiges UTF-8 ist, und angemessen reagieren.

3.5. Umgang mit unbekannten einfachen Werten und Tags​

Ein Decoder, der auf einen einfachen Wert (Abschnitt 2.3) trifft, den er nicht erkennt, etwa einen Wert, der dem IANA-Register nach der Bereitstellung des Decoders hinzugefügt wurde, oder einen Wert, den der Decoder nicht implementieren wollte, kann eine Warnung ausgeben, die Verarbeitung ganz einstellen, den Fehler behandeln, indem er der Anwendung den unbekannten Wert als solchen bereitstellt (wie von generischen Decodern erwartet), oder eine andere Art von Maßnahme ergreifen.

Ein Decoder, der auf ein Tag (Abschnitt 2.4) trifft, das er nicht erkennt, etwa ein Tag, das dem IANA-Register nach der Bereitstellung des Decoders hinzugefügt wurde, oder ein Tag, das der Decoder nicht implementieren wollte, kann eine Warnung ausgeben, die Verarbeitung ganz einstellen, den Fehler behandeln und der Anwendung den unbekannten Tag-Wert zusammen mit dem enthaltenen Datenelement bereitstellen (wie von generischen Decodern erwartet), das Tag ignorieren und der Anwendung nur das enthaltene Datenelement bereitstellen oder eine andere Art von Maßnahme ergreifen.

3.6. Zahlen​

Für die Zwecke dieser Spezifikation sind alle Zahlendarstellungen für denselben numerischen Wert gleichwertig. Das bedeutet, dass ein Encoder einen Gleitkommawert von 0.0 als die ganze Zahl 0 kodieren kann. Es bedeutet aber auch, dass eine Anwendung, die nur ganzzahlige Werte erwartet, Gleitkommawerte finden kann, wenn der Encoder diese für wünschenswert hält, etwa wenn der Gleitkommawert kompakter ist als eine 64-Bit-Ganzezahl.

Eine Anwendung oder ein Protokoll, das CBOR verwendet, kann die Darstellungen von Zahlen einschränken. Beispielsweise könnte ein Protokoll, das nur mit ganzen Zahlen arbeitet, festlegen, dass Gleitkommazahlen nicht verwendet werden dürfen und dass Decoder dieses Protokolls nicht in der Lage sein müssen, Gleitkommazahlen zu verarbeiten. Ebenso könnte ein Protokoll oder eine Anwendung, die CBOR verwendet, festlegen, dass Decoder in der Lage sein müssen, beide Arten von Zahlen zu verarbeiten.

CBOR-basierte Protokolle sollten berücksichtigen, dass verschiedene Sprachumgebungen unterschiedliche Einschränkungen hinsichtlich Wertebereich und Genauigkeit darstellbarer Zahlen mit sich bringen. Beispielsweise behandelt das JavaScript-Zahlensystem alle Zahlen als Gleitkommazahlen, was beim Dekodieren ganzer Zahlen mit mehr als 53 signifikanten Bits zu einem stillschweigenden Genauigkeitsverlust führen kann. Ein Protokoll, das Zahlen verwendet, sollte seine Erwartungen an die Handhabung nicht-trivialer Zahlen in Decodern und empfangenden Anwendungen definieren.

Ein CBOR-basiertes Protokoll, das Gleitkommazahlen enthält, kann einschränken, welche der drei Formate (halbe Genauigkeit, einfache Genauigkeit und doppelte Genauigkeit) unterstützt werden müssen. Bei einer ausschließlich auf ganze Zahlen ausgerichteten Anwendung kann ein Protokoll die Verwendung von Gleitkommawerten vollständig ausschließen wollen.

Ein auf Kompaktheit ausgelegtes CBOR-basiertes Protokoll kann bestimmte ganzzahlige Kodierungen ausschließen wollen, die für die Anwendung länger als nötig sind, etwa um die Notwendigkeit zu vermeiden, 64-Bit-Ganzzahlen zu implementieren. Es besteht die Erwartung, dass Encoder die kompakteste ganzzahlige Darstellung verwenden, die einen gegebenen Wert darstellen kann. Eine kompakte Anwendung sollte jedoch Werte akzeptieren, die eine länger als nötige Kodierung verwenden (beispielsweise die Kodierung von "0" als 0b000_11101, gefolgt von zwei Bytes 0x00), solange die Anwendung eine ganze Zahl der betreffenden Größe dekodieren kann.

3.7. Festlegung von Schlüsseln für Maps​

Die kodierenden und dekodierenden Anwendungen müssen sich darauf einigen, welche Arten von Schlüsseln in Maps verwendet werden sollen. In Anwendungen, die mit JSON-basierten Anwendungen zusammenarbeiten müssen, sollten Schlüssel wahrscheinlich auf UTF-8-Zeichenfolgen beschränkt werden; anderenfalls muss eine festgelegte Abbildung von den anderen CBOR-Typen auf Unicode-Zeichen existieren, was häufig zu Implementierungsfehlern führt. In Anwendungen, in denen Schlüssel von Natur aus numerisch sind und die numerische Sortierung der Schlüssel für die Anwendung wichtig ist, ist die direkte Verwendung der Zahlen als Schlüssel nützlich.

Wenn mehrere Arten von Schlüsseln verwendet werden sollen, sollte bedacht werden, wie diese Typen in den spezifischen Programmierumgebungen dargestellt würden, die verwendet werden sollen. Beispielsweise kann in JavaScript-Objekten ein Schlüssel der ganzen Zahl 1 nicht von einem Schlüssel der Zeichenfolge "1" unterschieden werden. Das bedeutet, dass bei Verwendung ganzzahliger Schlüssel die gleichzeitige Verwendung von Zeichenfolgen-Schlüsseln, die wie Zahlen aussehen, vermieden werden muss. Auch dies führt zu dem Schluss, dass Schlüssel von einem einzigen CBOR-Typ sein sollten.

Decoder, die in einem CBOR-Datenelement verschachtelte Datenelemente unmittelbar nach deren Dekodierung ausliefern ("Streaming-Decoder"), behalten häufig nicht den Zustand, der nötig ist, um die Eindeutigkeit eines Schlüssels in einer Map festzustellen. Ebenso kann ein Encoder, der mit der Kodierung von Datenelementen beginnen kann, bevor das umschließende Datenelement vollständig verfügbar ist ("Streaming-Encoder"), seinen Aufwand erheblich verringern wollen, indem er sich darauf verlässt, dass seine Datenquelle die Eindeutigkeit aufrechterhält.

Ein CBOR-basiertes Protokoll sollte eine bewusste Entscheidung darüber treffen, was zu tun ist, wenn eine empfangende Anwendung mehrere identische Schlüssel in einer Map sieht. Die daraus resultierende Regel im Protokoll sollte das CBOR-Datenmodell respektieren: Sie kann keine spezifische Handhabung der Einträge mit identischen Schlüsseln vorschreiben, mit der Ausnahme, dass sie eine Regel haben kann, wonach identische Schlüssel in einer Map eine fehlerhafte Map anzeigen und der Decoder mit einem Fehler abbrechen muss. Doppelte Schlüssel sind auch von CBOR-Decodern verboten, die den Strict-Modus verwenden (Abschnitt 3.10).

Das CBOR-Datenmodell für Maps erlaubt es nicht, der Reihenfolge der Schlüssel/Wert-Paare in der Map-Darstellung Semantik zuzuschreiben. Daher wäre es eine sehr schlechte Praxis, ein CBOR-basiertes Protokoll so zu definieren, dass eine Änderung der Reihenfolge der Schlüssel/Wert-Paare in einer Map die Semantik ändern würde, abgesehen von trivialen Aspekten (Cache-Nutzung usw.). (Ein CBOR-basiertes Protokoll kann eine bestimmte Serialisierungsreihenfolge vorschreiben, etwa zur Kanonisierung.)

Anwendungen für eingeschränkte Geräte, die Maps mit 24 oder weniger häufig verwendeten Schlüsseln haben, sollten die Verwendung kleiner ganzer Zahlen in Betracht ziehen (und solche mit bis zu 48 häufig verwendeten Schlüsseln sollten auch kleine negative ganze Zahlen in Betracht ziehen), weil die Schlüssel dann in einem einzigen Byte kodiert werden können.

3.8. Undefined-Werte​

In manchen CBOR-basierten Protokollen kann der einfache Wert (Abschnitt 2.3) Undefined von einem Encoder als Ersatz für ein Datenelement mit einem Kodierungsproblem verwendet werden, um den Rest der umschließenden Datenelemente ohne Schaden kodieren zu können.

3.9. Kanonisches CBOR​

Manche Protokolle möchten, dass Encoder CBOR nur in einem bestimmten kanonischen Format ausgeben; diese Protokolle können auch die Decoder prüfen lassen, dass ihre Eingabe kanonisch ist. Diese Protokolle sind frei darin zu definieren, was sie unter einem kanonischen Format verstehen und was von Encodern und Decodern erwartet wird. Dieser Abschnitt listet einige Vorschläge für solche Protokolle auf.

Wenn ein Protokoll unter "kanonisch" versteht, dass zwei Encoder-Implementierungen, die mit denselben Eingabedaten beginnen, dieselbe CBOR-Ausgabe erzeugen, würden die folgenden vier Regeln genügen:

  • Ganze Zahlen müssen so klein wie möglich sein.

    • 0 bis 23 und -1 bis -24 müssen im selben Byte wie der Haupttyp ausgedrückt werden;

    • 24 bis 255 und -25 bis -256 dürfen nur mit einem zusätzlichen uint8_t ausgedrückt werden;

    • 256 bis 65535 und -257 bis -65536 dürfen nur mit einem zusätzlichen uint16_t ausgedrückt werden;

    • 65536 bis 4294967295 und -65537 bis -4294967296 dürfen nur mit einem zusätzlichen uint32_t ausgedrückt werden.

  • Die Angabe von Längen in den Haupttypen 2 bis 5 muss so kurz wie möglich sein. Die Regeln für diese Längen folgen der obigen Regel für ganze Zahlen.

  • Die Schlüssel in jeder Map müssen vom niedrigsten zum höchsten Wert sortiert sein. Die Sortierung erfolgt über die Bytes der Darstellung der Schlüssel-Datenelemente, ohne Berücksichtigung der 3/5-Bit-Aufteilung für Haupttypen. (Hinweis: Diese Regel erlaubt Maps mit Schlüsseln unterschiedlicher Typen, obwohl dies wahrscheinlich eine schlechte Praxis ist, die bei manchen Kanonisierungsimplementierungen zu Fehlern führen kann.) Die Sortierregeln sind:

    • Wenn zwei Schlüssel unterschiedliche Längen haben, wird der kürzere früher einsortiert;

    • Wenn zwei Schlüssel dieselbe Länge haben, wird der mit dem niedrigeren Wert in (byteweiser) lexikalischer Reihenfolge früher einsortiert.

  • Elemente mit unbestimmter Länge müssen in Elemente mit bestimmter Länge umgewandelt werden.

Wenn ein Protokoll IEEE-Gleitkommazahlen zulässt, müssen möglicherweise zusätzliche Kanonisierungsregeln hinzugefügt werden. Eine Beispielregel könnte sein, dass alle Gleitkommazahlen als 64-Bit-Gleitkommazahl beginnen und dann eine Testkonvertierung in eine 32-Bit-Gleitkommazahl durchgeführt wird; wenn das Ergebnis derselbe numerische Wert ist, wird der kürzere Wert verwendet und der Vorgang mit einer Testkonvertierung in eine 16-Bit-Gleitkommazahl wiederholt. (Diese Regel wählt für positives und negatives Infinity ebenfalls die 16-Bit-Gleitkommazahl.) Außerdem gibt es viele Darstellungen für NaN. Wenn NaN ein zulässiger Wert ist, muss er immer als 0xf97e00 dargestellt werden.

CBOR-Tags bringen zusätzliche Überlegungen für die Kanonisierung mit sich. Das Fehlen oder Vorhandensein von Tags in einem kanonischen Format wird durch die Optionalität der Tags im Protokoll bestimmt. In einem CBOR-basierten Protokoll, das optionale Markierungen überall erlaubt, darf das kanonische Format sie nicht zulassen. In einem Protokoll, das Tags an bestimmten Stellen erfordert, muss das Tag im kanonischen Format erscheinen. Ein CBOR-basiertes Protokoll, das Kanonisierung verwendet, kann stattdessen festlegen, dass alle in einer Nachricht erscheinenden Tags beibehalten werden müssen, unabhängig davon, ob sie optional sind.

3.10. Strict-Modus​

Manche Anwendungsbereiche von CBOR erfordern keine Kanonisierung (Abschnitt 3.9), können aber erfordern, dass verschiedene Decoder zu denselben (semantisch äquivalenten) Ergebnissen gelangen, selbst bei potenziell bösartigen Daten. Dies kann erforderlich sein, wenn eine Anwendung (etwa eine Firewall oder eine andere schützende Instanz) eine Entscheidung aufgrund der Daten trifft, auf die sich eine andere Anwendung verlässt, die die Daten unabhängig dekodiert.

Normalerweise liegt es in der Verantwortung des Senders, mehrdeutig dekodierbare Daten zu vermeiden. Der Sender könnte jedoch ein Angreifer sein, der absichtlich CBOR-Daten so zusammenstellt, dass sie von verschiedenen Decodern unterschiedlich interpretiert werden, um dies als Schwachstelle auszunutzen. Generische Decoder, die in Anwendungen eingesetzt werden, in denen dies ein Problem sein könnte, müssen einen Strict-Modus unterstützen, in dem es auch in der Verantwortung des Empfängers liegt, mehrdeutig dekodierbare Daten zurückzuweisen. Es wird erwartet, dass Firewalls und andere Sicherheitssysteme, die CBOR dekodieren, nur im Strict-Modus dekodieren.

Ein Decoder im Strict-Modus wird zuverlässig alle Daten zurückweisen, die von anderen Decodern auf unterschiedliche Weise interpretiert werden könnten. Er wird zuverlässig Datenelemente mit Syntaxfehlern zurückweisen (Abschnitt 3.3). Er wird auch den Aufwand auf sich nehmen, andere Dekodierungsfehler zuverlässig zu erkennen (Abschnitt 3.4). Insbesondere muss ein Strict-Decoder über eine API verfügen, die für ein CBOR-Datenelement, das eines der folgenden Merkmale aufweist, einen Fehler meldet (und keine Daten zurückgibt):

  • eine Map (Haupttyp 5), die mehr als einen Eintrag mit demselben Schlüssel hat

  • ein Tag, das auf einem Datenelement des falschen Typs verwendet wird

  • ein Datenelement, das für den ihm zugewiesenen Typ falsch formatiert ist, etwa ungültiges UTF-8 oder Daten, die nicht mit dem spezifischen Tag interpretiert werden können, mit dem sie markiert wurden

Ein Decoder im Strict-Modus kann eines von zwei Dingen tun, wenn er auf ein Tag oder einen einfachen Wert trifft, den er nicht erkennt:

  • Er kann einen Fehler melden (und keine Daten zurückgeben).

  • Er kann das unbekannte Element (Typ, Wert und bei Tags das dekodierte markierte Datenelement) an die Anwendung ausgeben, die den Decoder aufruft, mit dem Hinweis, dass der Decoder dieses Tag oder diesen einfachen Wert nicht erkannt hat.

Der letztere Ansatz, der auch für nicht-strikte Decoder geeignet ist, unterstützt die Vorwärtskompatibilität mit neu registrierten Tags und einfachen Werten, ohne dass der Encoder gleichzeitig mit der aufrufenden Anwendung aktualisiert werden muss. (Dazu muss die API des Decoders eine Möglichkeit bieten, unbekannte Elemente zu kennzeichnen, damit die aufrufende Anwendung sie in einer für das Programm geeigneten Weise behandeln kann.)

Da ein Teil dieser Verarbeitung mit merklichen Kosten verbunden sein kann (insbesondere bei der Duplikaterkennung für Maps), ist die Unterstützung des Strict-Modus keine Anforderung, die an alle CBOR-Decoder gestellt wird.

Manche Encoder verlassen sich darauf, dass ihre Anwendungen Eingabedaten so bereitstellen, dass eindeutig dekodierbares CBOR entsteht. Ein generischer Encoder kann ebenfalls einen Strict-Modus bereitstellen wollen, in dem er seine Ausgabe zuverlässig auf eindeutig dekodierbares CBOR beschränkt, unabhängig davon, ob seine Anwendung API-konforme Daten bereitstellt.