5. CBOR の将来の進化

成功したプロトコルは時間とともに進化します。新しいアイデアが現れ、実装プラットフォームが改善し、関連するプロトコルが開発されて進化し、アプリケーションやプロトコルからの新しい要件が追加されます。したがって、プロトコルの進化を促進することは、あらゆるプロトコル開発において重要な設計上の考慮事項です。

CBOR を使用するプロトコルに対して、CBOR はその進化を促進するための有用なメカニズムをいくつか提供します。このためのベストプラクティスは、特に JSON ベースのプロトコルにおける JSON 形式の開発から、よく知られています。したがって、そのようなベストプラクティスは本仕様の範囲外です。

しかし、CBOR 自体の進化を促進することは、まさにその範囲内です。CBOR は、CBOR ベースのプロトコルの開発に対して安定した基盤を提供するとともに、自身が進化できるように設計されています。

成功したプロトコルは数十年にわたって存続する可能性があるため、CBOR は数十年にわたる使用と進化を念頭に設計される必要があります。このセクションは、CBOR の進化に関するいくつかの指針を提供します。それは必然的に、この文書の他の部分よりも主観的です。また、プロトコル開発の教科書にならないよう、必然的に不完全です。

5.1. 拡張ポイント

プロトコル設計において、進化の機会はしばしば拡張ポイントという形で組み込まれます。例えば、最初から完全には割り当てられていないコードポイント空間が存在し、最初に割り当てられたよりも多くのコードポイントを使い始める実装を許容し、受け入れるようにプロトコルが設計されている場合があります。

コードポイント空間のサイズ決定は困難な場合があります。必要となる範囲を予測するのが難しいかもしれないからです。プロトコルの想定される寿命にわたってゆっくりと埋められていくよう、コードポイント空間を十分に大きくすることが試みられるべきです。

CBOR には 3 つの主要な拡張ポイントがあります:

• "simple" 空間 (主タイプ 7 の値)。24 個の効率的な (および 224 個のやや効率の劣る) 値のうち、ごく少数しか割り当てられていません。未知のシンプルデータ項目を受信した実装は、その値の構造が実際にシンプルであることを前提として、それをそのまま処理できる可能性があります。セクション 7.1 の IANA レジストリが、このコードポイント空間の拡張性に対処する適切な方法です。

• "tag" 空間 (主タイプ 6 の値)。これも、コードポイント空間のごく一部しか割り当てられておらず、空間は豊富にあります (ただし、初期の番号のほうが後期の番号より効率的です)。未知のタグを受信した実装は、それを単に無視するか、後続のデータ項目を包む未知のタグとして処理するかを選択できます。セクション 7.2 の IANA レジストリが、このコードポイント空間の拡張性に対処する適切な方法です。

• "追加情報" 空間。未知の追加情報値を受信した実装には解析を続行する手段がないため、この空間へのコードポイントの割り当ては大きな一歩です。また、残っているコードポイントもごくわずかです。

5.2. 追加情報空間の管理

人間の心は、ときとして、物事を整然としたものにするために、認識された小さな隙間を埋めようと引き寄せられます。追加情報値のコードポイント空間に残されている隙間は、ただそこにあるという理由だけで、新しいアイデアを引きつけるものになると予想されます。

本仕様は、追加情報のコードポイント空間を IANA レジストリでは管理しません。代わりに、この空間からの割り当ては、本仕様を更新することによってのみ行うことができます。

n >= 24 の追加情報値の場合、追加データのサイズは通常 2**(n-24) バイトです。したがって、追加情報値 28 と 29 は、プロトコルに追加する必要が生じた場合に備えて、128 ビット量および 256 ビット量の候補と見なされるべきです。すると追加情報値 30 が、一般的な割り当てに利用できる唯一の追加情報値となり、本プロトコルの更新を通じて割り当てる前にそれを割り当てるには、非常に良い理由がなければなりません。