要約

  • RFC 2062は旧IMAP構文を中心仕様から外しつつ、古い相手と接続する実装のために限定された参照地図を残した。
  • 新しいサーバーは廃止コマンドを実装する必要がなく、旧応答を原則として送信してはならない一方、クライアントには応答別の受信処理が残った。
  • 古い入力を理解できることは、送信側がその言語を使い続けてよいという意味ではない。

接続の両端が同時に更新されることは少ない。新しい側はしばらく古い相手と出会う。そこで必要なのは、全面互換でも即時切断でもなく、どちら向きの例外かを示すことである。

RFC 2062はInformationalであり、Internet Standardを定めないと明記した。RFC 1176、IMAP2bisの実装慣行、RFC 1730に由来する構文を、IMAP4rev1の本文から分離して保存した文書である。記録を残すことと、現行の送信言語として残すことを切り離した。

対象には FIND ALL.MAILBOXES、FIND MAILBOXES、SUBSCRIBE MAILBOX、UNSUBSCRIBE MAILBOX、PARTIAL がある。FETCHにも BODY[0] や RFC822.HEADER.LINES などの古い形があった。新しいサーバーに実装義務はない。旧クライアント向けに受け入れてもよいが、それは任意の橋であって、新しいクライアントが送り続ける根拠ではない。

PARTIAL は置換の意味をよく示す。データはFETCH応答で返るが、その応答自体には返却範囲が記されない。複数コマンドは順不同で実行され得るため、クライアントは各段階を処理し同期しなければならなかった。同じ目的に近い後継構文でも、要求と結果の対応をより明確にできる。

旧応答の扱いは一様ではない。新サーバーは原則として送らない。MAILBOX は旧FINDへの回答に限る。クライアントは旧 COPY を無視し、旧 STORE を FETCH と同等に扱う。受信互換とは、条件付き解析、無害化、現行意味への正規化という異なる動作の集合である。

RFC 2683は後に、寛容なサーバーが古いコマンドを受ける事実から、送信の正当性を導いてはならないと警告した。RFC 2061も互換性助言を基礎仕様の要件から分離し、古いbboard系コマンドを新ソフトウェアへ戻さないよう勧めた。寛容さは出口であり、更新権ではない。

RFC 3501はRFC 2062を歴史資料として残した。RFC 9051ではCAPABILITYと ENABLE IMAP4rev2 によってモード選択が見える。両版を広告するサーバーも、通常はIMAP4rev1側から関連動作を求められない限り、削除済み応答を返さない。これは同じ方向性を持つ後年の設計であり、直接の因果関係を示すものではない。

運用では証拠を四つに分ける必要がある。受理できる入力、選択する出力、相手と合意したモード、実際に流れたバイトである。パーサー試験の成功は受信能力しか証明しない。能力名の登録も、製品の採用や接続結果を証明しない。

まず旧出力を止め、残る旧入力を測り、例外を相手単位に閉じ込め、必要性が消えた時点でパーサーを外す。この順序なら互換性は移行を支える。方向を失えば、受信上の譲歩が旧言語を永久に生産する口実へ変わる。

出典