Aller au contenu principal

Appendix E. Comparaison d'autres formats binaires avec les objectifs de conception de CBOR

La proposition de CBOR s'inscrit dans une histoire des formats binaires aussi longue que l'histoire des ordinateurs eux-mêmes. Différents formats ont eu différents objectifs. Dans la plupart des cas, les objectifs du format n'ont jamais été énoncés, bien qu'ils puissent parfois être induits par le contexte dans lequel le format a été utilisé pour la première fois. Certains formats étaient destinés à être universellement utilisables, bien que l'histoire ait prouvé qu'aucun format binaire ne répond aux besoins de tous les protocoles et de toutes les applications.

CBOR diffère de beaucoup de ces formats en ce qu'il part d'un ensemble d'objectifs et tente de satisfaire uniquement ceux-ci. Cette section compare quelques-uns des dizaines de formats avec les objectifs de CBOR afin d'aider le lecteur à décider s'il veut utiliser CBOR ou un format différent pour un protocole ou une application particulière.

Notons que la discussion ici n'est pas destinée à être une critique d'un format quelconque : à notre connaissance, aucun format avant CBOR n'était destiné à couvrir les objectifs de CBOR dans l'ordre de priorité que nous leur avons assigné. Un bref récapitulatif des objectifs de la Section 1.1 est :

  1. encodage non ambigu des formats de données les plus courants des normes Internet

  2. compacité du code pour l'encodeur ou le décodeur

  3. aucune description de schéma nécessaire

  4. sérialisation raisonnablement compacte

  5. applicabilité aux applications contraintes et non contraintes

  6. bonne conversion vers JSON

  7. extensibilité

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

  • [ASN.1] a de nombreuses sérialisations. Dans l'IETF, DER et BER sont les plus courantes. La sortie sérialisée n'est pas particulièrement compacte pour de nombreux éléments, et le code nécessaire pour décoder les éléments numériques peut être complexe sur un appareil contraint.

Peu de protocoles de l'IETF (voire aucun) ont adopté l'une des plusieurs variantes des Packed Encoding Rules (PER). Il pourrait y avoir de nombreuses raisons à cela, mais une raison couramment avancée est que PER utilise le schéma même pour analyser la structure de surface du flux de données, ce qui nécessite un important support d'outils. Il existe différentes versions du langage de schéma ASN.1 en usage, ce qui a également entravé l'adoption.

E.2. MessagePack​

  • [MessagePack] est un format de sérialisation binaire compté, concis et largement implémenté, similaire à CBOR sur de nombreuses propriétés, bien que quelque peu moins régulier. Bien que le modèle de données puisse être utilisé pour représenter des données JSON, MessagePack a aussi été utilisé dans de nombreuses applications d'appel de procédure à distance (RPC) et pour le stockage à long terme de données.

MessagePack est essentiellement stable depuis sa première publication vers 2011 ; il n'a pas encore connu de transition. L'évolution de MessagePack est entravée par un impératif de maintenir une compatibilité ascendante complète avec les données stockées existantes, alors que seuls quelques bytecodes restent disponibles pour l'extension. Des demandes répétées au fil des ans de la part de la communauté d'utilisateurs de MessagePack pour séparer les chaînes binaires et les chaînes de texte dans l'encodage ont récemment conduit à une proposition d'extension qui laisserait les données « raw » de MessagePack ambiguës entre ses usages pour les données binaires et textuelles. Le mécanisme d'extension de MessagePack reste flou.

E.3. BSON​

  • [BSON] est un format de données qui a été développé pour le stockage de tables de type JSON (objets JSON) dans la base de données MongoDB. Sa principale caractéristique distinctive est la capacité de mise à jour sur place, renonçant à une représentation compacte. BSON utilise une représentation comptée, à l'exception des clés de table, qui sont terminées par un octet nul. Bien que BSON puisse être utilisé pour la représentation d'objets de type JSON sur le réseau, sa spécification est dominée par les exigences de l'application de base de données et est devenue quelque peu baroque. L'état d'avancement de la manière dont les extensions de BSON seront implémentées reste flou.

E.4. UBJSON​

  • [UBJSON] a pour objectif de conception de rendre JSON plus rapide et quelque peu plus petit, en utilisant un format binaire limité exactement au modèle de données qu'utilise JSON. Ainsi, il n'y a expressément aucune intention de prendre en charge, par exemple, les données binaires ; toutefois, il existe un « nombre de haute précision », exprimé comme une chaîne de caractères dans la syntaxe JSON. UBJSON n'est pas optimisé pour la compacité du code, et son codage d'octet de type est optimisé pour la reconnaissance humaine et non pour la représentation compacte des types natifs tels que les petits entiers. Bien qu'UBJSON soit principalement compté, il fournit une valeur réservée « unknown-length » pour prendre en charge la mise en flux continu des tableaux et des tables (objets JSON). À l'intérieur de ces conteneurs, UBJSON a aussi un type « Noop » pour le bourrage.

E.5. MSDTP : RFC 713​

Message Services Data Transmission (MSDTP) est un exemple très précoce de format de message compact ; il est décrit dans la [RFC0713], écrite en 1976. Il est inclus ici pour sa valeur historique, et non parce qu'il a jamais été largement utilisé.

E.6. Concision sur le réseau​

Bien que l'objectif de conception de CBOR de compacité du code pour les encodeurs et les décodeurs soit une priorité plus élevée que son objectif de concision sur le réseau, de nombreuses personnes se concentrent sur la taille sur le réseau. La Table 6 montre quelques exemples d'encodage pour le tableau imbriqué simple [1, [2, 3]] ; lorsqu'une forme d'encodage de longueur indéfinie est prise en charge par l'encodage, [_ 1, [2, 3]] (longueur indéfinie sur le tableau externe) est également montré.

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

Table 6 : Exemples pour différents niveaux de concision