Appendix A. Frequently Asked Questions (よくある質問)

A.1 Why Not JSON? (なぜJSONではないのか?)

初期の構造化フィールド提案はJSON [RFC8259]に基づいていました。しかし、HTTPヘッダーフィールドに適するようにその使用を制約するには、送信者と受信者が特定の追加処理を実装する必要がありました。

問題1: 正規化の問題

JSONは大きな数値と重複メンバーを持つオブジェクトに関して正規化の問題があります。

// 問題: 大きな数値
{"value": 9007199254740993}  // JavaScriptの安全な整数範囲を超える

// 問題: 重複キー
{"key": "value1", "key": "value2"}  // 動作が未定義

これらの問題を回避する推奨事項（例：[RFC7493]）はありますが、確実に依存することはできません。

問題2: Unicode文字列

JSON文字列はデフォルトでUnicode文字列であり、これには多くの潜在的な相互運用性の問題があります（例：比較において）。

// 異なるUnicode表現が問題を引き起こす可能性
"café"  // é as single character
"café"  // é as e + combining accent
// これら2つは同じように見えるがバイナリが異なる

不必要な場所で非ASCIIコンテンツを避けるよう実装者に提案することは可能ですが、これを強制することは困難です。

問題3: 任意のネスト深度

JSONはコンテンツを任意の深さにネストできます。

{
  "a": {
    "b": {
      "c": {
        "d": {
          // ... 無限の深さ
        }
      }
    }
  }
}

結果:

• メモリコミットメントが不適切な場合がある（例：組み込みおよびその他の制約のあるサーバー展開）
• 何らかの方法で制限する必要がある
• 既存のJSON実装にはそのような制限がない
• 制限が指定されていても、一部のフィールド定義では違反する必要がある場合がある

問題4: 実装の誘惑

JSONは広く採用され実装されているため、すべての実装に追加の制約を課すことは困難です。一部の展開ではそれらを強制できず、相互運用性が損なわれます。

簡単に言えば: JSONのように見える場合、人々はフィールド値にJSONパーサー/シリアライザーを使用する傾向があります。

結論

構造化フィールドの主な目標が相互運用性の改善と実装の簡素化であるため、これらの懸念により、専用のパーサーとシリアライザーを必要とする形式が採用されました。

さらに、JSONがHTTPフィールドで「正しく見えない」という広範なコンセンサスがありました。

---

比較まとめ

機能	JSON	RFC 8941
数値範囲	不確定（実装依存）	明確に定義（15桁整数）
小数精度	不確定	3桁小数
Unicode	デフォルトサポート	ASCIIのみ（Byte Sequenceで可能）
ネスト深度	無制限	2層に制限
重複キー	未定義	明示的に禁止
型システム	緩い	厳格
パーサー複雑度	高（追加制約が必要）	中（専用だが単純）
HTTP適合性	悪い	優れている

---

実用例

JSON方式（問題あり）

Example-Header: {"priority": 1, "timeout": 3.14159, "enabled": true}

問題:

• 数値精度の不確実性
• パーサー間の一貫性がない
• HTTPには「見た目が悪い」

RFC 8941方式（推奨）

Example-Header: priority=1, timeout=3.142, enabled

利点:

• ✅ 明確な型定義
• ✅ 予測可能な動作
• ✅ HTTPに自然に適合
• ✅ 実装が簡単
• ✅ 相互運用性が高い

---

重要なポイント

1. JSONは汎用的すぎる: HTTPフィールドには不必要な機能が多すぎる
2. 制約は困難: JSONのように見えるものにJSON以外のルールを強制するのは困難
3. 専用形式が最適: HTTPフィールド専用に設計された形式が最良の相互運用性を提供
4. 見た目も重要: 構文はHTTPの既存の慣例に適合すべき

---