メインコンテンツまでスキップ

1. Introduction (はじめに)

構造化データのバイナリ表現 (バイナリシリアライゼーションフォーマットとしても知られています) のための標準化されたフォーマットは数百種類存在します. そのうち, いくつかは特定の情報ドメイン用であり, 他のものは任意のデータ用に一般化されています. IETF では, 後者のカテゴリで最もよく知られているフォーマットは, おそらく ASN.1 の BER と DER [ASN.1] です.

ここで定義されるフォーマットは, 現在のフォーマットでは十分に満たされていない特定の設計目標に従っています. 基盤となるデータモデル (Data Model) は, JSON データモデル [RFC8259] の拡張版です. これは RFC 8259 の文法を一般的に拡張する提案ではないことに注意することが重要です. そうすることは, すでに展開されている JSON ドキュメントとの重大な後方互換性の問題を引き起こすためです. 代わりに, この文書は JSON から始まる独自のデータモデルを定義するだけです.

附録 E は, いくつかの既存のバイナリフォーマットをリストし, Concise Binary Object Representation (CBOR, 簡潔バイナリオブジェクト表現) の設計目標にどの程度適合または不適合であるかを議論しています.

この文書は [RFC7049] を廃止し, 編集上の改善, 新しい詳細, および誤記訂正を提供しながら, RFC 7049 の交換フォーマットとの完全な互換性を維持します. フォーマットの新しいバージョンは作成しません.

1.1. Objectives (目標)​

CBOR の目標は, おおよそ重要度の降順に次のとおりです:

  1. 表現は, インターネット標準で使用される最も一般的なデータフォーマットの大部分を明確にエンコードできなければなりません.

    • バイナリエンコーディングを使用して, 合理的な基本データ型と構造のセットを表現しなければなりません. ここでの "合理的" は, 主に JSON の機能に影響され, バイナリバイト文字列 (Byte String) の主要な追加があります. サポートされる構造は配列 (Array) とツリー (Tree) に制限されます; ループ (Loop) と格子状グラフ (Lattice-Style Graph) はサポートされません.

    • すべてのデータフォーマットが一意にエンコードされる必要はありません; つまり, 数値 "7" が複数の異なる方法でエンコードされることは許容されます.

  2. エンコーダ (Encoder) またはデコーダ (Decoder) のコードは, 非常に限られたメモリ, プロセッサパワー, および命令セットを持つシステムをサポートするためにコンパクトである必要があります.

    • エンコーダとデコーダは, 非常に少量のコードで実装可能である必要があります (例えば, [RFC7228] で定義されているクラス 1 制約ノード (Class 1 Constrained Node) で).

    • フォーマットは, 現代のマシンのデータ表現を使用する必要があります (例えば, バイナリから十進数への変換を必要としない).

  3. データは, スキーマ記述 (Schema Description) なしでデコード可能である必要があります.

    • JSON と同様に, エンコードされたデータは自己記述的 (Self-Describing) である必要があり, 汎用デコーダを作成できるようにします.

  4. シリアライゼーションは合理的にコンパクトである必要がありますが, データのコンパクトさはエンコーダとデコーダのコードのコンパクトさに次ぐものです.

    • ここでの "合理的" は, サイズの上限として JSON によって制限され, 実装の複雑さによって制限されます. これにより, そのコンパクトさを達成するために投入できる努力の量が制限されます. 一般的な圧縮スキームまたは広範なビット操作の使用は, 複雑さの目標に違反します.

  5. フォーマットは, 制約ノード (Constrained Node) と大容量アプリケーションの両方に適用可能である必要があります.

    • これは, エンコードとデコードの両方で CPU 使用量が合理的に節約される必要があることを意味します. これは, 制約ノードと非常に大量のデータを持つアプリケーションでの潜在的な使用の両方に関連しています.

  6. フォーマットは, JSON との間の変換のために, すべての JSON データ型をサポートしなければなりません.

    • 表現されるデータが JSON の機能の範囲内である限り, 合理的なレベルの変換をサポートしなければなりません. すべてのデータ型に対して JSON への単方向マッピングを定義できなければなりません.

  7. フォーマットは拡張可能である必要があり, 拡張されたデータは以前のデコーダによってデコード可能である必要があります.

    • フォーマットは数十年の使用を想定して設計されています.

    • フォーマットは, 拡張を理解しないデコーダでもメッセージをデコードできるように, フォールバック (Fallback) を可能にする拡張性の形式をサポートしなければなりません.

    • フォーマットは, 将来の IETF 標準によって拡張できなければなりません.

1.2. Terminology (用語)​

この文書のキーワード "MUST" (しなければならない), "MUST NOT" (してはならない), "REQUIRED" (必須), "SHALL" (するものとする), "SHALL NOT" (しないものとする), "SHOULD" (すべきである), "SHOULD NOT" (すべきでない), "RECOMMENDED" (推奨される), "NOT RECOMMENDED" (推奨されない), "MAY" (してもよい), および "OPTIONAL" (オプション) は, BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈されるものとします. ただし, ここに示すようにすべて大文字で表示される場合に限ります.

