要約

  • RFC 1957は、状態表示の直後に空白がないと失敗する二つのクライアントを報告したが、追加文がない場合の空白をRFC 1939は要求していなかった。
  • UCBのpopperは常に追加情報を返したため、常に空白も返した。その安定した余分が受信側の前提になった。
  • NetscapeはUIDL、EudoraはTOPを必要としたと報告されたが、RFC 1939では両方とも任意コマンドだった。

POP3の状態応答は、肯定なら+OK、否定なら-ERRから始まる。追加の文があれば空白を挟むが、何も続かなければそこで行を終えられる。RFC 1957が問題にした空白は、仕様が常に求める文字ではなかった。

しかし、利用者がよく目にする実装は最短形を出さなかった。広く使われたUCBのpopperは、のちにQualcommが開発を続け、状態表示の後へ常に情報を付けた。結果として空白も必ず現れた。正当な一つの出力習慣が、試験環境の標準形になった。

RFC 1957は、自由に複製できるUnixのpopclientと、プロプライエタリなnetApp Systems Internet Seriesが、その空白を期待し、見つからないと失敗したと記す。短い応答を返したサーバーは仕様の範囲内にいても、既存ソフトウェアの範囲外に置かれた。

ここでは、準拠と相互運用性が分離している。準拠は「許された集合の内側か」を問う。相互運用性は「実際に配置された相手が受け取れるか」を問う。多数派の送信側が一つの形しか出さず、受信側がその形しか受け取らなければ、文書が認めた自由は改訂なしに消える。

RFC 1957は、その習慣を新しい規範とは呼ばなかった。二つのクライアントの作者には連絡が取られ、新版は空白を期待しない予定だとする。一方で旧版を支えるよう勧める。受信側を直すことと、既設の利用者を壊さないことは、同時に必要でありながら終了時期が異なる仕事だった。

もう一つの観察は機能の前提である。RFC 1939はTOPとUIDLを任意のPOP3コマンドとしている。それでもRFC 1957によれば、NetscapeはUIDLを、EudoraはTOPを要求した。各コマンドの内部動作ではなく、任意性の行方が重要だ。サーバーに残された選択が、人気クライアントに接続するための実務上の条件へ変わった。

当時は能力を知る仕組みも弱かった。RFC 1939は、任意コマンドを実装していないサーバーと、処理する意思または能力がないサーバーを一般的に区別できないとした。RFC 2449は1998年、任意機能は試してみなければ分からず、場合によってはそれすら難しいと述べ、TOPやUIDLを含む能力を告知するCAPAを定義した。後年の設計上の応答ではあるが、RFC 1957との直接因果や全面採用までは証明しない。

史料の限界も守る必要がある。RFC 1957はRFC 1939を更新する情報提供文書で、1996年6月に公開された。名前を挙げた観察であって、市場調査ではない。台数、障害率、費用、利用期間は示さず、サーバーが不適合だったとも、クライアント作者が意図的に仕様へ反したとも述べない。

稼働するコードは、どこに依存があるかを教える。しかし、依存が高価だからといって、その起源に正統性が与えられるわけではない。互換性を守ることと、偶然を永久のプロトコル法にしないこと。その二つを分けて考えた点にRFC 1957の持続的な価値がある。

出典