要約

  • 1994年3月のRFC 1590は、電子メールを起点とする「MIME型」を、複数の用途で共有する「メディア型」として整理した。提案はietf-typesの公開リストに出し、二週間後にIANAへの登録とOIDの割り当てを申請できた。
  • 共通の登録簿には多様な名前を載せられる。一方、相手の能力が分からないメールでは、利用環境に合わせた適用指針で、広く扱える少数の形式を勧められた。名前の共有と実装の選択は別の仕事になった。

名前が割れる前に、列に並ぶ

同じ音声データをメールソフトと資料館のシステムが受け取る。片方が独自の名前を付け、もう片方も別名を付ければ、交換するたびに照合表が必要になる。異なる形式が偶然同じ名前を使えば、もっと厄介だ。名前は小さな文字列だが、プログラムに埋め込まれてから直すのは高い。先に公のカウンターで確かめる理由がそこにあった。

以前のRFC 1521は、MIMEでメール本文の形式を説明する仕組みを定めた。非同期のメールでは送信者が相手のソフトウェア能力を知らないことが多い。広く実装された少数の形式を使うほうが読まれやすい。しかし、同じ識別名をメール以外でも使うようになると、メールの慎重な選択を名前の登録全体に押しつけると困る。Jon PostelのRFC 1590は、共通の名前簿を広げる方向に舵を切った。

その意図は呼び名にも表れる。「MIME型」は「メディア型」になった。型と副型の組み合わせが、複数のアプリケーションで同じ形式を指す。登録簿が答えるのは、その名前が何を示すか。受信したプログラムが答えるのは、その形式を自分が処理できるかだ。新しい動画形式に名前を付けても、古いメールソフトの中に動画プレーヤーが湧いてくるわけではない。

提案者はまずietf-typesへ型と副型を送る。提案段階の副型にはx-を使う。公開の場では、名前の分かりやすさ、版やプロファイルの参照、関連するOID、分かっている安全上の問題などを検討する。限定した用途なら、その用途を書いておく。複数の人が同じ名前を見てから、正式な登録へ進む段取りだった。

二週間後、資料をIANAへ送る。RFCは妥当な検討期間を経て登録し、IANAの枝にOIDを割り当て、内容を公開する経路を説明した。申請書には型、副型、必須・任意のパラメータ、符号化、危険、仕様と連絡先を書く。記入欄は地味だが、後から「この名前は何を指していたか」を確かめる場所になる。

公開された完全な仕様がないデータも実際には流通していた。RFC 1590は、そのような場合に特定のソフトウェア製品と版を明記する方法を認めた。「どこかの文書形式」より「この製品のこの版が作るデータ」のほうが確かだ。受け手のソフトが実際に読めるかどうかは、登録名とは別に、その版のバイトを扱う実装にかかっている。

新しい最上位の型を作る場合は、RFCかそれになりうる原稿を用意し、標準化の手続きに入る。既存の型の下に副型を加える場合は、軽い行政手続きが使われる。メール向けに少数の推奨形式を選びたければ、メールの利用条件に即した適用文書で選ぶ。この組み合わせは、共有の引き出しを大きくしながら、各机に置く道具を現場が決めるためのものだ。

RFC 1590の二週間待ちは、名前に一度だけ公の時間を与える。登録簿は衝突を減らす。そこから先、画像を表示し、音を鳴らし、ファイルを解釈するのは動いているプログラムの仕事だ。書類は短い。名前が長く使われるからこそ、その短い書類に意味があった。