1. Introduction (Einführung)

Es gibt Hunderte von standardisierten Formaten für die binäre Darstellung strukturierter Daten (auch bekannt als binäre Serialisierungsformate, Binary Serialization Formats). Einige davon sind für bestimmte Informationsbereiche bestimmt, während andere für beliebige Daten verallgemeinert sind. In der IETF sind die bekanntesten Formate in der letzteren Kategorie wahrscheinlich BER und DER von ASN.1 [ASN.1].

Das hier definierte Format folgt einigen spezifischen Designzielen, die von aktuellen Formaten nicht gut erfüllt werden. Das zugrunde liegende Datenmodell (Data Model) ist eine erweiterte Version des JSON-Datenmodells [RFC8259]. Es ist wichtig zu beachten, dass dies kein Vorschlag ist, die Grammatik in RFC 8259 allgemein zu erweitern, da dies eine erhebliche Rückwärtsinkompatibilität mit bereits eingesetzten JSON-Dokumenten verursachen würde. Stattdessen definiert dieses Dokument einfach sein eigenes Datenmodell, das von JSON ausgeht.

Anhang E listet einige vorhandene binäre Formate auf und diskutiert, inwieweit sie den Designzielen der Concise Binary Object Representation (CBOR, Prägnante Binäre Objektdarstellung) entsprechen oder nicht entsprechen.

Dieses Dokument ersetzt [RFC7049] und bietet redaktionelle Verbesserungen, neue Details und Erratakorrektur, während die vollständige Kompatibilität mit dem Austauschformat von RFC 7049 erhalten bleibt. Es erstellt keine neue Version des Formats.

1.1. Objectives (Ziele)

Die Ziele von CBOR, ungefähr in abnehmender Reihenfolge der Wichtigkeit, sind:

1. Die Darstellung muss in der Lage sein, die meisten gängigen Datenformate, die in Internetstandards verwendet werden, eindeutig zu codieren.

   • Sie muss eine vernünftige Menge grundlegender Datentypen und Strukturen unter Verwendung binärer Codierung darstellen. "Vernünftig" wird hier weitgehend von den Fähigkeiten von JSON beeinflusst, mit der wichtigen Ergänzung binärer Byte-Zeichenfolgen (Byte String). Die unterstützten Strukturen sind auf Arrays (Array) und Bäume (Tree) beschränkt; Schleifen (Loop) und gitterartige Graphen (Lattice-Style Graph) werden nicht unterstützt.

   • Es ist nicht erforderlich, dass alle Datenformate eindeutig codiert werden; das heißt, es ist akzeptabel, dass die Zahl "7" auf mehrere verschiedene Arten codiert werden kann.

2. Der Code für einen Encoder oder Decoder muss kompakt sein können, um Systeme mit sehr begrenztem Speicher, Prozessorleistung und Befehlssätzen zu unterstützen.

   • Ein Encoder und ein Decoder müssen in einer sehr kleinen Menge Code implementierbar sein (zum Beispiel in Klasse-1-eingeschränkten Knoten, wie in [RFC7228] definiert).

   • Das Format sollte zeitgenössische Maschinendarstellungen von Daten verwenden (zum Beispiel keine Binär-zu-Dezimal-Konvertierung erfordern).

3. Daten müssen ohne Schemabeschreibung (Schema Description) decodiert werden können.

   • Ähnlich wie JSON sollten codierte Daten selbstbeschreibend (Self-Describing) sein, damit ein generischer Decoder geschrieben werden kann.

4. Die Serialisierung muss vernünftig kompakt sein, aber die Datenkompaktheit ist der Codekompaktheit für den Encoder und Decoder untergeordnet.

   • "Vernünftig" ist hier durch JSON als Obergrenze der Größe begrenzt und durch die Implementierungskomplexität, die die Menge an Aufwand begrenzt, die in das Erreichen dieser Kompaktheit gesteckt werden kann. Die Verwendung allgemeiner Komprimierungsschemata oder umfangreicher Bit-Manipulationen verstößt gegen die Komplexitätsziele.

5. Das Format muss sowohl auf eingeschränkte Knoten (Constrained Node) als auch auf Hochvolumenanwendungen anwendbar sein.

   • Dies bedeutet, dass es sowohl für die Codierung als auch für die Decodierung vernünftig sparsam im CPU-Verbrauch sein muss. Dies ist sowohl für eingeschränkte Knoten als auch für potenzielle Verwendung in Anwendungen mit sehr hohem Datenvolumen relevant.

6. Das Format muss alle JSON-Datentypen für die Konvertierung zu und von JSON unterstützen.

   • Es muss ein vernünftiges Maß an Konvertierung unterstützen, solange die dargestellten Daten innerhalb der Fähigkeiten von JSON liegen. Es muss möglich sein, für alle Datentypen eine unidirektionale Zuordnung zu JSON zu definieren.

7. Das Format muss erweiterbar sein, und die erweiterten Daten müssen von früheren Decodern decodierbar sein.

   • Das Format ist für jahrzehntelange Nutzung konzipiert.

   • Das Format muss eine Form der Erweiterbarkeit unterstützen, die Fallback ermöglicht, sodass ein Decoder, der eine Erweiterung nicht versteht, die Nachricht dennoch decodieren kann.

   • Das Format muss in Zukunft durch spätere IETF-Standards erweitert werden können.

