要約

  • RFC 1049 は、PostScript、TeX、TROFFなど構造を持つメール本文のためにContent-Typeを提案した。本文は当時のASCIIメールの範囲で運び、受信側の閲覧ソフトが適切な表示処理を選べる。
  • 形式名に版と参照資源を添える仕組みも用意された。受信者の処理能力を自動で確かめる手段がない段階では、送信者が対応相手を自分で覚えておく。RFC 2045 は後にこの欄をMIME向けに拡張した。

文書を一文字も落とさず届けても、相手が文書として読めるとは限らない。1988年の受信箱にPostScriptの本文が届けば、普通のメール画面は命令文を律儀に並べる。数式や字組みを楽しんでほしかった送り手に対し、受け手は舞台裏の台本を渡される。RFC 1049 は、そのすれ違いをメールの見出しで減らそうとしたMartin Sirbuの提案だ。

RFC 822に沿うメールには見出しとASCII文字の本文があった。そこへ利用者はTROFF、TeX、Scribe、SGML、DVI、PostScriptなどを入れ始めていた。文字としては運べても、見せたい紙面を作るには別のプログラムがいる。Content-Typeがあれば、閲覧ソフトは本文の仕組みを知り、ふさわしい処理系に渡せる。郵便経路は従来どおり文字を運び、受信側で表示の仕事を引き受ける。

Sirbuの札は単なる「特殊な文書」ではない。先頭にPOSTSCRIPTやTROFFなどの形式名、必要なら版番号、参照する資源、コメントを置く。二者間で使うX-形式にも余地がある。資源の例にはPostScript向けのLaserPrepの版、TROFFで使うeqn、tbl、meが挙がる。料理名を知っていても、調理器具がなければ献立は完成しない。参照資源の欄は、その依存関係を本文と一緒に運ぼうとする工夫だった。

ここで受け手の能力という厄介な問題が現れる。解釈プログラムのない機械にもASCIIのメールは届き、画面には生の命令が並ぶ。送り手は誰の機械が何を読めるか、どう知ればよいのか。RFCは三つの案を検討した。各送信システムが遠隔地の能力を記録する、SMTPで交渉して必要なら変換する、ディレクトリに受信側の能力を載せる。記録は古くなり、交渉は既存のメール転送ソフトを変え、ディレクトリ案は送信と名前解決の仕事を増やす。それぞれ別の場所に費用が生じる。

試験を始めるために選ばれたのは、妙に手作業の答えだった。送り手が相手ごとの対応形式を私的な一覧で管理する。文書には標準化された札が付き、人間は友人の道具箱の目録を持つ。RFCは有効な欄を見た閲覧ソフトの具体的な動作も一律には決めなかった。形式を認識すること、解釈プログラムを持つこと、きれいに表示することは、それぞれ別の仕事である。

後のRFC 2045 は、MIMEのContent-TypeをRFC 1049から一般化したものと明記する。MIMEでは媒体の型と副型、パラメータに加え、MIME-VersionやContent-Transfer-Encodingが本文の表現を細かく説明する。1996年の仕様は1988年の構文を簡素で、おおむね互換性があると評した。その出発点にあるのは、本文の正体を機械に伝える作業と、相手がそれを扱えるかを知る作業の分担だった。

小さな札のおかげで、受信者は画面の命令文から形式を当てるゲームをせずに済む。次に問われるのは、解釈プログラム、版、補助資源がそろっているか。しばらくの間、いちばん頼れる能力データベースは「送信」を押す人の記憶の中にあった。