用語 "byte" (バイト) は, "octet" (オクテット) の同義語として現在慣習的に使用されています. すべてのマルチバイト値は, ネットワークバイトオーダー (Network Byte Order) でエンコードされます (つまり, 最上位バイトが最初で, "ビッグエンディアン" (Big-Endian) としても知られています).

この仕様では, 次の用語を使用します:

Data item (データ項目): 単一の CBOR データ. データ項目の構造には, ゼロ, 1 つ, または複数のネストされたデータ項目が含まれる場合があります. この用語は, 表現フォーマット内のデータ項目と, デコーダによってそこから導き出せる抽象的な概念の両方に使用されます; 前者は, "encoded data item" (エンコードされたデータ項目) という用語を使用することで特に扱うことができます.

Decoder (デコーダ): 整形式のエンコードされた CBOR データ項目をデコードし, それをアプリケーションで利用可能にするプロセス. 正式には, デコーダには, CBOR の構文規則を使用して入力を分解するパーサー (Parser) と, アプリケーションに適した形式でデータを準備するセマンティックプロセッサ (Semantic Processor) が含まれます.

Encoder (エンコーダ): アプリケーション情報から CBOR データ項目の (整形式の) 表現フォーマットを生成するプロセス.

Data Stream (データストリーム): ゼロ個以上のデータ項目のシーケンスで, より大きな含有データ項目にさらに組み立てられないもの ([RFC8742] の 1 つのアプリケーションを参照). データストリームを構成する独立したデータ項目は, "top-level data items" (トップレベルデータ項目) とも呼ばれることがあります.

Well-formed (整形式): CBOR の構文構造に従うデータ項目. 整形式のデータ項目は, CBOR で定義されているようにその値によって暗示される初期バイトとバイト文字列および/またはデータ項目を使用し, 後続の無関係なデータを含みません. CBOR デコーダは, 定義上, 整形式のデータ項目からのみコンテンツを返します.

Valid (有効): 整形式であり, かつ CBOR データ項目に適用されるセマンティック制限に従うデータ項目 (セクション 5.3).

Expected (期待される): 通常の英語の意味に加えて, "expected" という用語は, アプリケーションが入力データに対して持つ CBOR 有効性を超える要件を記述するために使用されます. Well-formed (まったく処理可能), valid (有効性チェック汎用デコーダによってチェック), および expected (アプリケーションによってチェック) は, 受容性の階層レイヤーを形成します.

Stream decoder (ストリームデコーダ): データストリームをデコードし, シーケンス内の各データ項目を受信時にアプリケーションで利用可能にするプロセス.

Infinity, NaN (非数), 負のゼロ (Negative Zero), および非正規数 (Subnormal) などの浮動小数点値の用語と概念は, [IEEE754] で定義されています.

ビット演算またはデータ型が説明される場合, この文書はプログラミング言語 C [C] に慣れ親しんだ表記法を使用しますが, ".." は両端を含む範囲を示し, 上付き表記は指数を示します. たとえば, 2 の 64 乗は次のように表記されます: 2^(64). この仕様のプレーンテキストバージョンでは, 上付き表記は使用できないため, 代替表記法で表現されます. その表記法はこの RFC に最適化されていません; 残念ながら C の排他的論理和と曖昧です (これは附録でのみ使用され, 附録では指数を使用しません) ので, プレーンテキストバージョンの読者には慎重さが求められます.

例と疑似コードは, 符号付き整数が 2 の補数表現を使用し, 符号付き整数の右シフトが符号拡張を実行することを前提としています; これらの仮定は, C++ 2020 バージョン (現在最終草案として入手可能, [Cplusplus20]) のセクション 6.8.1 (basic.fundamental) および 7.6.7 (expr.shift) でも指定されています.

16 進数の "0x" 表記と同様に, 2 進数表記の数値には "0b" が前置されます. 可読性のためだけに数値にアンダースコアを追加できるため, 0b00100001 (0x21) は 0b001_00001 と書いて, バイト内のビットの望ましい解釈を強調することができます; この場合, 3 ビットと 5 ビットに分割されています. エンコードされた CBOR データ項目は, "0x" または "0b" 表記で示されることがあります; これらの値は最初に C のように数値として解釈され, 次に表記で表現されたすべての先頭ゼロバイトを含めて, ネットワークバイトオーダーのバイト文字列として解釈されます.

単語は強調のために イタリック体 で表示される場合があります; この仕様のプレーンテキスト形式では, これは単語をアンダースコア文字で囲むことによって示されます. 逐語的テキスト (例: プログラミング言語の名前) は "等幅" タイプで設定される場合があります; プレーンテキストでは, これはテキストを二重引用符で囲むことによって多少曖昧に近似されます (二重引用符は通常の意味も保持します).

に最終更新