摘要

  • RFC 1176 允许服务器不实现 FIND MAILBOXES、FIND BBOARDS 等命令；收到 BAD 后，客户端仍无法判断失败原因。
  • RFC 1203 自称针对 RFC 1176 的反提案，要求服务器先报告可用版本和功能，再由客户端选择。

一个菜单项是否存在，本应是个能在点击前回答的问题。RFC 1176 在 1990 年修订 IMAP2 时却留下了一个窟窿：FIND MAILBOXES 是可选命令；客户端若试用后收到 BAD，文件说它不能从中作任何推断。FIND BBOARDS 也一样。协议把选择权留给服务器，把猜谜的工作交给每个邮件程序。

1991 年 2 月，John Rice 在 RFC 1203 开头就把 IMAP3 称作反提案。他指责上一份文件没有经过 IMAP 社群内部协商。这是 Rice 对制定过程的陈述；两份原始文件能够直接核对的，则是设计分歧：一边允许命令缺席，却没有列出可用命令的查询机制；另一边要把服务器的实际能力写到线上。

IMAP3 给出了三个动作。客户端先发 SUPPORTED.VERSIONS，取得版本和功能清单；再用 SELECT.VERSION 选择协议版本，以 SELECT.FEATURES 开关具体功能。文档示例先查询，再选 3.0，最后启用 TAGGED.SOLICITED。请求不受支持的版本或功能，服务器应答 NO。程序可以据此安排界面，用户无需充当功能探针。

这份反提案也没有把老客户端扔出门。连接开始时仍按 RFC 1064 的 IMAP2 行事；客户端不主动选择，服务器就不改变行为。Rice 还要求在选定邮箱之前确定版本，因为另一版本可能由另一套服务器程序处理，切换时会丢失会话状态。协议升级被放在尚未背上邮箱状态的时点，兼容因此有了可操作的起点。

争论甚至伸到了客户端内部。RFC 1176 的附录要求 IMAP2 客户端维护本地缓存，把它视为邮箱的不完整模型，并说明怎样靠服务器回应更新。RFC 1203 反对服务器擅自假定客户端采用哪种缓存架构。它还把“因某条命令而必须返回”的数据标上该命令标签，把服务器自发发送的数据标成 *。当多个搜索并行、磁盘迟迟给不出结果时，客户端需要知道每条回应究竟属于哪次提问。

RFC Editor 的状态页 如今把 RFC 1203 列为 Historic；当年它对互联网社群是 Experimental。状态记录没有给出装机数量，也不替任何一方宣布商业胜负。它留下的戏剧性细节更实在：一份标准让客户端盲试可选命令，另一份标准要求掌握答案的服务器先开口。1991 年的邮件菜单，成了谁承担不确定性的战场。

来源