要約

  • RFC 984は常設の保管庫に安定した全体のメール状態を置き、同じ利用者の複数のPCが局所的な写しを持って、接続時に同期する設計を示した。
  • 約100バイトの要約記録で小容量のPCも全メッセージの目録を持てる。切断中の操作は待ち行列へ入り、DMSPは一つの操作を丸ごと成功または失敗として扱う。

会社のパソコンを止めても、家のパソコンは待っている。小型機なら車の後部座席にも乗る。1986年5月のPCMAIL提案で、David ClarkとMark Lambertはそんな移動を真面目に想定した。機械が帰宅するあいだ、新しい手紙はどこへ行くのか。答えは大きなディスクを持つ常設の保管庫だった。利用者の郵便状態はそこに住み、PCは必要なときに訪ねる。

当時の個人用計算機は便利で窮屈だった。安価なので職場と自宅に一台ずつ置ける。持ち運べる。一方、原文が挙げる典型例では主記憶は1メガバイト未満、フロッピーの容量は約360キロバイト。大量のメール本文を全部持たせるには小さい。そこでPCMAILはまず一覧表を持たせた。

メール一通は要約記録と本文に分かれる。要約は通常約100バイトで本文の長さに左右されず、識別子、長さ、便利なヘッダー項目、状態の印を含む。PCは要約をすべて保持し、本文は空き容量に合わせて保管庫から取る。利用者は中身を持ち帰る前に、何が届いているかを知ることができる。目録は貧しいディスクのための小さな勝利だった。

複数のPCを使うと記憶がずれる。保管庫の全体状態と各PCの局所状態は、切断中に異なる。常時接続なら対話モードで変更をすぐ反映し、新着メールも届く。接続がまばらならバッチモードで局所操作を積み、次の接続時に送る。DMSPがメール操作と同期を担った。家と職場のPCは同じ持ち主の郵便箱を見ながら、しばらく違う時点に生きる。

再会には明快な会計が要る。DMSPの操作は原子的で、全部成功するか全部失敗する。明示的な確認がなければ失敗扱いだ。削除の途中で回線が切れても、双方の状態を壊さないためである。保管庫は各PCが見逃した変更も記録する。文書に記された実装では一週間接続しないPCを非活動扱いにし、戻ったときには全体状態を丸ごと送り直した。細かな変更を長々と再生するより早いと判断したのだ。

RFC Editorの記録では刊行は1986年5月で、後にRFC 993が置き換えた。原文は討議用の予備案として出された。そこで示された役割分担は鮮明だ。保管庫は覚え、PCは動き、約100バイトの目録は荷物を減らし、プロトコルは切断中の行動の決着を付ける。パソコンが帰宅しても、郵便箱には夜勤が残った。