Summary

  • RFC 9948 是真实、永久的 RFC，于 2026 年 4 月 1 日作为 Independent Stream 的 Informational 文档发布；它的状态声明明确说，这不是 Standards Track 规范，RFC Editor 不判断其实施或部署价值，它也不是任何级别 Internet Standard 的候选者。
  • 文档故意用标准文本的外观讲笑话：正式编号、DOI、BCP 14 大写词和一套从“挑眉”到“扶额”的处罚表。这些元素能够证明文档身份，却不能把表情变成 IETF 的执法行为。
  • 一旦引用将触发采购、审计、封禁或处罚，使用者就应附上“体裁与权力凭据”，把固定身份、文档流、状态、日期、标准关系、IANA 影响、文献谱系和体裁证据重新接合。它保护笑话与档案，不设立新的内容审查机关。

最容易被带走的是编号

RFC 编号很适合传播。它短、稳定、可检索，也能在不同系统之间作为共同键。RFC 9948 的编号确实指向一个由 RFC Editor 正式保存的文档；标题、作者、DOI 和正文都不是仿造。

最容易留在原页上的，却是决定权力边界的长句。

RFC 9948 的信息页给出四项关键事实：发布日期是 2026 年 4 月 1 日；文档流是 Independent Stream；状态是 Informational；正文的 Status of This Memo 声明，它并非 Internet Standards Track 规范。声明还说，RFC Editor 对其实施或部署价值不作判断，经这一文档流批准的作品也不是任何级别 Internet Standard 的候选者。

“这是正式 RFC”与“这不是具有标准约束力的命令”没有冲突。前一句回答档案真伪，后一句回答制度属性。编号告诉读者“是哪一份文档”；stream 告诉读者“经过哪条发布路径”；status 告诉读者“这是什么类型的成果”；真正让某条文本产生现实后果的，则是实施者、合同、组织政策或法律后来作出的采用决定。

把这四层压成“RFC 要求”，就会让采用者从记录中消失。

一套不存在的处罚，照见真实的影响

RFC 9948 给轻微问题安排了 Raised Eyebrow，也就是挑眉。再严重一些是 Frown；把复杂性扫到地毯下面，会招来 Shaking of the Head；另一些问题对应 Finger Wag；传说中的最高境界是 Head-in-Hand Gesture。

文档随后列出协议评审中并不陌生的话：“这一部分需要展开”“你可能没有考虑……”“威胁模型似乎还不够完整”。这些话完全可能改变一个草案，也可能影响实施者的判断。但 RFC 特意补上一句：它们本身并不是处罚。至于用湿面条进行“敲打式劝说”，文本也明确把它留在传闻里。

这不是凭空出现的角色。RFC 9948 延续了 RFC 8962 虚构的 Protocol Police。后者在 2021 年 4 月 1 日作为 Independent Stream 的 Informational RFC 发布，同样声明不属于 Standards Track，也不主张实施或部署价值。

笑点来自两种现实的重叠。IETF 没有这样一支警察力量；技术共同体却确实存在评审、声望、资历、反对意见和互操作性压力。讽刺把非正式影响夸张成穿制服的执法，让人看见二者不能混写。

如果把笑话当政策，机器反而完成了笑话所批评的动作：它把技术不赞成洗成了无须说明来源的处罚权。

正式档案不只保存标准

RFC 8700 对 RFC 系列五十年历史的回顾，把 4 月 1 日 RFC 描述为 Independent Stream 的特殊组成，并明确称其为幽默文本。那段历史还记录了一条创作标准：读者最好在读到第二页末尾前都未必马上识破。换言之，酷似严肃 RFC 不是分类失误，而是体裁本身的技术。

因此，不能用删掉、隐藏或降格的办法解决下游误读。RFC 系列本来就同时保存标准、最佳实践、实验、研究、历史与其他互联网相关材料。永久编号的价值，在于稳定地指认一份已经发布的文字，不在于把所有文字变成同一种制度产物。

RFC Editor 当前的“How to Read an RFC”说明也要求先看元数据。它明确提醒：并非每份 RFC 都是 Internet Standard；只有 IETF Stream 能产生 Internet Standards；Independent Stream 位于 IETF、IAB 和 IRTF 的正式流程之外。RFC 8729 进一步说明，不同 stream 有各自的批准路径。RFC 7841 则通过不同的页眉与 boilerplate，把这些制度差异写进文档。

档案的正式性需要保留，文档流的差异也需要保留。两者丢掉任何一个，都会得到不真实的分类。

MUST 只能在自己的边界内工作

RFC 9948 明确调用 BCP 14 的大写规范词规则。这是精心设计的一部分：当“必须挑眉”穿上协议规范的语法外衣，荒诞感才成立。

但大写词只描述一句话在既定文档范围内的强度。它不会选择文档流，不会提升 status，不会创建执行机关，也不会回答谁自愿采用了这份文本。一个 Independent Stream 的 Informational 文档不会因为用了 MUST 就变成 Proposed Standard。

