摘要

  • 2026 年 9 月 3 日，IESG 认定 Safe-IOC 独立投稿与 IETF 工作不存在冲突。这是 RFC 5742 下的冲突审查结论，不是技术背书、IETF 共识，也不是 RFC 发布决定。
  • 第 13 版草案给出了统一且可逆的文本规则，但“安全”只在每个下游系统都维持不可执行边界时成立。管理者要追踪的是激活权的流转，而不只是最终显示的字符。

IETF 公告公布了冲突审查记录中的结论。RFC 5742把 IESG 的职责限定为检查独立流或 IRTF 流文件是否妨碍 IETF 工作；没有冲突之后，技术价值与最终发布仍由相应流程判断。文件页面明确写明：这是个人提交的 Independent Submission，拟为 Informational，不代表 IETF 或工作组认可。第 13 版日期为 9 月 4 日，审阅记录中尚无最终 RFC 编号。

RFC Editor 对独立投稿的说明进一步划清边界：这类文件无需、也不携带社区共识，不是标准或最佳实践。把“无冲突”写成“IESG 已认证安全”，正是把程序状态误当现实结果。

第 13 版全文解决的互操作问题是真实的。长期以来，安全团队用 hxxp、替换点号等办法避免链接被误点，但各工具对这些变体的理解不同。草案要求按固定次序包裹 scheme，并处理中用户信息与 host 的结构分隔符；已中性化的 token 必须保持不透明。这样重复处理时不会不断叠加括号，正向变换具有幂等性。

幂等并不等于永久安全。逆向操作的目的就是重新得到可用地址。草案因此要求只把结果写入不可执行缓冲区，禁止在浏览器预览、活动文档、富文本编辑器、地址栏或任何可能自动解析、执行、生成链接的环境中还原。聊天机器人案例里，危险不是人违背规程，而是机器人拥有未被单独记录的还原和访问权限。

RFC 3986解释了为何不能粗暴地全局替换标点。host 中百分号编码的点属于非保留字符，可以先规范化；已编码的保留分隔符则不能随意解码，否则 URI 结构会改变。逆向得到的值可能语义等价，却不保证逐字节相同。若原始字节和来源被覆盖，事后就无法完整重建证据。

嵌套指标使解析器成为决策者。一条重定向 URL 可以在 query 中装入另一条 URL；路径里也可能出现邮箱或 IP。草案禁止把 path、query、fragment 中所有点、冒号和 @ 一律替换，只允许对符合语法的嵌套片段递归处理。不同解析器版本可能对同一段文本作出不同分类，字符表面却看不出这种权力变化。

部分中性化尤其危险，因为它会制造“已经处理”的错觉。只替换 host 的点而保留有效 scheme，或只包裹 scheme 而留下原 host，都可能继续触发自动链接。hxxp 与 hxxps 在语法上仍占据 scheme 位置；它们在 IANA URI Scheme 登记表中的临时记录以及 RFC 7595的登记制度，都不能被解释为允许解析或访问。

文本中性化也不证明指标本身正确。RFC 9424把 IoC 放在发现、评估、分享、部署、检测、响应和结束的完整生命周期中。一个地址可能过期、被合法服务复用或归因错误。RFC 7970、STIX 2.1与 TAXII 2.1所承载的上下文、关系和传输状态，不能由一对括号代替。收到情报不等于规则已经安装，更不等于检测或处置成功。

测试应使用 RFC 2606保留的示例域名，避免把真实基础设施写进假设。Running-Code Primacy要求观察实际运行的机器人、预览器和解析器；Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption允许统一最小文本规则，同时把还原与隔离决策留在本地；On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile提醒我们：看起来不可点击是符号层，是否发出网络请求才是现实层。