要約

  • 1994年10月のRFC 1703は、インターネットのメールを無線呼び出しサーバーへ渡す手順を定めた。RCPTとDATAへの肯定応答が示す事実は、最初のMAIL、SEND、SOML、SAMLによって変わる。
  • クライアントがサーバーへSMTPで直接接続し、SENDまたはSAMLを使う構成なら、肯定応答は呼び出しが無線網で送出されたことを保証する。そこで確認されるのは無線網での送出である。

受付票だけではベルは鳴らない

手紙なら、集配所で受け付けた時点でひとまず安心できる。ポケベルの用件は少し違う。修理担当を呼ぶ、当直に知らせる、今すぐ折り返してもらう。知らせる時刻に値段が付いている。メールの仕組みが無線呼び出しの窓口を務めると、いつもの成功コードだけでは時間の勘定が合わなくなった。RFC 1703はその勘定書をSMTPのコマンドごとに書いた。

無線呼び出しサーバーにはMAILのサポートが必須だった。SEND、SOML、SAMLは任意である。仕様はRCPTとDATAの両方に肯定応答が返ったときの意味を分ける。MAILなら、少なくとも無線呼び出し網へ送るための待ち行列にメッセージが入った、という約束になる。確かに一歩進んだ。ただし、行列は無線塔ではない。順番を待つ間も時計は動く。

ここでRFCは二段階に分けて書く。第3.3節では、SENDに対するRCPTとDATAの肯定応答は、無線呼び出し網が宛先への配送用にメッセージを受理したことを示す。SOMLとSAMLでは網が受理したことを示す場合がある、という表現にとどまる。この段階では経路の長さを条件にしていない。表示された「OK」だけを切り取れば、コマンドごとの領収書の差が紙くずのように落ちてしまう。

宛先の作り方も独特だ。電話番号の数字をDNSラベルに並べ、tpc.intの下でMXレコードから応答するサーバーを探す。ワイルドカードのMXは広い番号帯への試行を引き受ける意思を示すが、個々のポケベルの存在を証明するものではない。この入口はRFC 1530のTPC.INT構想につながる。入口を見つけた後、どこまで仕事が済んだと言えるかがRFC 1703の焦点だった。

端末にも注文がある。pager-numericの本文は数字だけ。pager.やpager-alpha.は英数字を扱うサービスを示す。メール風の宛先を付けても、数字専用端末が突然長文を読めるようにはならない。ゲートウェイは宛先と本文を無線サービスの条件に合わせて受け取る必要があった。

さらに普通の電子メールは、途中で複数のリレーやゲートウェイを経由できる。各所で保存してから転送すれば、RFCが挙げたように数分、数時間、場合によっては数日の遅れも生じる。急ぎの呼び出しには長すぎる寄り道だ。Roseはクライアントから無線呼び出しサーバーへIP/SMTPで直接つなぎ、SMTPの一跳びで届ける構成を示した。途中のメールリレーが作る待ち時間を取り除ける。

第3.4節は経路とコマンドを一緒に指定する。クライアントがリレーを挟まずサーバーへ直接つなぎ、SENDまたはSAMLでリアルタイム送出とその成否を求める。この組み合わせなら、サーバーの肯定応答はメッセージが無線呼び出し網で送出されたことを保証する。第3.3節のSAML単独についての「受理した場合がある」と、第3.4節の直結したSAMLについての送出保証は、条件が違う。仕様が見届けた地点は無線網での送出だ。持ち主が画面を見た瞬間まで、SMTPの返事に詰め込んではいない。

待ち行列に入れた。無線網が受けた。直結して送出を求め、無線網で送った。RFC 1703は似た色のランプに、それぞれの作業名と条件を刻んだ。急ぐ人に必要だったのは、優しい返事よりも、その返事がどの時計を止めたか分かることだった。