摘要

  • RFC 1097 的正文称自己为 Internet 社群的标准，但 RFC Editor 当前资料页把它列为 Independent Stream、状态 Unknown；IETF Datatracker 进一步说明它没有 IETF 标准流程中的正式地位。
  • 这项讽刺性的 Telnet 选项默认关闭。客户端必须先通过 DO/WILL 协商，之后才接收持续时间、重复间隔和信息字符串。这个“同意”属于协议端点，不是用户的知情同意。
  • 规范只要求客户端“尝试”以本地实现决定的方式显示。收到参数不证明屏幕真的发光，更不证明人看见、理解、被说服或升级了软件。

写在正文里的地位，仍需正文以外的权威确认

RFC 1097 的外观完全像一份正式选项规范。页首写着 Network Working Group、作者 B. Miller、CMU-NetDev 和 1989 年 4 月 1 日。它为 SUBLIMINAL-MESSAGE 指定 257，并在“本文状态”中宣称这是面向 Internet 社群的标准。

这段话可靠地证明了文档说过什么，却没有证明文档有权决定什么。当前 RFC Editor 资料页 将 RFC 1097 标为 Unknown，归在 Independent Stream。IETF Datatracker 则明确写明：它不获 IETF 背书，在 IETF 标准流程中没有正式地位。

两份记录回答的是不同问题。RFC 正文属于被保存的历史对象；资料页和流程记录负责分类这个对象。若允许正文覆盖分类记录，任何文件都能靠一句自我声明把自己变成标准。权威不能由最需要它的那一方自行签发。

档案保存笑话，不等于把笑话变成规范

RFC 8700 回顾 RFC 系列五十年时，把 4 月 1 日 RFC 描述为 Independent Stream 中特殊的幽默作品：它们不走普通意义上的正式审查与批准流程，但会按这种特殊用途接受选择和编辑。

RFC 1097 的喜剧效果正来自严肃格式。它列出命令含义、默认状态、动机、实现说明和交换示例，甚至一本正经地讨论屏幕荧光粉余辉与 Caps Lock 灯上的摩尔斯码。读者必须先认出“标准文档的样子”，才能看懂它如何挪用这种样子。

进入 RFC 档案证明这篇文本被正式保存。档案本来就同时容纳标准、实验、信息、历史与幽默。被保存和获得标准效力，是两种完全不同的事实。

连“潜意识信息”也必须先请求许可

玩笑借用的 Telnet 骨架是真实的。RFC 854 把 Telnet 定义为双向、八位字节导向的通信机制，先有各端都能理解的 NVT 默认状态，再由双方协商附加选项。一端可以提出，另一端可以接受或拒绝；遇到不支持的选项，拒绝后仍保留共同基线。

RFC 855 又把含参数的选项分成两步。DO/WILL 先确认双方可以讨论，子协商随后才传参数；DON'T/WON'T 可以终止这种状态。

RFC 1097 沿用这套语法。WILL 请求显示许可或确认愿意显示，WON'T 拒绝；DO 要求对方显示或授予显示许可，DON'T 则要求停止。默认值是 WON'T/DON'T，也就是不显示任何信息。

因此，远端发送方并没有天然取得本地屏幕。它先要让客户端进入一个可接收后续参数的状态。这个边界很窄，却足以说明：提出功能、获得端点能力和控制最终对象不是同一件事。

257 位于普通表格之外

RFC 1097 选择了 257。当前 IANA Telnet Options 登记表 列出的普通选项到 255 为止，其中 255 是 Extended-Options-List；表内没有名为 SUBLIMINAL-MESSAGE 的 257 项。

这个数字并非没有上下文。RFC 861 早已把 255 留给 EXOPL，用封装式协商再扩展 256 个选项。RFC 1097 把自己放在普通空间之后，却在示例中只写符号化的 IAC DO/WILL/SB SUBLIMINAL-MESSAGE，没有展开 EXOPL 的线上封装。

据此可以说，笑话被安放在一个真实扩展机制的边缘。不能据此说 IANA 当前登记了 257，也不能发明一次实际编码、抓包或互操作。备忘录里的编号和登记表里的条目必须分别取证。

客户端说“可以”，屏幕前的人没有参加握手

选项启用后，远端可发送两个 16 位数值和一个字符串。第一个数是毫秒计的显示时长，第二个数是秒计的重复间隔。客户端应接收子协商并尝试立即、周期性地显示；位置与渲染方式由本地实现决定。参数中出现数值 255 的字节时，仍要按 Telnet 规则加倍转义。

示例先发“Use VMS”，随后用“Go home”取代前一条，最后用两个零值和空字符串停止。动机部分声称传统公告无法劝固执用户升级 Telnet，并点名 REMOTE-FLOW-CONTROL。此前的真实 RFC 1080 规定了这个 33 号选项，同样要求先完成 DO/WILL 再发送控制子命令。

然而，RFC 1097 说的是“客户端同意”。它没有提供用户解释界面，没有记录人是否选择了内容、频率和目的。客户端可能因默认配置、管理员决定或程序作者选择而发送 WILL。把软件状态写成“用户同意”，会把真正作决定的角色隐藏起来。

控制面也不是一个整体。远端选择文字和时间，本地客户端选择如何渲染，人的注意力则不在 Telnet 语法中。三者不能用一个“同意”概括。

“尝试显示”距离“产生影响”还有多层证据

子协商到达，可以证明字节进入客户端。日志可进一步证明渲染函数被调用。但仍要另行观察终端状态是否允许可见闪现；再另行确认人当时在场、正看向屏幕、注意到内容、理解内容、记住内容，最后才可能讨论行为改变。

备忘录声称 CMU 的实现考虑了线路速度、视频能力和荧光粉余辉，还说正在开发通过 Caps Lock 灯发摩尔斯码的版本。因为这些句子处在讽刺文本内部，它们只能被准确报道为“文档如此声称”，不能升级成软件确已发布、运行或影响用户的证据。

完整证据阶梯依次是：文本被归档、权威记录如何分类、端点能力已协商、参数已收到、本地已尝试、物理显示已发生、人已感知、人被说服、人采取行动。每跨一层，都需要新增证据。

来源