要約

  • RFC 2361 は audio/vnd.wave;codec=... と video/vnd.avi;codec=... により、既存の WAVE／AVI 登録値をインターネットから参照可能にした。IANA は値を割り当てるのではなく再掲する立場だった。
  • 登録値が見つかることは名前の解決であり、本文の一致、デコーダーの実装、連絡先の現存、安全性、再生結果の証明ではない。

受信したファイルに audio/vnd.wave;codec=55 とある。表を引けば MPEG Layer 3 と分かる。端末にも音声再生機能がある。それだけで再生可能と表示したくなるが、ここまでに確認できたのは一つの文字列を一つの登録項目へ結び付けたことだけだ。

ヘッダーが誤っているかもしれない。WAVE の内部が別形式を示すかもしれない。インストール済みデコーダーはその派生形を扱えないかもしれず、壊れたチャンクや巨大な宣言サイズで停止するかもしれない。サンプルを復号できても、アプリケーションが正しい時刻に音を出すとは限らない。名前の精度と処理の成否は別物である。

1998 年の背景には、インターネットより先に蓄積された膨大なマルチメディアがあった。WAVE と AVI はデスクトップ環境で広く使われ、各コーデックには Microsoft が維持してきた番号や FourCC があった。RTSP や Web のようなネットワークアプリケーションが既存資産を扱うには、まず「どのコーデックだと主張されているか」を相互に再現できる名称が必要だった。

6 月に Informational RFC として公開された RFC 2361 は、ビットストリームを再定義しなかった。MIME の vendor tree に外部登録簿への参照を置いた。音声では vnd.wave が WAVE の名前空間を示し、必須の codec パラメータが WAVE Format ID を選ぶ。映像では vnd.avi と同じパラメータが AVI Codec ID を選ぶ。

重要なのは権限の分離である。元の値を割り当て、重複を避けるために管理していたのは Microsoft 側の登録簿だった。MIME はインターネットのメッセージで運べる構文を与え、RFC は対応規則を公開した。現在の IANA ページにも、手続きは「IANA does not assign. Republication of values」と明記されている。IANA のページにあることと、IANA が発行・推奨・監査したことは同義ではない。

WAVE の数値には基数の罠がある。Format ID は16進の登録番号で、パラメータには 0x を付けずにその桁を記す。MP3 の 0x0055 は codec=55 となるが、十進数の55へ変換されたわけではない。これを十進として読み直す実装は、見た目の数字を保ちながら別の値を指す可能性がある。

AVI は数ではなく FourCC を使う。4文字の ASCII、32ビットで、大文字小文字を区別する。CVID と cvid は画面上で似ていても、勝手に同一視できない。文字列の正規化、大小文字変換、空白除去は表示上の親切ではなく、識別子の変更になり得る。

RFC は WAVE ID と FourCC を GUID へ写す方法も示した。固定テンプレートの先頭32ビットへ番号または FourCC 値を入れる。H260 が16進表示では 30363248 に見える例は、DWORD のエンディアンによる並び替えである。同じ規則を使えば、FourCC を扱う実装と GUID を扱う実装が同じ項目を指しているか確認できる。

しかし、この変換は意味を増やさない。計算された GUID は新しいコーデック仕様ではなく、対応するデコーダーの存在も示さない。実行ファイルの出所、権限、脆弱性、入力に対する適合性も含まれない。後年の RFC 4122 が UUID の形式を標準化しても、元の識別子が持たない証拠まで付与されるわけではない。

登録簿自体も時間から自由ではなかった。RFC 2361 は WAVE と AVI の台帳を historical databases と呼ぶ。会社の買収、住所、電話番号、担当者の変更は、元の登録者が通知しない限り古いまま残るのが一般的だった。付録は1998年1月時点の登録値について権威ある一覧だったが、各企業の存続や保守体制を将来まで保証する名簿ではない。

識別子が企業より長く生きることは欠陥ではない。古い媒体を何十年後にも識別するには、その方がよい。だが、残っている登録行から現役の製品、ライセンス窓口、セキュリティ担当、公式デコーダーの存在を逆算してはならない。名前の継続性と管理主体の継続性は別の記録である。

送信者が書いた MIME パラメータは、本文の鑑定結果でもない。受信側はコンテナを解析し、実際のトラックと内部識別子を確認する必要がある。ヘッダーは欠落、誤記、偽装のいずれもあり得る。本文は切断され、複数形式を装い、あるいはパーサーの欠陥を狙うかもしれない。登録照合の成功は、入力されたトークンに登録上の意味があることだけを示す。

後の RFC 6381 は、別のコンテナ型メディアに複数形の codecs パラメータを定め、宣言と本文が食い違えば実体側が決定的だとした。全トラックが部分的な再生に必須とは限らないことも認めている。これは RFC 2361 の単数構文を更新する文書ではない。それでも、ラベルが検査の代わりにはならないという問題が後代にも残ったことを示す。

ローカル能力にはさらに独立した台帳が要る。パッケージがあること、アプリがそれを選ぶこと、初期化に成功すること、特定プロファイルを解くこと、出力を利用者へ提示することは順番の異なる事実である。バージョン、配布元、対応するビット深度、サンドボックス、メモリと時間の上限は FourCC から得られない。

RTSP や HTTP の成功も穴を埋めない。セッションを制御できた、オブジェクトを取得できた、パケットが届いたという記録は、デコードや同期、視聴の記録ではない。WAVE／AVI の名前は、伝送対象を話題にするための座標であって、伝送や再生の受領証ではなかった。

RFC のセキュリティ節は短いが、責任範囲を明快にした。文書は形式を登録するだけで、各形式のセキュリティ問題には対処しない。よって登録ヒットを、プラグインの自動取得、権限の高いネイティブコードの実行、無制限の解析に対する許可として使えない。

実務上は、受信した Content-Type の生データ、参照した登録簿の版、16進または FourCC の解釈、GUID 変換、本文検査、矛盾、実デコーダーと由来、隔離判断、デコード試行、出力トラック、提示結果を別々に残すべきだ。各段階の成功は、次の段階の成功を先取りしない。

RFC 2361 が歴史に残したのは万能な互換性ではなく、限定された連邦である。インターネットは、自らが統治しない既存の名前空間を正確に参照できるようになった。参照しただけで、その割当権、実装、結果まで所有したことにはならなかった。