摘要

  • RFC 1602 原本设想一份长期公开、可由实施者执行的许可表格；RFC 1915 接受了更概括的授权承诺，以解除 PPP 压缩和加密控制协议的标准化停顿。
  • 例外决定本身经过公开说明、延长的 Last Call 和申诉机制，但它只能授权 IETF 的程序动作，不能证明未来每份许可证的价格、速度和条件真正平等。
  • RFC 1962 与 RFC 1968 后来正式发表，证明控制协议完成了标准文本，不证明专利有效、许可已经取得、产品符合标准、网络实际部署或端到端安全成立。

缺的不是另一个数据字段

PPP 工作组已经把两个控制协议推进到 IESG。CCP 用于协商链路压缩，ECP 用于协商链路加密。它们解决的是端点之间如何声明能力、选择算法以及在状态失步时如何复位，而不是谁有权实施某种算法。

Motorola 随后告诉 IETF，这些工作可能涉及美国专利 5,245,614 和 5,130,993。RFC 1915 记载，协议提交标准化后，进程因这些权利主张停下。工程文稿可以完整，法律与商业入口却仍然不完整。读取所有比特，并不能读出实施许可的价格；互通测试成功，也不能替企业签署合同。

这正是证据层必须分开的地方。专利主张、专利是否有效、技术是否落入权利范围、权利人愿意谈判、实施者收到要约、双方签约、产品上线，是七件不同的事。把它们压缩成“标准已批准”，只会让最后承担成本的人失去判断依据。

RFC 1602 要求的是可执行文本

当时适用的 RFC 1602 不满足于权利人表达善意。它附带的模型安排要求向 Internet Society 提供用于标准工作的免费许可，并设想让互联网社群的实施者可以在合理条件下取得许可。它还包含一项自动调整机制：后来给别人的条款更有利时，既有许可证也应随之改善。

更关键的是，许可证表格应一直在互联网上公开可得。实施者可以事先读到文本，填写并送达权利人，使其生效。共同文件不会消除所有争议，却把起点固定下来：适用对象、权利范围、执行方式、版本变化都可以被比对。

公开表格是一种薄而有力的协调。它不替市场决定价格，却降低谈判前的信息差；它不裁判专利，却让各方知道自己签的是什么；它不保证每家公司作出同样选择，却让“是否拿到同一入口”成为可审计问题。

RFC 1915 说明，IETF 没有拿到这样的表格。Motorola 更愿意发布一份一般性声明：将向任何一方提供许可，条件合理，并且可以证明不存在不公平歧视。声明列出了专利和联系人，也被完整收入公共记录。但承诺未来会给合同，不等于把合同放在桌上。

“合理”需要数字，“不歧视”需要比较

一个申请者只能看到自己收到的要约。没有共同表格，就还要记录什么时候提出请求、什么时候得到答复、覆盖哪些产品和地区、费用如何计算、有哪些限制、何时生效。另一家公司是否得到更快或更宽的条件，不能从第一份要约中推出。

RFC 1915 对此并不天真。它明确列出风险：权利人可能分别对待不同请求，推进某些请求，拖延另一些请求。这会违背 IETF 关于开放和平等获得技术的传统。例外的真实含义因此不是“风险已解决”，而是“风险已被公开识别，但标准化不再等它完全解决”。

证据的位置随之改变。RFC 1602 的方案把更多许可机制留在共同文档中；Motorola 的承诺把价格、时限和实际平等待遇移入未来的双边关系。协议文本仍然公开，进入实现世界的商业路径却变得不对称且不易观察。

技术绕行没有形成可信的共同选择

工作组曾考虑修改协议，以避开被主张的专利。RFC 1915 说，这在技术上可行，但一些成员认为修改后的方案明显不如原设计，并直言无论工作组或 IESG 最后标准化什么，他们仍会实现原始 CCP。另一些人接受替代方案，也更多是因为看不到其他出路，而不是认可它的技术质量。

这不是围绕更佳设计形成的粗略共识。它更像两个坏结果之间的挤压：坚持原程序，协议继续冻结；选择不受欢迎的替代，正式标准可能与实际代码分裂。运行代码没有自动取得法律权威，法律主张也没有自动取得技术优越性。双方都无法消灭另一层的问题。

RFC 1915 选择了第三条路：不把技术争议伪装成已解决，而是用程序例外放行原设计。IESG 接受 1995 年 6 月 5 日的承诺，让 CCP 和 ECP 可以进入标准轨道。

例外不是暗门

RFC 1871 在此前数月为这类僵局建立了 variance 程序。它允许在既有规则失灵或没有提供指引时作有限偏离，但要求整个过程公开，并让相关方有评论机会。

负责的工作组提出问题，IESG 提出解决方案，延长的 Last Call 接受公开审查。IESG 必须比较偏离规则给互联网社群带来的收益与成本，考虑技术价值、其他办法、先例和连带影响，并把例外压到尽可能窄。IAB 负责听取申诉。

因此，RFC 1915 不只是结论，也是程序收据。它记录哪项要求没有满足、为什么技术替代失败、接受了什么承诺、预期收益是什么、风险由谁承担。它足以证明 IETF 如何授权自己的程序继续，却不足以证明任何后来申请许可的人得到了公平结果。

两份协议发表，不等于所有门都打开

1996 年 6 月，CCP 作为 RFC 1962 发表，ECP 作为 RFC 1968 发表。两份标准说明了配置协商、复位和算法选项，也给专有机制保留了按组织标识符区分的空间。公开定义的算法同样可能附带许可限制；加密还可能受到出口限制。

CCP 没有共同压缩算法时，可以不压缩而继续链路。ECP 无法找到双方都同意的加密选项时，端点可能需要关闭链路。控制协议的存在从来不保证某种算法必然可用，也不保证两个方向作出相同选择。

RFC 1968 还把安全边界写得很窄：保护强度取决于具体算法和秘密材料的保管，完整安全仍需要主机之间的端到端机制。标准发表不是保密性测量，更不是专利许可、密钥管理和应用结果的总证明。

后来的程序换了一种证据安排

1996 年 10 月，RFC 2026 取代 RFC 1602。它仍要求秘书处尝试取得书面保证，使任何一方能够在公开说明、合理且不歧视的条件下实施、使用和分发相关技术，但尝试结果通常不再决定标准能否前行。它也没有保留 RFC 1602 那套在线可执行许可表格的结构。

RFC 2026 进一步说明，IESG 不会明确判定“不歧视”在实践中已经兑现。不同组织的独立实现和后续运行经验可以支持推定，Last Call 期间仍可挑战这种推定。

这段时间顺序证明政策发生了变化，却不证明 RFC 1915 单独造成了 RFC 2026。更稳妥的历史结论是：技术机构能够要求披露、请求承诺、公开例外并决定自己的标准程序；它不能裁定专利效力，不能替实施者签约，也不能只凭一封公开信观察所有私下交易。

来源与边界

这些官方材料证明当时的程序文本、权利主张、公开承诺、例外与后续标准文件。它们不证明专利有效或必要，不给出每次许可谈判的费用和结果，也不证明任何具体产品获得许可、符合标准、互通、部署或实现端到端安全。