摘要

  • NNTP 把新闻分发、检索和投稿放在同一套流协议里，但部署中的服务器不必向每条连接开放全部工作。
  • MODE READER 让客户端请求从 transit mode 转入 reading mode；切换前后的 CAPABILITIES 才是当下可用命令的证据。
  • 服务器可以在转换时重置会话；该命令不能流水发送、重复发送，也不自带认证、加密或投稿权。

同一条连接给出了两张不同的能力清单

连接建立后，客户端先问 CAPABILITIES。服务器列出 IHAVE 和 MODE-READER，却没有 READER。前者用于新闻系统之间提议转交一篇文章，后者说明这台服务器可以改变模式。客户端随后发送 MODE READER，得到成功回复，再次查询能力。此时 READER、NEWNEWS 和面向阅读的 LIST 形式出现，IHAVE 则可以消失。

TCP 两端没有更换，端口没有更换，证书也未必更换；真正改变的是服务器愿意在此会话中承担的工作。若客户端只把主机名与端口当作永久能力证明，它就会用旧角色解释新状态。

RFC 977 在 1986 年给 NNTP 列出的任务本来就很宽：分发、查询、取回和投稿。个人可以从中心新闻库选读文章，合作主机也可相互取得文章并在本地保存。共同协议降低了互通门槛，却没有要求所有实现把读者请求与服务器间 feed 当成同一种信任关系。

先有运行中的分工，后有标准里的名字

MODE READER 不是为了理论上的整齐而凭空设计。RFC 2980 收录了已经存在的 NNTP 扩展，并记载该命令最早出现在 INN。阅读客户端用它表明自身用途，一些实现据此重新配置，以更适合响应 reader commands。

这段历史揭示了协议标准化常见的方向：软件先把同一入口后的工作拆开，随后客户端才需要一种共同说法来选择角色。命令不是在网络上宣告“我是某种人”，而是在一个具体会话里请求“请把这条连接当作阅读连接”。

RFC 2980 还把它与 RFC 977 中少有实现的 SLAVE 对照。两者不能被写成对称开关。可确认的事实只是：部署真正保留了显式进入阅读角色的需要，而早期的从属服务器提示没有成为这一边界的通用表达。

能力表只对当前状态负责

RFC 3977 把服务器分为 reading、transit 与 mode-switching 三类。可切换服务器刚连接时处于 transit mode，必须公告 MODE-READER，不得公告 READER。成功切换后，规则正好改变：MODE-READER 不再出现，READER 必须出现，而原先存在的 IHAVE 可以不再公告。

因此，CAPABILITIES 不是产品规格书，而是一张带会话状态的即时凭证。RFC 要求服务器列出的能力准确反映当前可用功能。TLS、认证、角色变化或外部政策都可能让答案在同一会话内改变。

IANA 的 NNTP 参数登记表 为 MODE-READER、READER、IHAVE、STREAMING 等标签保留共同含义。登记解决的是“看到这几个字该如何理解”，不是“某个站点今天一定提供什么”。

模式切换也是解析边界

RFC 3977 明令 MODE READER 不得进入 pipeline。客户端不能在尚未得知切换结果时，紧接着把 GROUP、NEXT 等命令一股脑送出。原因不仅是礼貌。服务器可在转换时忽略某些提前到达的数据；双方一旦对哪条命令属于哪个模式理解不同，响应的对应关系也会错位。

同一会话里，该命令不得发送两次，也不得在安全或隐私命令之后发送。服务器还可以把会话状态重置到“刚建立连接”的位置，然后才进入 reader mode。连接不断开，并没有承诺 selected group、current article、认证假设或扩展状态原样保留。

这正是有状态协议最容易犯的错误：把传输连续性误认作应用上下文连续性。真正可靠的实现必须在转换点明确丢弃旧推断，并重新读取允许的操作面。

能阅读仍不等于能投稿

成功切换有两种普通回复：200 表示允许投稿，201 表示禁止投稿；两者都进入阅读模式。若阅读服务永久不可用，服务器返回 502 并立即关闭连接。

三个结果分别回答三个问题：阅读命令是否开放，投稿是否获准，这个入口是否根本不提供阅读服务。把 “reader” 自动扩张成 “publisher”，就是把服务角色误当作修改权限。

能力表可以比欢迎语更精细地表达 POST 是否真实可用。状态码仍有作用，但它是一层粗粒度结果；当前能力表是另一层更细的证据。二者不能互相替代。

角色、身份与加密是三条轴

RFC 3977 的示例里，STARTTLS 甚至可以只在 reading mode 的能力表中出现。RFC 4642 另行规定 NNTP 的 TLS 转换，RFC 4643 则规定认证。它们成功后也可能改变能力表。

但 MODE READER 本身既不加密，也不证明客户端身份；TLS 或认证成功也不会自动让连接变成读者会话。RFC 4644 的 STREAMING 又属于 feed 传递。把角色、安全与命令权限分开，才有可能看清最小授权与故障发生在哪一层。

真正的遗产是“旧能力到此为止”

有状态协议常因隐藏状态而脆弱。MODE READER 的价值恰好是把一段原本隐藏的部署分工公开出来：客户端点名请求转换，服务器接受或拒绝，之后的能力表说明新状态。

这并不证明单端口架构优于分离端口。一处入口可降低发现与迁移成本，也可能把 feed 与读者政策错误集中在一起。标准提供的不是唯一拓扑，而是一条边界纪律：只要连接换了工作，旧权限就不能靠“socket 还活着”继续成立。

来源与证据边界

这些材料证明协议行为、标准演变与登记名称，不提供当前部署率、流量份额、某产品内部结构或某站点政策。本文不把 IANA 登记当成使用证明，也不把 MODE READER 说成认证、加密或投稿许可。