摘要

  • RFC 3969 为每个 SIP/SIPS URI 参数名做成对保留，目的是阻止同一拼写在两种方案中获得冲突含义；成对保留本身并不证明参数对两者都适用。
  • 文件一面写着“Specification Required”，一面又要求标准轨 RFC。RFC 5727 后来明确指出两者矛盾，并把原意澄清为 Standards Action。

RFC 3969 中最值得保存的，不是一张参数表，而是一项反直觉的治理选择：每一个参数名称都要同时作为 SIP URI 参数和 SIPS URI 参数登记。紧接着，文件又说有些参数可能并不适用于其中一种方案。两句话并不冲突。第一句处理命名权，第二句处理行为边界。

如果一个名字只在 SIP 一侧被占用，未来作者仍可能在 SIPS 一侧拿同样的拼写定义另一种功能。日志、配置、解析器和人类读者看到同一个词，却必须猜测它携带哪一套语义。RFC 3969 宁可在表里占两个位置，也不让这种歧义成为既成部署。第二个位置是一把语义锁，不是一份功能许可证。

七个初始名称把问题具体化

RFC 3261 允许扩展定义新的 SIP 与 SIPS URI 参数和值，却没有为它们建立 IANA 注册表。RFC 3969 在 2004 年 12 月补上这一协调层，首批名称是 comp、lr、maddr、method、transport、ttl 与 user。其中 comp 指向 RFC 3486，其余初始条目指向 RFC 3261。

每一行保存名称、是否只接受预定义值，以及定义来源。Predefined Values: Yes 不是一份完整枚举。RFC 3969 选择“按引用登记”：实施者必须打开所有被引用的 RFC，才能得到完整值域、语法、用途与安全条件。今天的 IANA SIP Parameters 注册表 在 transport 一行同时引用 RFC 3261 与 RFC 7118，正说明这张表是一幅会增长的出处地图，而不是冻结的解析器代码。

文件把已登记名称和值称为“保留字”。私有或本地名称并未被全面禁止，但可能与未来公开登记相撞。注册表也没有厂商扩展树。RFC 3427 已经警告，SIP 扩展可能大幅增加复杂度，甚至损害安全，因此公开名称要由 RFC 解释语法、预期用途与语义。

这一层权威仍然很窄。它能证明某个拼写已被公共流程绑定到一套文档，不能证明终端已经实现，也不能证明 SIPS 的安全约束已经满足。RFC 5630 后来专门澄清 SIPS URI 的处理与安全预期，RFC 3263 讨论服务器定位和传输选择。这些运行规则都不能从“名称在两边都保留”倒推出。

登记政策的标签与门槛并不一致

RFC 3969 还留下了一处可追踪的政策裂缝。第 4.2 节采用 RFC 2434 的“Specification Required”标签，下一句却要求参数必须由标准轨 RFC 定义。前者通常意味着永久公开规范加指定专家审查，后者则要求通过标准流程；决策权和审查门槛并不相同。

2010 年的 RFC 5727 没有假装原文从未出错。它明确称这是一处由误解政策类别造成的矛盾，并说明原意是 Standards Action。当前 IANA 页面也显示 Standards Action。RFC 8126 后来更新 IANA 政策词汇，更清楚地表明这些标签不是编辑装饰，而是“谁有权批准、需要何种材料”的制度接口。

因此，当前页面不能替代历史文件，历史文件也不能覆盖后续纠正。RFC Editor 状态记录、勘误查询 与 IETF Datatracker 分别保存发布状态、勘误入口和文件演进。RFC 3986 提供通用 URI 架构背景；RFC 6648 后来再次提醒，不能仅凭名称前缀推断标准化程度或安全性。

观察到一个参数之后该怎么读

第一步不是看表上有几个勾，而是记录准确方案、准确拼写和观察时间。第二步是按当时状态找到 IANA 行，并跟进全部引用。第三步从定义 RFC 中确认语法、适用方案与安全条件。最后才检查特定软件版本、配置、事务处理和结果。

一通会话成功，可能只是参数被忽略；一个名称已登记，也可能遇到完全不认识它的旧实现。两者都不能越级替下一层作证。RFC 3969 的历史价值正在于它主动扩大“保留”范围，却严格没有扩大“适用”结论。成熟的证据系统也应如此：为防冲突而宽占位，为判断行为而窄推断。

来源