1.1. Objectives (Objectifs)

1.1. Objectives (Objectifs)

Les objectifs de CBOR, dans un ordre d'importance à peu près décroissant, sont:

1. La représentation doit pouvoir encoder sans ambiguïté la plupart des formats de données courants utilisés dans les normes Internet.

   • Elle doit représenter un ensemble raisonnable de types de données et de structures de base en utilisant l'encodage binaire. Le terme "raisonnable" ici est largement influencé par les capacités de JSON, avec l'ajout majeur des chaînes d'octets binaires. Les structures prises en charge sont limitées aux tableaux et aux arbres; les boucles et les graphes de type réseau ne sont pas pris en charge.

   • Il n'est pas nécessaire que tous les formats de données soient encodés de manière unique; c'est-à-dire qu'il est acceptable que le nombre "7" puisse être encodé de plusieurs manières différentes.

2. Le code d'un encodeur ou d'un décodeur doit pouvoir être compact afin de prendre en charge des systèmes avec une mémoire, une puissance de processeur et des jeux d'instructions très limités.

   • Un encodeur et un décodeur doivent pouvoir être implémentés avec une très petite quantité de code (par exemple, dans les nœuds contraints de classe 1 tels que définis dans [CNN-TERMS]).

   • Le format doit utiliser des représentations de données machine contemporaines (par exemple, ne nécessitant pas de conversion binaire-décimal).

3. Les données doivent pouvoir être décodées sans description de schéma.

   • Similaire à JSON, les données encodées doivent être auto-descriptives afin qu'un décodeur générique puisse être écrit.

4. La sérialisation doit être raisonnablement compacte, mais la compacité des données est secondaire par rapport à la compacité du code pour l'encodeur et le décodeur.

   • Le terme "raisonnable" ici est limité par JSON comme limite supérieure en taille, et par la complexité d'implémentation maintenant une limite inférieure. L'utilisation de schémas de compression généraux ou de manipulation de bits extensive viole les objectifs de complexité.

5. Le format doit être applicable à la fois aux nœuds contraints et aux applications à grand volume.

   • Cela signifie qu'il doit être raisonnablement économe en utilisation CPU pour l'encodage et le décodage. Ceci est pertinent à la fois pour les nœuds contraints et pour une utilisation potentielle dans des applications avec un très grand volume de données.

6. Le format doit prendre en charge tous les types de données JSON pour la conversion vers et depuis JSON.

   • Il doit prendre en charge un niveau raisonnable de conversion tant que les données représentées sont dans les capacités de JSON. Il doit être possible de définir un mappage unidirectionnel vers JSON pour tous les types de données.

7. Le format doit être extensible, et les données étendues doivent être décodables par les décodeurs antérieurs.

   • Le format est conçu pour des décennies d'utilisation.

   • Le format doit prendre en charge une forme d'extensibilité qui permet le repli afin qu'un décodeur qui ne comprend pas une extension puisse toujours décoder le message.

   • Le format doit pouvoir être étendu à l'avenir par des normes IETF ultérieures.