1.2. Terminology (Terminologie)

Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "NOT RECOMMENDED" (NICHT EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Der Begriff "byte" (Byte) wird in seinem heute üblichen Sinn als Synonym für "octet" (Oktett) verwendet. Alle Mehrbyte-Werte werden in Netzwerk-Byte-Reihenfolge (Network Byte Order) codiert (das heißt, höchstwertiges Byte zuerst, auch bekannt als "Big-Endian").

Diese Spezifikation verwendet die folgende Terminologie:

Data item (Datenelement): Ein einzelnes CBOR-Datenelement. Die Struktur eines Datenelements kann null, ein oder mehrere verschachtelte Datenelemente enthalten. Der Begriff wird sowohl für das Datenelement im Darstellungsformat als auch für die abstrakte Idee verwendet, die ein Decoder daraus ableiten kann; ersteres kann spezifisch durch Verwendung des Begriffs "encoded data item" (codiertes Datenelement) angesprochen werden.

Decoder (Decoder): Ein Prozess, der ein wohlgeformtes codiertes CBOR-Datenelement decodiert und es einer Anwendung zur Verfügung stellt. Formal gesprochen enthält ein Decoder einen Parser, um die Eingabe unter Verwendung der Syntaxregeln von CBOR zu zerlegen, sowie einen semantischen Prozessor (Semantic Processor), um die Daten in einer für die Anwendung geeigneten Form vorzubereiten.

Encoder (Encoder): Ein Prozess, der das (wohlgeformte) Darstellungsformat eines CBOR-Datenelements aus Anwendungsinformationen generiert.

Data Stream (Datenstrom): Eine Sequenz von null oder mehr Datenelementen, die nicht weiter zu einem größeren enthaltenden Datenelement zusammengesetzt werden (siehe [RFC8742] für eine Anwendung). Die unabhängigen Datenelemente, aus denen ein Datenstrom besteht, werden manchmal auch als "top-level data items" (Datenelemente der obersten Ebene) bezeichnet.

Well-formed (wohlgeformt): Ein Datenelement, das der syntaktischen Struktur von CBOR folgt. Ein wohlgeformtes Datenelement verwendet die anfänglichen Bytes und die Byte-Zeichenfolgen und/oder Datenelemente, die durch ihre Werte impliziert werden, wie in CBOR definiert, und enthält keine folgenden fremden Daten. CBOR-Decoder geben per Definition nur Inhalte von wohlgeformten Datenelementen zurück.

Valid (gültig): Ein Datenelement, das wohlgeformt ist und auch den semantischen Einschränkungen folgt, die für CBOR-Datenelemente gelten (Abschnitt 5.3).

Expected (erwartet): Neben seiner normalen englischen Bedeutung wird der Begriff "expected" verwendet, um Anforderungen zu beschreiben, die über die CBOR-Gültigkeit hinausgehen und die eine Anwendung an ihre Eingabedaten stellt. Well-formed (überhaupt verarbeitbar), valid (von einem gültigkeitsprüfenden generischen Decoder geprüft) und expected (von der Anwendung geprüft) bilden eine Hierarchie von Akzeptabilitätsschichten.

Stream decoder (Stream-Decoder): Ein Prozess, der einen Datenstrom decodiert und jedes der Datenelemente in der Sequenz einer Anwendung zur Verfügung stellt, sobald sie empfangen werden.

Begriffe und Konzepte für Gleitkommawerte wie Infinity, NaN (keine Zahl, Not a Number), negative Null (Negative Zero) und subnormale Zahlen (Subnormal) sind in [IEEE754] definiert.

Wo Bitarithmetik oder Datentypen erklärt werden, verwendet dieses Dokument die aus der Programmiersprache C [C] bekannte Notation, außer dass ".." einen Bereich bezeichnet, der beide angegebenen Enden einschließt, und die Hochstellungsnotation die Potenzierung bezeichnet. Zum Beispiel wird 2 hoch 64 notiert: 2^(64). In der Klartextversion dieser Spezifikation ist die Hochstellungsnotation nicht verfügbar und wird daher durch eine Ersatznotation dargestellt. Diese Notation ist nicht für diese RFC optimiert; sie ist leider mehrdeutig mit dem exklusiven Oder von C (das nur in den Anhängen verwendet wird, die wiederum keine Potenzierung verwenden) und erfordert Umsicht vom Leser der Klartextversion.

Beispiele und Pseudocode gehen davon aus, dass vorzeichenbehaftete Ganzzahlen die Zweierkomplement-Darstellung verwenden und dass Rechtsverschiebungen von vorzeichenbehafteten Ganzzahlen eine Vorzeichenerweiterung durchführen; diese Annahmen sind auch in den Abschnitten 6.8.1 (basic.fundamental) und 7.6.7 (expr.shift) der 2020-Version von C++ spezifiziert (derzeit als finaler Entwurf verfügbar, [Cplusplus20]).

Ähnlich wie die "0x"-Notation für Hexadezimalzahlen werden Zahlen in binärer Notation mit "0b" vorangestellt. Unterstriche können allein für die Lesbarkeit zu einer Zahl hinzugefügt werden, sodass 0b00100001 (0x21) als 0b001_00001 geschrieben werden kann, um die gewünschte Interpretation der Bits im Byte zu betonen; in diesem Fall wird es in drei Bits und fünf Bits aufgeteilt. Codierte CBOR-Datenelemente werden manchmal in der "0x"- oder "0b"-Notation angegeben; diese Werte werden zuerst wie in C als Zahlen interpretiert und dann als Byte-Zeichenfolgen in Netzwerk-Byte-Reihenfolge interpretiert, einschließlich aller in der Notation ausgedrückten führenden Null-Bytes.

Wörter können zur Betonung kursiv gesetzt werden; in der Klartextform dieser Spezifikation wird dies durch Umgeben von Wörtern mit Unterstrich-Zeichen angezeigt. Wörtlicher Text (z. B. Namen aus einer Programmiersprache) kann in "Festbreitenschrift" gesetzt werden; im Klartext wird dies etwas mehrdeutig durch Umgeben des Textes mit doppelten Anführungszeichen angenähert (die auch ihre übliche Bedeutung behalten).