RFC 3935 给出了更根本的限制。即使是一份 IETF 标准，“标准”的含义也是：如果你声称按该标准做这件事，就应照它描述的方式做；它并不意味着 IETF 强制人们采用，更不意味着 IETF 负责巡查使用情况。RFC 9592 也保留了那句广为流传的话：IETF 不是“协议警察”。

所以，每个被摘录的大写词都应带着三个问题：谁的文档？在什么 stream 与 status 下？又是谁通过什么现实行为，让它对当前对象产生了后果？缺少最后一项，命令式语法没有现实管辖权。

不应为风险虚构一个事故

现有证据没有显示某个搜索引擎、AI 模型、采购部门或合规系统已经把 RFC 9948 当成真实处罚表。本文不会为了增强戏剧性而编造一次误判。

可以确认的是结构性风险：文档越来越多地以片段传播。搜索摘要、向量库段落、知识图谱节点、自动生成答案和合规表格都可能保留准确句子，却丢失限定句。编号和 MUST 因为短小而幸存，status boilerplate 因为重复和冗长而被压缩。

日期也不能单独承担分类任务。RFC 的历史资料提醒，4 月 1 日并不自动意味着讽刺；用日历做二元规则，会把严肃文档误伤。只看文风也不够，因为成功的讽刺正是要在一段时间内维持严肃外观。

RFC 9948 的体裁判断来自一组相互支撑的证据：4 月 1 日、Independent Stream、Informational、明确的非标准与非部署声明、与 RFC 8962 的谱系、虚构的机构、不可能的处罚、无 IANA action，以及 RFC 8700 记载的历史传统。重要的是组合，不是某一个关键词。

一份随引用走的体裁与权力凭据

这份凭据无需改动 RFC，也不要求改造官方档案。它由做出高后果引用的人生成，并能用官方资料独立核验。

第一组字段固定身份：RFC 编号、完整标题、DOI、正文哈希、发布日期，以及查阅信息页的时间。第二组字段固定制度来源：stream、status、stream approver、已知 errata、Updates 与 Obsoletes 关系。

第三组字段回答“为什么会有后果”：它是否属于 Standards Track 或 BCP；哪段 boilerplate 描述了共识与部署地位；是否产生 IANA action；当前场景中的采用者是谁。如果采购文件引用了 RFC，就链接具体条款与责任人；如果产品声明兼容，就记录版本、测试和声明主体；如果组织政策把它设为控制项，就写明批准行为。

第四组字段保存体裁：支持判断的多项证据、相关文档谱系、被引用段落的上下文、翻译选择，以及在反讽或文化语境会改变结论时触发人工复核。

最后还要说明凭据不证明什么、由谁制作、何时复查、如何把更正传到派生规则。只有源摘要更正而下游处罚仍在运行，并不算完成修正。

这不是“体裁警察”。它不决定哪些笑话可以发表，只要求准备采取现实行动的人交代权力链。

IETF 是语境，不是这份 RFC 的 stream

RFC 9948 讨论 IETF 文化，也引用 IETF 规范语言。本文的目录链接因此指向 IETF 这一制度语境。但这不等于把文档归入 IETF Stream。

一条准确记录应同时容纳四句话：它是 RFC 系列的正式制品；它由 Independent Stream 发布；它的 status 是 Informational；它以 IETF 文化为讽刺对象，却没有 IETF Standards Track 地位。

如果数据库只能写一个组织名，就会把关系类型抹平。官方托管、讨论对象、发布路径和标准批准者并不是同一字段。链接可以帮助发现；只有带类型的链接才能避免把“谈论 IETF”误写成“IETF 制定的标准”。

让挑眉留在档案里

RFC 9948 无须被改写。它的状态声明没有隐藏，IANA 部分写明没有动作，虚构谱系也可公开追溯。问题发生在某个下游使用者准备把引用变成现实后果的时候。

后果越重，凭据就应越完整。推荐阅读可以很轻；技术比较需要版本与 status；合同要求必须显示采用条款；拒绝供应商、判定审计失败或处罚个人，则必须显示完整权力链并保留可申诉的责任人。

RFC 编号应继续完成它最擅长的任务：稳定地指向文档。挑眉也应继续完成它的任务：让共同体笑着看见非正式权威的边界。谁都不该借两者之名，凭空造出一张罚单。

信息来源

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — RFC 9948 信息页
  5. RFC 9948 — Internet Protocol Police (IPP): Schedule of Punishments
  6. RFC Editor — RFC 8962 信息页
  7. RFC 8962 — Establishing the Protocol Police
  8. RFC 8700 — Fifty Years of RFCs
  9. RFC Editor — What Is an RFC?
  10. RFC 8729 — The RFC Series and RFC Editor
  11. RFC 7841 — RFC Streams, Headers, and Boilerplates
  12. RFC 3935 — A Mission Statement for the IETF
  13. RFC 9592 — Retiring the Tao of the IETF