Zum Hauptinhalt springen

Anhang E. Vergleich anderer Binärformate mit den Designzielen von CBOR

Der Vorschlag für CBOR folgt einer Geschichte von Binärformaten, die so lang ist wie die Geschichte der Computer selbst. Verschiedene Formate hatten verschiedene Ziele. In den meisten Fällen wurden die Ziele des Formats nie ausdrücklich genannt, obwohl sie sich mitunter aus dem Kontext ableiten lassen, in dem das Format erstmals verwendet wurde. Manche Formate sollten universell einsetzbar sein, obwohl die Geschichte gezeigt hat, dass kein Binärformat die Bedürfnisse aller Protokolle und Anwendungen erfüllt.

CBOR unterscheidet sich von vielen dieser Formate dadurch, dass es von einer Reihe von Zielen ausgeht und versucht, genau diese zu erfüllen. Dieser Abschnitt vergleicht einige der Dutzenden von Formaten mit den Zielen von CBOR, um dem Leser bei der Entscheidung zu helfen, ob er für ein bestimmtes Protokoll oder eine bestimmte Anwendung CBOR oder ein anderes Format verwenden möchte.

Hinweis: Die hier geführte Diskussion ist nicht als Kritik an irgendeinem Format gedacht: Nach bestem Wissen war kein Format vor CBOR darauf ausgerichtet, die Ziele von CBOR in der von uns zugewiesenen Priorität abzudecken. Eine kurze Zusammenfassung der Ziele aus Abschnitt 1.1:

  1. eindeutige Kodierung der meisten gängigen Datenformate aus Internet-Standards

  2. Kompaktheit des Codes für Encoder oder Decoder

  3. keine Schemabeschreibung erforderlich

  4. einigermaßen kompakte Serialisierung

  5. Anwendbarkeit auf eingeschränkte und nicht eingeschränkte Anwendungen

  6. gute JSON-Konvertierung

  7. Erweiterbarkeit

E.1. ASN.1 DER, BER und PER​

  • [ASN.1] hat viele Serialisierungen. In der IETF sind DER und BER die gängigsten. Die serialisierte Ausgabe ist für viele Elemente nicht besonders kompakt, und der zum Dekodieren numerischer Elemente benötigte Code kann auf einem eingeschränkten Gerät komplex sein.

Wenige (wenn überhaupt) IETF-Protokolle haben eine der verschiedenen Varianten der Packed Encoding Rules (PER) übernommen. Dafür mag es viele Gründe geben, aber einer, der häufig genannt wird, ist, dass PER das Schema selbst für das Parsen der Oberflächenstruktur des Datenstroms heranzieht, was eine erhebliche Werkzeugunterstützung erfordert. Es sind unterschiedliche Versionen der ASN.1-Schemasprache in Gebrauch, was die Verbreitung ebenfalls behindert hat.

E.2. MessagePack​

  • [MessagePack] ist ein kompaktes, weit verbreitetes gezähltes binäres Serialisierungsformat, das in vielen Eigenschaften CBOR ähnlich ist, wenn auch etwas weniger regelmäßig. Obwohl das Datenmodell verwendet werden kann, um JSON-Daten darzustellen, wurde MessagePack auch in vielen Remote-Procedure-Call-Anwendungen (RPC) sowie zur langfristigen Speicherung von Daten eingesetzt.

MessagePack ist seit seiner ersten Veröffentlichung um das Jahr 2011 im Wesentlichen stabil geblieben; es hat noch keinen Übergang erlebt. Die Weiterentwicklung von MessagePack wird durch das Gebot behindert, die vollständige Abwärtskompatibilität mit bestehenden gespeicherten Daten zu wahren, während nur noch wenige Bytecodes für Erweiterungen verfügbar sind. Wiederholte Anfragen aus der MessagePack-Nutzergemeinschaft über die Jahre, binäre Zeichenfolgen und Text-Zeichenfolgen in der Kodierung zu trennen, haben in jüngerer Zeit zu einem Erweiterungsvorschlag geführt, der die "raw"-Daten von MessagePack zwischen ihrer Verwendung für Binär- und Textdaten mehrdeutig ließe. Der Erweiterungsmechanismus für MessagePack bleibt unklar.

