摘要

  • RFC 3080 允许多组彼此独立的交换共享一个 BEEP 会话。通道零只管理会话；应用通道必须绑定一个已被接受的 profile，才有自己的语法与语义。
  • TCP 已连接、greeting 合法、能力已宣布、通道已打开、应用已产生效果，是五件不同的事。低层成功不能替高层作证。

线路已经亮起，对话却还没开始

设想两个端点已经建立连接，双方都能解析通道零上的 greeting，但第一个 start 提出的所有 profile 都被拒绝。此时线路没有故障，会话管理也没有语法错误，可两端仍然没有共同的应用语言。

这正是 RFC 3080 在 2001 年 3 月划出的边界。它以 Standards Track RFC 的形式定义 Blocks Extensible Exchange Protocol Core，为面向连接的异步交互提供一个通用内核。它允许多组交换在同一应用用户身份之下同时进行，却没有把“一个连接”写成“一个应用”。

连 BEEP 会话如何落到底层传输上，都由另一份规范负责。RFC 3081 把一个 BEEP 会话映射到一条 TCP 连接。因此，TCP 建连只是一张传输回执；它没有选择 profile，也没有证明任何业务已经准备好。

通道零只负责开门

会话刚开始时，唯一存在的是通道零。它承载 greeting、profile 能力清单、通道创建、通道关闭与会话释放。

能力清单不是选举结果。某个 URI 出现在 greeting 里，只表示本端作为 server role 时能够支持它，并不表示另一端已经获得一条使用该 profile 的通道。规范甚至提醒，示例中先出现谁的 greeting 只是排版效果；真实的两个 reply 是独立发送的。

真正的绑定发生在 start。发起方提出一个通道号和一个或多个 profile URI；接收方可以选中一个并返回肯定 reply，也可以全部拒绝。只有那一刻，数字、profile、端点和会话才结合成一条有意义的通道。

奇偶规则让双方不必争夺一个中央分配器。initiator 只用正奇数，listener 只用正偶数。未来新通道仍由各端自行决定，共同层只保留避免冲突所需的最小规则。

Profile 才是通道的语言

BEEP core 提供交换形状，不替应用写含义。MSG 发起请求，RPY 或 ERR 结束一对一交换，ANS 返回多项答案，NUL 宣告答案序列结束。message number 区分同一通道上的交换；payload sequence number 则随该通道中的每个 frame 前进。

不同通道的 frame 可以交错出现。一个被切分的消息在自己的通道里仍须保持顺序；多个 ANS 可以借助 answer number 交错并重新归并。这说明并发被允许，却不保证公平、及时或成功。顺序合法，只是应用成功的前提之一。

后续 RFC 展示了责任如何继续留在 profile。RFC 3195 为可靠 syslog 定义自己的 BEEP profile。RFC 4227 让 SOAP profile 再经历 boot 与 ready。RFC 4744 把 NETCONF 放进 profile，同时明确 manager/agent 不等于 BEEP 的 initiator/listener。承载方向与应用权力没有天然对应关系。

安全升级后，旧证据必须作废

RFC 3080 把初始 tuning channel 与持续数据 channel 分开。TLS 与 SASL 可以在长期交换开始前改变隐私和身份条件，同一时刻只能有一个 tuning channel 处于活动状态。

TLS 成功以后，端点必须丢弃保护建立之前缓存的会话信息。中间人可能已经修改过旧 greeting 或能力数据。新的加密层不能替旧缓存洗白；新状态需要重新取证。

认证也不是通行证。规范要求每条通道在执行任务前，根据已认证身份和隐私级别实施相应访问控制。知道对方是谁，不等于必须接受其 profile，更不等于允许其消息改变外部状态。

共享连接，也要共享资源账本

RFC 3081 揭示了多通道的物理代价。TCP 的 flow control 以整条连接为单位；如果没有额外约束，一条读取缓慢或持续发送的通道可能让其他通道饥饿甚至互相卡死。

TCP mapping 因此给每条通道增加 sliding window。新通道从 4096 octets 开始，接收方用 SEQ 表明下一段期望的 sequence number 与可接收窗口。TCP 负责可靠传送；这个窗口负责会话内部的容量分配。

所以“独立”不是通道号带来的幻觉。它要靠各自的顺序、缓冲、进度和失败记录来维持。

端口被释放，并不改写分层事实

BEEP 后来拥有 syslog、SOAP、NETCONF 等 profile。更晚的 RFC 9900 释放了 NETCONF over BEEP 以及 NETCONF over SOAP 的端口号，同时保留服务名。

这段历史不该被压缩成“成功”或“失败”。RFC 发布不是部署证明；端口释放也不是对原始分层设计的否定。规范状态、注册表记录、可运行软件与常见使用各有自己的生命周期。

RFC 3080 留下的判断方法更窄，也更可靠：greeting 只证明能力宣布，start reply 只证明 profile 绑定，应用 reply 只证明协议交换。配置是否持久、日志是否写入、服务是否改变，还要到应用与现实层分别核验。

来源

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/