摘要

  • RFC 7168 的 Updates 字段说明它在内容上扩展 RFC 2324；状态栏说明它是独立提交的信息性文档，不属于互联网标准轨道。
  • 文档关联不代表社区共识、互联网标准，也不能证明设备实现了这套趣味协议。

一页上的三种信息

RFC 7168 的第一页并排列出 Updates: 2324、茶壶协议扩展的标题和状态说明。第一项指出它与哪份旧文档相关；标题说明内容把 HTCPCP 从咖啡冲煮延伸到茶；状态栏则指出它属于 Independent Submission，类别为 Informational，不是 Internet Standards Track 规范，RFC Editor 也不对实施或部署价值作判断。

这些信息并不冲突。Updates 描述文档的内容关联；Independent Submission 描述发布途径；Informational 和状态文字说明文档地位。RFC 编号只说明文本进入 RFC 系列，不能单独证明它经过何种共识程序或具有何种标准权威。

正文采用技术规范形式，定义 BREW 请求、message/teapot 媒体类型、茶叶品种 URI 和响应规则，也使用大写规范词。但形式严谨不会覆盖同一页上的状态说明。

扩展描述了什么

1998 年的 RFC 2324 提供了咖啡壶控制协议的语汇。2014 年的 RFC 7168 将其扩展到茶。设备可以用 Alternates 列出茶种，让客户端先选择，再请求具体 URI。用 message/teapot 请求根路径 / 时，文本规定先返回选项而不开始冲泡；若使用 message/coffeepot，处理流程可能回到基础协议并开始冲咖啡。文档还描述了达到偏好浓度后发送停止请求。

这里的设计次序是先发现选项，再触发设备动作。但 RFC 没有记载真实设备、互通测试或联网茶饮服务。它证明作者写了什么，不证明设备照此运行。

RFC 2324 自己也说不规定任何互联网标准。因此 RFC 7168 的 Updates 没有改变基础文档的状态，也没有把茶扩展变成标准。它标注的是文档延续关系，不是采用情况。

RFC 系列不只有一条发布途径

RFC 5741 解释 RFC 页眉为何说明文档来源和状态。RFC 系列收录来自不同发布流的文档。Independent Submission 的状态模板说，RFC Editor 依其判断决定发布，并不对实施或部署价值作判断。RFC 7168 使用了这段说明。

要分开看三件事：编号说明是否收录；发布流和类别说明途径与地位；Updates 说明扩展哪份旧文档。RFC 2324 到 RFC 7168 表示内容有关联，不是共识或实际使用的证据。

两份文档都标注 4 月 1 日，分别是 1998 年和 2014 年，幽默也很明显。发布元数据帮助读者区分正式排版的趣味贡献与运营者应实施的互联网标准。

卢恒的 Note 65《Running-Code Primacy》只作为编辑视角：规范文字不能代替运行代码证据。联网茶壶是否运行过，需要独立材料证明。

来源