要約

  • RFC 1176ではFIND MAILBOXESなどが任意だった。BADが返っても、クライアントは未対応なのか別の失敗なのかを判断できない。
  • RFC 1203は対案として、サーバーの対応版と機能を照会し、版を選び、個別の機能を選択する手順を示した。

使えるかどうか分からない検索ボタンを、誰が画面から消すのか。1990年のRFC 1176を読むと、その問いが生まれる。FIND MAILBOXESとFIND BBOARDSは任意のコマンド。実行してBADが返っても、その理由についてクライアントは何も推定できないと書かれている。サーバーは自分の機能を知っているが、メールソフトには事前に聞く手段がない。

John Riceは1991年2月のRFC 1203を、RFC 1176への対案と明記した。前の改訂がIMAP共同体の内部相談なしに作られたとも批判する。これはRiceによる経緯の主張である。一方、任意コマンドを列挙する手段の有無は、二つの仕様書そのものから確かめられる。仕様の一語「任意」が、実装側には失敗時の判定不能として届いていた。

対案は順番を定めた。SUPPORTED.VERSIONSでサーバーに対応版と機能を尋ね、SELECT.VERSIONで版を選ぶ。SELECT.FEATURESで使う機能を指定する。RFC内のやり取りでは、一覧を受け取ってから3.0を選び、TAGGED.SOLICITEDを有効にする。未対応の版や機能を求めればNOが返る。画面を作る側は、利用者に押させる前に選択肢の根拠を持てる。

古い機器との接続も設計に入っていた。接続直後の既定動作はRFC 1064のIMAP2。クライアントが明示的に選ばなければ、サーバーは振る舞いを変えない。版の選択をメールボックス選択より先に置いたのは、別の版を扱うためサーバー側で別プログラムを起動する可能性があり、その際に状態を引き継げないからだ。変更の手続きを、捨てるものがまだ少ない時点に置いた。

RFC 1176の付録は、クライアントがメールボックスの不完全な写しであるローカルキャッシュを持つとした。RFC 1203は、サーバーがクライアント内部のキャッシュ構成を前提にすることにも反対した。さらに、要求への必須応答にはそのコマンドのタグを付け、サーバーが自発的に送るデータには*を付ける。複数の検索が同時に進み、保存媒体からの応答が遅れるなら、結果の帰属を見分ける仕組みが要る。

RFC Editorの記録では、この案は現在Historic、当時のインターネット向けにはExperimentalとされる。普及台数を示す記録ではない。残ったのは、拡張をめぐる実務上の衝突だ。サーバーが知る機能を、クライアントに当てさせるのか。仕様の入り口で明かすのか。1991年のIMAP3は後者を選んだ。

出典