要約

  • Jon PostelのRFC 807は、1982年1月に開かれたマルチメディアメールの会議を記録した。受信機にLPCボコーダーなどの再現装置がなければ、データが存在することとその種類を利用者に知らせる、というのが会議のおおむねの考えだった。
  • 白黒ビットマップの交換にはCCITT T.4符号化を使うことで合意した。初期実験はRFC 759の文書を丸ごとファイルで運び、文字にはRFC 767の段落形式を使う。部分ごとのポインタや中継をまたぐ交渉は研究課題に残した。

メールを開くと文章と絵があり、音声データも入っている。ところが受信側の計算機には、その音を鳴らす装置がない。黙って音声部分を消すのか。それとも「この種類のデータは届いているが、ここでは再現できない」と伝えるのか。1982年1月12日、南カリフォルニア大学Information Sciences Instituteに集まった研究者は後者を選んだ。翌月Jon PostelがまとめたRFC 807に、その考えが記されている。冒頭のメールは例えだが、装置のない受信機は議事録の問題そのものだ。

参加した研究室の機材はばらばらだった。CMUはPERQとファクス、LPCボコーダーを扱い、ISIはTOPS20とPERQ、Rapicom 450を試していた。MITのApolloにはまだ必要なネットワーク接続がそろわない。COMSATはファクスの符号化を進め、BBNは配布とプライバシー、UCLはビットマップの加工、SRIは安全性と文字・図形の混在を調べていた。同じメッセージの形式に合意しても、同じスピーカーや表示装置が研究室に生えるわけではない。

議事録の「装置の違い」は、利用者の目の前で起きる問題を問う。LPCボコーダーを持たない受信機が音声データを受け取ったらどうするか。会議では、再現できないデータがあると利用者に知らせ、その種類を示すのがよいと考えられた。何種類の標準形式を設けるか、媒体ごとにメモリ、計算時間、表示や再生時間がどれだけかかるかは今後の課題だった。少なくとも、バイト列が届いた事実と人が内容を聞ける事実は別々に扱った。

共有できるところでは共有した。白黒ビットマップの交換用符号化にはCCITT T.4を選んだ。予定された実験では、改訂版COMSAT画像形式に生のビットマップかCCITT方式で圧縮した画像を入れる。機械が異なっても画像データの読み方を合わせるための決定だ。しかし共通の符号は、音声再生のためのハードウェアまで作ってくれない。

もっと賢そうな案もあった。まずメッセージ各部分へのポインタだけを送り、受信機が扱える部分だけ要求する。中継機を挟んだら、そのやり取りはどうなるか。文字、画像、音声が細かく入り交じる文書では、どこを切り出すのか。添付や相互参照まで考えると、その会議では収まらなかった。そこで最初の実験では文書を丸ごと送ることにした。美しい選択式の転送より、まず別の研究室に一通届くことを優先したのである。

試す内容は明確だった。利用できる方法でファイルを転送し、中身は完全なRFC 759文書とする。文章はRFC 767の段落形式、画像は改訂版COMSAT形式で、生またはT.4符号化を使う。全参加拠点にはファクスと文字の文書交換を1982年4月19～20日に実演する課題が割り当てられた。議事録が示すのは期限と担当であり、実演結果ではない。National Bureau of Standardsの別のメール形式との比較も宿題になった。

編集の方法は各拠点が開発して後で比べる。画像の拡大縮小や回転、メールボックスの識別、保存と転送の費用、文字だけの既存メールとの接続も調べる。共有の土台は狭く、現場の差はそのまま研究対象だった。1982年の参加者が最も確かに言えたのは、受け取ったものを受け取ったと伝え、再現できない部分も名指しすることだった。

届いた音声を鳴らせない計算機は、少なくとも何が黙っているのかを知らせられる。その一言は、万能な形式を夢見るより利用者に親切だ。マルチメディアメールはまず、機械の能力差を隠さずに運ぶ方法を探していた。