1. Introduction
1. Introduction
Le Concise Binary Object Representation (CBOR) [RFC7049] permet l'échange de données structurées sans nécessiter de schéma préalablement convenu. [RFC7049] définit un ensemble de base de types de données ainsi qu'un mécanisme d'étiquetage permettant d'étendre l'ensemble des types de données pris en charge via un registre IANA.
Récemment, une forme simple de tableaux typés de données numériques a suscité de l'intérêt à la fois dans la communauté du graphisme Web [TypedArray] et dans la spécification JavaScript (voir la Section 22.2 (https://www.ecma-international.org/ecma-262/10.0/index.html#sec-typedarray-objects) de [ECMA-ES10]) ainsi que dans les implémentations correspondantes [ArrayBuffer].
Étant donné que ces tableaux typés peuvent transporter des quantités significatives de données, il existe un intérêt à les échanger en CBOR sans devoir convertir longuement chaque nombre du tableau. Cela peut également économiser la surcharge d'espace liée à l'encodage d'un type pour chaque élément d'un tableau.
Ce document définit un ensemble d'étiquettes CBOR interreliées qui couvrent ces tableaux typés, ainsi que des étiquettes supplémentaires pour des tableaux multi-dimensionnels et des tableaux homogènes. Il est destiné à servir de document de référence pour l'enregistrement IANA des étiquettes définies.
Notez qu'une application qui génère du CBOR avec ces étiquettes dispose d'une grande liberté pour choisir des variantes (par exemple, en ce qui concerne l'endianité, le type embarqué (signé vs. non signé), et le nombre de bits par élément) ou même décider si une étiquette définie par cette spécification est utilisée ou non, à la place d'un CBOR plus basique. Contrairement aux variantes de représentation des nombres CBOR individuels, il n'existe pas de représentation pouvant être identifiée comme "préférée". Si un encodage déterministe est souhaité dans un protocole basé sur CBOR utilisant ces étiquettes, le protocole doit définir quelles variantes d'encodage sont utilisées pour chaque cas individuel.
1.1 Terminologie
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The term "byte" is used in its now-customary sense as a synonym for "octet". Where bit arithmetic is explained, this document uses familiar notation from the programming language C [C] (including C++14's 0bnnn binary literals [CPlusPlus]) with the exception of the operator "**", which stands for exponentiation.
The term "array" is used in a general sense in this document unless further specified. The term "classical CBOR array" describes an array represented with CBOR major type 4. A "homogeneous array" is an array of elements that are all the same type (the term is neutral as to whether that is a representation type or an application data model type).
The terms "big endian" and "little endian" are used to indicate a most significant byte first (MSB first) representation of integers and a least significant byte first (LSB first) representation, respectively.