E.3. BSON​

  • [BSON] ist ein Datenformat, das für die Speicherung JSON-ähnlicher Maps (JSON-Objekte) in der Datenbank MongoDB entwickelt wurde. Sein wesentliches Unterscheidungsmerkmal ist die Fähigkeit zur Aktualisierung an Ort und Stelle, wofür eine kompakte Darstellung aufgegeben wird. BSON verwendet eine gezählte Darstellung, mit Ausnahme der Map-Schlüssel, die durch ein Null-Byte abgeschlossen werden. Obwohl BSON für die Darstellung JSON-ähnlicher Objekte auf dem Übertragungsweg verwendet werden kann, wird seine Spezifikation von den Anforderungen der Datenbankanwendung dominiert und ist etwas barock geworden. Wie BSON-Erweiterungen implementiert werden, bleibt unklar.

E.4. UBJSON​

  • [UBJSON] verfolgt das Designziel, JSON schneller und etwas kleiner zu machen, indem ein Binärformat verwendet wird, das genau auf das von JSON verwendete Datenmodell beschränkt ist. Daher besteht ausdrücklich keine Absicht, beispielsweise Binärdaten zu unterstützen; es gibt jedoch eine "High-Precision Number", die als Zeichenfolge in JSON-Syntax ausgedrückt wird. UBJSON ist nicht auf Codekompaktheit optimiert, und seine Typbyte-Kodierung ist auf menschliche Erkennbarkeit optimiert und nicht auf kompakte Darstellung nativer Typen wie kleiner ganzer Zahlen. Obwohl UBJSON überwiegend gezählt ist, stellt es einen reservierten "unknown-length"-Wert bereit, um das Streaming von Arrays und Maps (JSON-Objekten) zu unterstützen. Innerhalb dieser Container hat UBJSON außerdem einen "Noop"-Typ zum Auffüllen.

E.5. MSDTP: RFC 713​

Message Services Data Transmission (MSDTP) ist ein sehr frühes Beispiel für ein kompaktes Nachrichtenformat; es ist in [RFC0713] beschrieben, das 1976 verfasst wurde. Es ist hier aus historischen Gründen aufgenommen, nicht weil es jemals weit verbreitet gewesen wäre.

E.6. Kompaktheit auf dem Übertragungsweg​

Obwohl das Designziel von CBOR, die Kompaktheit des Codes für Encoder und Decoder, eine höhere Priorität hat als das Ziel der Kompaktheit auf dem Übertragungsweg, konzentrieren sich viele Menschen auf die Größe auf dem Übertragungsweg. Tabelle 6 zeigt einige Kodierungsbeispiele für das einfache verschachtelte Array [1, [2, 3]]; sofern die Kodierung eine Form der Kodierung mit unbestimmter Länge unterstützt, wird auch [_ 1, [2, 3]] gezeigt (unbestimmte Länge beim äußeren Array).

Format[1, [2, 3]][_ 1, [2, 3]]
RFC 713c2 05 81 c2 02 82 83
ASN.1 BER30 0b 02 01 01 30 06 02 01 02 02 01 0330 80 02 01 01 30 06 02 01 02 02 01 03 00 00
MessagePack92 01 92 02 03
BSON22 00 00 00 10 30 00 01 00 00 00 04 31 00 13 00 00 00 10 30 00 02 00 00 00 10 31 00 03 00 00 00 00 00
UBJSON61 02 42 01 61 02 42 02 42 0361 ff 42 01 61 02 42 02 42 03 45
CBOR82 01 82 02 039f 01 82 02 03 ff

Tabelle 6: Beispiele für unterschiedliche Grade von Kompaktheit