摘要

  • RFC 3983 在 IRIS profile 被接受、BEEP 通道建立后把通道称为 ready；这个状态只证明可以交换约定的消息，并不自动证明服务器或用户身份。
  • 服务器认证可以采用注册类型专属方法、基本 TLS authority 绑定，甚至明确声明不做；加密、用户认证、查询授权与转介目标信任仍是彼此独立的证据。

运维面板常把复杂握手收束成一盏绿灯。连接成功，状态显示 ready，后续系统便假定对端可信、用户已识别、请求可执行、结果可交付。RFC 3983 中的 “ready” 没有这么大的含义。它只出现在一个精确时刻：BEEP profile 已接受，通道已创建，可以开始传送 IRIS 消息。

RFC Editor 的状态记录、勘误记录和 Datatracker 档案表明这是一份 2005 年 1 月的 Standards Track 文档。它把 Internet Registry Information Service 映射到 Blocks Extensible Exchange Protocol。文献状态不能证明部署规模，也不能证明今天存在可用服务。

选择 BEEP 的理由，是复用已经具备的帧分隔、认证、连接管理和协商机制，以及实现工具和运行经验。专为 IRIS 另造传输，仍要重做这些能力。作者认为 HTTP 会与传统 Web 应用混淆，且 TLS 实践不一致；直接跑在 TCP 上，又欠缺转介客户端跨越参数不同的多个服务器时所需的协商。这是规范给出的设计判断，不是性能对比实验。

BEEP profile URI 同时包含 IRIS 模式版本与注册类型 URN。创建通道时，客户端可以提出多个 profile 元素，协商每个已服务注册类型使用的版本。profile 一经接受、通道一经创建，服务器就必须在该 IRIS 通道上响应自己声明过的注册类型查询。这里确立的是共同消息上下文，不是身份结论。

“响应查询”也不等于“给出数据”。默认模式是一问一答：客户端在 MSG 中发送有效的 IRIS XML，服务器以 RPY 返回 IRIS XML；BEEP ERR 用于 profile 层故障。注册类型可以定义其他符合 BEEP 的消息模式，但必须为 lookupEntity 支持默认模式。上层的 IRIS 核心及其状态记录仍可表达不支持、拒绝访问或其他非结果状态。ready 只让问答发生，并不预写答案。

服务器身份另有一套程序。使用 BEEP 的 TLS tuning profile 时，各注册类型最好规定自己的服务器认证方法；未规定时才回落到基本方法。客户端先把希望访问的 authority 写入 BEEP serverName。服务器出示包含该 authority 的 X.509 证书。随后至少有两道不同检查：按照 TLS 验证证书密码学有效性，再依次在 subjectAltName dNSName 与规定的 subjectDN 形式中比对 authority 名称。

证书链有效，不代表名称就是客户端要求的名称；字符串吻合，也不能替代证书链验证。RFC 3983 让两道检查并列，是因为一项判断“这张证书是否可信”，另一项判断“它是否代表我正要访问的权威”。

注册类型清单进一步排除了默认猜测。每一种类型都必须明确消息模式，并且必须在三项中选一：定义 TLS 服务器认证方法、采用基本方法，或明确声明根本不做服务器认证。因此，一个语法正确、协商成功的 IRIS profile 完全可能处在有意不认证服务器的通道上。

用户身份又是另一层。RFC 3983 列出 SASL DIGEST-MD5 与 OTP，可在不加密会话时认证用户；又把 TLS 仅加密的用法，与加入客户端证书从而同时认证用户的用法分开。匿名访问既可以表示没有运行任何认证 tuning profile，也可以采用 SASL ANONYMOUS。于是，加密不等于用户已认证，服务器已认证不等于用户已认证，用户已认证也不等于有权取得某条注册信息。

这种组合方式来自 BEEP。RFC 3080及其状态页、勘误页和 Datatracker 记录定义 profile、channel、message 与 tuning。RFC 3081及其状态页把 BEEP 映射到 TCP。一次 tuning 能改变会话某项安全状态，却不会把其余状态自动变成真。

当时的配套规范说明了可用机制。RFC 2246与其状态页定义 TLS 1.0；RFC 2222与其状态页提供当时引用的 SASL 框架。RFC 2817及其状态页，以及 RFC 2818及其状态页，记录 RFC 3983 讨论的两种 HTTP/TLS 路径。机制存在，不等于某次会话正确启用了它。

转介让凭据边界变得最明显。IRIS 正常运行就可能让客户端访问多个服务器。RFC 3983 提醒客户端不要把凭据交给不受信任的转介目标，建议不要使用 SASL PLAIN，并禁止在 TCP 会话加密前使用它。加密能保护凭据在路上不被看见，却不能证明接收者有资格得到凭据。

后来的 RFC 4992及其状态页又为 IRIS 增加 XPC over TCP 传输并更新核心。这证明传输层可以替换，却不能据此推断任何采用率或替换原因。

今天，IANA URI Scheme 注册表仍保留 iris.beep，IANA BEEP Parameters 注册表仍保留相关 profile 与 tuning 名称空间。登记事实不是在线通道、证书匹配、用户身份或授权结果的证明。

RFC 3983 留下的历史价值，在于给 “ready” 限定了严格的宾语：准备好交换消息。连接、保密、服务器身份、用户身份、权限和结果各有控制者，也各有失败方式。把它们汇总成一个绿色状态，会丢掉这套架构最重要的诚实。

Sources