要約

  • IETFのCBORシリアライゼーション草案は2026年9月28日に第09版となった。表紙は、承認された場合にRFC 8949を更新すると記すが、現状は作業部会の最終意見募集段階にあるInternet-Draftだ。
  • 第7節は、今後のタグ定義が自ら定義する型以外の型に影響してはならないという規則を提案する。既存の大整数タグ2と3は例外として残す。
  • 規則自体は第08版にもあった。第09版が明確にしたのは、既存RFCとの関係とIANA登録簿への参照追加の要請であり、採択済みの変更ではない。

既存の型まで触れてよいわけではない

現行のRFC 8949はCBORのデータモデルと符号化を定める。IANAのタグ登録簿には番号ごとの対象データと意味が載る。あるタグを見たデコーダーがそのタグに固有の解釈を行うのは自然だ。しかし、新たな登録を理由に、タグの付いていない整数や別の既存型の意味まで変わるなら、拡張の責任範囲が見えなくなる。

第09版の第7節はそこを区切る。将来のタグは、自分が定義した型以外の型を取り込んだり、修正したり、その他の形で影響を及ぼしたりしてはならないという提案だ。複数のタグが相互に関係する場合は、各定義主体が明示的に同意する余地も残す。単独の拡張が共通データモデルを無断で変えることとは違う。

例外が必要な理由は、大整数の来歴にある。タグ2と3は正負の大整数を表し、RFC 8949では既存の整数型の範囲を広げる役割を持つ。草案はこの既定事実を遡って消さず、明示的に適用外とした。だからといって、次のタグにも同じ権限が引き継がれるわけではない。新しい仕様を読む際は、何を新しく定義し、どの旧型の解釈が変わると主張しているかを分けて確かめたい。

「承認されれば」という二語

第09版の表紙には Updates: 8949 (if approved) が加わった。第10節は、CBORタグ登録簿に第7節への参照を追加し、CDDLの制御演算子 .serial を登録するようIANAに要請する。要請と登録済みの状態を混同してはならない。確認時点の公開タグ登録簿は、登録の基本参照としてなおRFC 8949を挙げている。

また、第08版にも将来のタグを制限する条文と大整数の例外がある。9月にこの考え方が初めて生まれたとの書き方は正確でない。IETFの最近の提出文書一覧が示すのは、28日の改訂と作業部会の最終意見募集という手続き上の位置だ。RFCの発行、IESGの承認、実装の普及はそこから推定できない。

草案は符号化について「preferred-plus」と決定的なシリアライゼーションも整理する。マップの項目を一定の順序でバイト列に並べる規則は、デコード後のマップに意味上の順序を与えない。バイト列の一貫性と型の定義権限は別の論点である。今回の焦点は、新しいタグにどこまで既存の型を動かす力を認めるかに絞られる。

出典