要約

  • RFC 910 は1984年7月のマルチメディアメール会議の記録である。BBNはJerichoワークステーション上でDiamondの初期実装を完成し、文章、図形、画像、音声、表計算とグラフを含む複合文書を扱えると報告した。
  • Diamondの表計算オブジェクトは、データと一緒にモデルを運ぶ。対応した受信ソフトなら数値を変えて結論を試せる。簡素な受信ソフトは式を扱わず、セルの値だけを示せる。会議では画面や印刷機の違いを越えて著者の意図を伝える方法も議論した。

きれいなグラフには、人を黙らせる力がある。線が右肩上がりなら、なおさらだ。だが一つのセルを変えたらどうなるか。画像だけ受け取った人には、線を眺めるしかない。モデルまで受け取った人は、その線に質問できる。1984年7月の研究者たちは、この「問い返せる文書」を電子メールに載せようとしていた。

Harry Forsdick がまとめた RFC 910 は、7月23日と24日にBBNで開かれた会議の議事録だ。BBN、ISI、SRI、Linkabitが別々の進捗を持ち寄った。BBNのDiamondはJericho上で初期実装が完成し、文章、図形、画像、音声、表計算とグラフを混ぜた文書を交換できた。ISIはXerox 1108向けの操作画面を開発し、TOPS-20上のメッセージ処理モジュールでは通常のSMTPメールとの変換を加えていた。SRIはSun上のメール管理、構造編集、輸送モジュールを説明し、当時は文章、音声、図形に対応していた。会議室には一つの完成品ではなく、互いに話しかけたい複数の試作品が並んでいた。

Diamondの表計算は、数字を並べた絵では終わらない。セルには数値、ラベル、日付、式を入れられ、データを動かすモデルごと送信する。対応するソフトを持つ受け手は、別の数値を試し、元の文書が示した結論への影響を調べられる。表にも折れ線にも散布図にも棒グラフにも円グラフにも見せられる。罫線を足せば立派な業務資料だ。その内側には、読み手が仮説をいじるための小さな機械が残っている。

受け手の機械がそこまで器用でなくても、会議は使い道を考えた。最小限の実装なら式を無視してセルの値だけ表示できる。これで、ある人は計算をやり直し、別の人は少なくとも表を読める。Diamondの表計算を知らない他の実装は、おそらくデバッガーに落ちるだろう、と議事録は心配した。想定された互換性問題だった。参加者は未知の媒体型も受け入れ、内容を扱えなければ飛ばせるようにしようと合意した。

表計算の中身だけでなく、見せ方も悩みの種だった。ビットマップ画面、小さなウィンドウ、紙の印刷物では、大きさも解像度も書体も違う。参加者は、著者が意図したまとまり、見出し、強調、文章と図の関係を記録しつつ、最終的な配置は受け手の装置に決めさせたいと考えた。数式が届いても、説明文と図が離ればなれになれば議論が読みにくい。この表現方式は会議で開発課題に挙げられ、期限も記された。

出発点にはJon Postelの RFC 759 が定めたインターネットメッセージと処理モジュール、RFC 767 が示したマルチメディア文書構造があった。1984年の会議は、それを実装する人たちの揉めどころを扱う。図形はどの表現で当面やり取りするか。ワークステーションの違いをどう越えるか。豊かな文書を文字だけのSMTPメールへどう橋渡しするか。図形にはDiamond由来の暫定方式 MMGraphics1 を採用することになった。

議事録の予定表も具体的だ。改訂したマルチメディア構文への移行は1984年10月1日までに終える目標で、次の実験は1985年1月、文章、図形、画像、音声を含む計画だった。BBNは翌年のADDCOMPE実験環境に100～200人の利用者を見込んでいた。実験はこれからで、各拠点の受信プログラムを合わせる作業が続いた。

この歴史の面白さは、グラフを送る人の都合だけで話が終わらないところにある。モデルが届けば、受け手は数字を動かして「もし」を試せる。1984年の電子メールは、結論を封筒に入れるだけでなく、結論を問い直す道具まで一緒に送ろうとしていた。