要約

  • RFC 9876は、Media Type、パラメータ、任意のContent Codingの組合せを意味の面から審査し、希少・一般・文書用・実験用の番号帯に異なる方針を割り当てた。
  • 番号の承認は共有レジストリ上の対応関係を作るが、実際のバイト列、パーサ、交渉、資源上限、失敗時の挙動、製品間の一致を試験するものではない。
  • 誠実な運用では、割当て受領書と配備受領書を接続しながら、レジストリに製品認証の役割を持たせない。

センサーが整数293を送る。受信側はレジストリを引き、対応するCoAP Content-Formatを得る。長い型名、パラメータ、Content Codingを毎回送らないからこそ、低帯域で損失の多い環境に利点がある。

問題は、メッセージの圧縮が判断の省略に変わるときだ。「IANAに番号があるから相互運用できる」「指定専門家が認めたから、どんな入力でも安全だ」「二社が同じ番号を掲げるから意味も同じだ」。

RFC 9876が証明するのは、そのどれでもない。実装が協調を始めるための公共記録を、以前より正確にする規格である。

一つの整数が複数の登録を結ぶ

RFC 7252のCoAPは、メモリの小さいノードと低速・高損失のネットワークを想定した。数値Content-Formatは表現を短く示す。RFC 9876は、各行がContent Type、任意のContent Coding、基礎となるMedia Type、数値ID、そしてペイロードの意味を説明する参照文献を持つよう明確にした。

これらは同義語ではない。Media Typeは形式の族を示し、パラメータはその内部のプロファイルや意味を選ぶ。Content Codingは表現を変換する。CoAPにはCodingを別に伝える欄がないため、同じMedia Typeでも異なるCodingなら別IDが必要になる。

旧手続きは、この組合せが意味として成立するかを明示的に確認させていなかった。未知の型、未定義パラメータ、許されない値、未登録Coding、別表記の論理的重複が、見た目だけ整った申請として通り得た。RFC 9876は、この判断が複数の文書と技術をまたぎ、登録事務だけに任せられないと認めた。多くの番号帯に、明示的チェックリストを持つExpert Reviewを導入した。

制度上の改善は、申請書を処理できることと、その組合せに意味があることを別の仕事として扱った点にある。

番号帯は政策を表す

0から65535は一様な空間ではない。0–255は1バイトで表せる希少領域であり、Expert Reviewに加えて、その短い番号を使う妥当性も考慮される。256–9999はIETF ReviewとExpert Review、またはIESG ApprovalとExpert Reviewを要する。10000–19999と33000–64997も専門家審査を受ける。

20000–32999だけは狭いFirst Come First Servedの経路を残す。パラメータとContent Codingがなく、Media Typeが登録済みまたは承認済みで、CoAP表に未登録である場合に限られる。複雑な申請がこの経路で審査を避けることはできない。

64998と64999は文書例専用である。65000–65535は実験用で、運用利用は認められない。例示や試験が、長く使われたという理由だけで本番の権威を得ないための境界だ。

小さな番号は所有権でも品質章でもない。希少な協調資源である。大きな番号が劣るわけでもない。番号帯が示すのは決定手続きであって、製品の評価ではない。

専門家が閉じる誤った入口

審査はまず、同じContent-TypeとContent Codingの組合せが既にないかを見る。Media Typeが登録・承認済みか、許された番号帯でprovisional登録されているかを確認する。パラメータ名と値は当該Media Typeで定義され、CodingはHTTPの登録に存在または承認されていなければならない。Content Typeの表記も推奨形に直される。

正規化は、書き方と意味を分ける。大文字小文字を区別しない要素は小文字にし、必要な場合だけ値を引用し、区切りのセミコロン周辺に空白を置かない。RFC 9876の例はさらに、既定値の明記と省略、identityとCodingなし、大小文字の異なるが同義のURNが重複になり得ることを示す。

専門家は文字列比較を超えて意味を追う。それでも製品試験所ではない。全エンコーダを動かし、全パーサに悪意ある入力を与え、全マイコンのメモリを測るわけではない。登録は「この正確な組合せを、この方針で共有名前空間に入れてよいか」を答える。相互運用試験は「このバージョン同士が、この条件で正しく交換・処理できるか」を答える。

二つを混ぜれば、IANAと専門家に制御できない認証責任を負わせ、ベンダーには自らの証拠を番号で代替する余地を与える。

Temporaryは寿命の状態である

RFC 9876は一時登録の遷移を見えるようにした。provisional Media Typeを使うContent-Formatは一時的である。必要な手続きが完了してMedia Typeが恒久化すれば、一時表示を外せる。手続きが失敗するか provisional型が放棄されれば、行を削除し、番号をUnassignedに戻せる。

現在のIANA表はこの仕組みを実例で示す。本調査時点では、provisional型に結び付く293と294などの一時IDが、恒久行、未割当て、文書用、実験用と並んでいる。これは状態の証拠であり、普及率ではない。一時形式が危険だとも、特定製品が対応済みだとも言わない。

一時番号を製品に入れるなら、追随するドラフトとMedia Type記録、期限、恒久化経路、撤回時の挙動を残す必要がある。整数だけをデータベースに保存すれば、後の移行に必要な出自が消える。

番号帯ごとの差も重要だ。標準化完了や登録文書を要求しない帯では、文書が停止しても自動削除にはならない。ドラフト失効を、あらゆる番号に共通する取消し規則にしてはならない。

二つの受領書で権威の水増しを防ぐ

割当て受領書は、正規化されたContent Type、基礎Media Type、パラメータ、Content Coding、申請・割当て番号帯、審査方針、決定、意味の参照、一時・恒久状態、日付、希少番号の理由を保存する。同義として退けた表記も残し、綴りを変えた重複を防ぐ。

配備受領書は別の事実を記録する。エンコーダとデコーダのバージョン、試験したパラメータ、Coding前後のバイト、交渉、未知・失効・再割当てIDの処理、サイズや再帰の制限、CoAP/HTTPゲートウェイ、テストベクトル、失敗、ロールバックである。

二つはIDと正確な組合せで接続するが、融合させない。割当てが正しくても、個別デコーダは壊れ得る。調達が両方を求めるのは合理的だが、IANAが機器を認証したことにはならない。

この二受領書モデルは本稿の編集・運用上の提案であり、RFC 9876のフィールドでもIANA要件でも、既知の配備事実でもない。

レジストリは自らの決定だけを映す

Lu HengのMinimum Initial Specificationは適切な大きさを示す。安定ID、正確な組合せ、意味の参照、監査可能な手続きがあれば、各実装は独立に動ける。全パーサと製品版を中央管理する必要はない。

The Policy Mirrorは限界を示す。行は、所定の方針で割当てが決まった事実を映せる。全機器の安全性、採用規模、実装品質、二端点の互換性までは映せない。それらには別の権限と証拠が必要だ。

RFC 9876は、無効な組合せや意味上の重複が入りにくい鏡を作った。次に実装者が守るべきことは、正しく割り当てられた番号を、動作が証明済みのシステムと取り違えないことだ。

出典