要約

  • RFC 9876 は、誤った組合せを許した旧手続を改め、CoAP Content-Format の多くに意味上の確認と専門家審査を導入した。
  • 登録は番号、Media Type、パラメータ、Content Coding の対応を調整するが、デコーダーや送信者、用途、結果を保証しない。
  • 本番採用には、実装版、プロファイル、保護、資源上限、認可、観測、ロールバックを含む別の証拠が必要である。

保守拠点に届いた小型端末は、IANA に存在する Content-Format を送っていた。検証環境では読める。ところが現場の二世代前のゲートウェイは、同じ番号を別のライブラリへ渡す。共通番号は、共通挙動の証明ではなかった。

RFC 9876 は 2025 年 10 月の IETF Proposed Standard で、RFC 7252 の登録手続を更新する。CoAP Content-Format は Media Type と任意のパラメータ、Content Coding を一つの符号なし整数で表す。省帯域の利点と、誤対応が小さな番号だけで広がる危険は同じ仕組みから生じる。

審査が守る範囲

旧 FCFS では、申請された Content-Type と Content Coding の組合せが意味上成立するかを明示的に確かめなかった。RFC 9876 は誤登録が発生したと記す。新制度は単なる重複確認ではなく、公開された判断項目を置く。

IANA CoRE Parameters では、0–255 は希少なため Expert Review、256–9999 は IETF Review と Expert Review、または IESG Approval と Expert Reviewを要する。10000–19999 と 33000–64997 も専門家審査である。

FCFS の 20000–32999 は、既登録の Media Type だけを使い、パラメータも Content Coding もなく、その Media Type が未使用の場合に限られる。64998–64999 は文書用、65000–65535 は実験用で、本番運用には使えない。

専門家は重複、Media Type の登録状態、パラメータ名と値、表記、Content Coding の登録を確認する。短い番号の消費も評価対象になる。この合格は特定申請が基準を満たした証拠である。受信側のメモリ安全性、実装互換性、鍵の信頼、制御機器の権限までは対象ではない。

一時登録には期限と版がある

Media Type が provisional なら Content-Format も一時登録となる。必要な手続と Media Type の恒久登録が完了すると印が外れ、放棄された場合は区分ごとの規則に従い Unassigned に戻り得る。

その変更は配布済みファームウェアを書き換えない。キャッシュされた表、更新停止製品、長期保存データには古い対応が残る。RFC 8126 も、専門家審査はある時点の特定文書版に対するものだとする。後の大幅変更には再審査が必要になり得る。「承認済み」だけでは証拠の範囲を再現できない。

数字は別の容器にも入る

RFC 9193 は SenML のバイナリ値に CoAP Content-Format 番号を付けられるようにする。元の文脈を持たない中継者にも解釈の手掛かりが届く一方、古い対応もブローカー、保存庫、分析処理へ持ち越される。

運用状態は、レジストリ既知、ハンドラー導入済み、プロファイル対応、保護確認済み、内容妥当、ローカル認可済み、効果観測済みに分けるべきだ。unknown、unsupported、invalid を一つにすると、互換性問題と攻撃と設定漏れを区別できない。

追加された Media Type 列は出典を追いやすくするが、送信者を信用させるものではない。正しく型付けされたデータでも改ざんされ得る。署名が正しくても鍵が許可されていない場合がある。妥当な測定でも、装置を動かす権限を持つとは限らない。

番号は候補デコーダーを選ぶ。版管理されたプロファイルが意味を確認し、セキュリティ層が出所と完全性を確認し、現場ポリシーが動作を決める。最後に実際の効果を観測する。登録はその最初の接続点である。