要約

  • 1979年1月10日のBBNでの会議は、ARPANETメールの各システムによる独自拡張と部分実装が、共通の配送を壊すと判断した。ホスト間で使う利用者名の空白、メールボックス中の複数の@、ほとんど実装されなかったRFC 733のIncludeとPostal型アドレスを退け、MAIL/MLFLのFTP応答コード変更も止めた。
  • 既存サービスの小さな変更はDuane Adamsが裁定し、音声・ファクス・画像の構造化メールは次世代の実験で進める。Jon PostelがRFC 808で会議を記録したのは1982年3月で、記録も仕様改訂も遅れたことが問題を長引かせたと書いた。

共同の郵便仕分け機を何十もの計算機室で使う。各室が便利な部品を追加するたび、別の室では封筒が詰まる。1979年1月、BBNに集まったメール開発者は、その仕分け機にいったんブレーキをかけることにした。Jon PostelのRFC 808は会議を三年後に振り返る。仕分け機は比喩だが、決定がその場で記録されず仕様も直されなかった、という書き出しはPostel自身のものだ。

メールプログラムの成長は計画どおりばかりではなかった。付録には異なる機械で動く送信、閲覧、配送システムの暫定的な一覧が並ぶ。議論ではホスト表の更新、奇妙なFTP応答、利用者名の書き方、配達失敗をいつ知らせるかまで不満が出た。Duane Adamsが求めた視点は、ひとつの見栄えの良い画面ではなく、最初から最後までのメールサービスだった。自室で送信ボタンが動くだけでは、相手のプログラムに届く保証にならない。

議事録によれば、仕様は複数の書き方を許し、多くの実装は仕様の一部だけを備えていた。一か所の小さな変更が別の場所で予期せぬ失敗を起こす。そこで会議は既存サービスを早く安定させる方針を取った。少数の小変更は認める余地を残し、紛争はAdamsが判断する。RFC 733に書かれた機能を、動いている全プログラムが突然そろえて実装する方針は採らなかった。

禁止した例は驚くほど具体的だ。ホスト間の利用者名に空白を入れない。メールボックスに@を何個も並べない。RFC 733のInclude型とPostal型アドレスは一般に実装されていなかったため、現行サービスの約束から外す。MAIL/MLFLのFTP応答コードもこれ以上変えない。句読点の趣味を争っていたのではない。送信側の自由が受信側の故障に変わる境目を決めていた。

一方で、新しいメールの夢は残った。議論の中では、修正の上にまた修正を重ねるより第二世代を作るべきだという声が出た。音声、ファクス、画像を運ぶ構造化データを次世代サービスで検討する。Jack Havertyは定義に利用できる言語としてRFC 713のMSDTPを挙げた。Postelには1979年2月中旬の草案が課され、後の注記ではそれが同年3月のIEN-85となり、さらにRFC 759と767に引き継がれたと説明する。古い共有ルートを守り、新しい設計を試す場所を分けたのである。

個人用計算機も将来の郵便受けを揺らしていた。常時起動して受信できるとは限らず、利用者は大きな計算機にメールを預け、後で取りに行くだろうと参加者は予想した。NSWの利用者は特定ホストの利用者ではないため、単純なuser@hostでは表せない。Bob Thomasは仮想ホストという考えを示した。こうした問題を旧サービスへの場当たり的な例外として押し込めば、仕分け機はまた複雑になる。

会議の一番痛い皮肉は、互換性の境界を決めながら、その境界をすぐ公開しなかったことだ。1982年にPostelが書いた記録は三年を隔てたため不完全で、仕様も当時改訂されていなかった。彼はその空白がメールの問題を続かせたと述べる。会議室ではっきり決めても、別の機械室のプログラマーが読めなければ共通ルールにならない。

RFC 808は、古い技術を嫌って新しい技術を拒んだ話ではない。皆が使う経路には実装できる約束だけを残し、もっと豊かなメールは別の実験で育てるという判断だ。1979年に仕分け機へ必要だったブレーキは踏まれた。ただ、そのブレーキの位置を書いた紙が届くのが遅すぎた。