5. Évolution future de CBOR

Les protocoles qui réussissent évoluent au fil du temps. De nouvelles idées apparaissent, les plates-formes d'implémentation s'améliorent, des protocoles connexes sont développés et évoluent, et de nouvelles exigences issues des applications et des protocoles sont ajoutées. Faciliter l'évolution des protocoles est donc une considération de conception importante pour tout développement de protocole.

Pour les protocoles qui utiliseront CBOR, CBOR fournit quelques mécanismes utiles pour faciliter leur évolution. Les meilleures pratiques à cet égard sont bien connues, en particulier grâce au développement du format JSON et des protocoles basés sur JSON. Par conséquent, ces meilleures pratiques sortent du cadre de la présente spécification.

Toutefois, faciliter l'évolution de CBOR lui-même relève très certainement de son cadre. CBOR est conçu à la fois pour fournir une base stable au développement de protocoles basés sur CBOR et pour pouvoir évoluer.

Comme un protocole qui réussit peut vivre pendant des décennies, CBOR doit être conçu pour des décennies d'utilisation et d'évolution. Cette section fournit quelques orientations pour l'évolution de CBOR. Elle est nécessairement plus subjective que d'autres parties de ce document. Elle est aussi nécessairement incomplète, de peur de se transformer en un manuel de développement de protocoles.

5.1. Points d'extension

Dans la conception d'un protocole, les opportunités d'évolution sont souvent incluses sous la forme de points d'extension. Par exemple, il peut y avoir un espace de points de code qui n'est pas entièrement alloué dès le départ, et le protocole est conçu pour tolérer et accueillir les implémentations qui commencent à utiliser plus de points de code que ceux initialement alloués.

Le dimensionnement de l'espace de points de code peut être difficile car la plage requise peut être difficile à prédire. Il convient de s'efforcer de rendre l'espace de points de code suffisamment grand pour qu'il puisse être lentement rempli sur la durée de vie prévue du protocole.

CBOR a trois points d'extension majeurs :

• l'espace « simple » (valeurs dans le type majeur 7). Sur les 24 valeurs efficaces (et 224 valeurs légèrement moins efficaces), seul un petit nombre a été alloué. Les implémentations qui reçoivent un élément de données simple inconnu peuvent être capables de le traiter en tant que tel, étant donné que la structure de la valeur est effectivement simple. Le registre IANA de la Section 7.1 est le moyen approprié de traiter l'extensibilité de cet espace de points de code.

• l'espace des « étiquettes » (valeurs dans le type majeur 6). Là encore, seule une petite partie de l'espace de points de code a été allouée, et l'espace est abondant (bien que les premiers numéros soient plus efficaces que les suivants). Les implémentations qui reçoivent une étiquette inconnue peuvent choisir de simplement l'ignorer ou de la traiter comme une étiquette inconnue enveloppant l'élément de données suivant. Le registre IANA de la Section 7.2 est le moyen approprié de traiter l'extensibilité de cet espace de points de code.

• l'espace de l'« information additionnelle ». Une implémentation qui reçoit une valeur d'information additionnelle inconnue n'a aucun moyen de poursuivre l'analyse, de sorte que l'allocation de points de code dans cet espace est une étape majeure. Il ne reste également que très peu de points de code.

5.2. Gestion de l'espace d'information additionnelle

L'esprit humain est parfois attiré par le fait de combler de petites lacunes perçues pour rendre quelque chose d'ordonné. Nous nous attendons à ce que les lacunes restantes dans l'espace de points de code pour les valeurs d'information additionnelle attirent de nouvelles idées, simplement parce qu'elles sont là.

La présente spécification ne gère pas l'espace de points de code d'information additionnelle par un registre IANA. Au lieu de cela, les allocations dans cet espace ne peuvent être faites qu'en mettant à jour cette spécification.

Pour une valeur d'information additionnelle de n >= 24, la taille des données additionnelles est typiquement de 2**(n-24) octets. Par conséquent, les valeurs d'information additionnelle 28 et 29 devraient être considérées comme candidates pour des quantités de 128 bits et 256 bits, au cas où il deviendrait nécessaire de les ajouter au protocole. La valeur d'information additionnelle 30 est alors la seule valeur d'information additionnelle disponible pour une allocation générale, et il devrait y avoir une très bonne raison de l'allouer avant de l'attribuer par une mise à jour de ce protocole.