摘要

  • RFC 3529 规定，XML-RPC 的正常结果与 fault 都放在 BEEP RPY 中；应用故障并不改用 BEEP ERR。
  • 名称解析、通道就绪、隐私保护与对端认证各有证明范围，但都不能代替方法授权、执行成功和持久结果。

一张只记录帧类型的监控表会把 RFC 3529 看反。表中若出现 RPY，BEEP 的一对一交换确实完成了回复阶段；然而 XML 文档内部可能明确写着 fault。外层为正，内层为负，并非协议矛盾，而是两个判断对象不同。

这条边界从通道初始化开始。XML-RPC profile 初始处于 boot。发起方发送带有资源路径的 bootmsg。服务器识别资源后返回 bootrpy，profile 才进入 ready。若消息格式错误或资源不被识别，服务器返回 error 或 ERR，状态不前进。此时失败的是 profile 启动，不是某个 XML-RPC 方法。

进入 ready 后，客户端把 methodCall 放入 BEEP MSG，服务器把 methodResponse 放入 RPY。RFC 3529 特意说明：执行 XML-RPC 时，不以 BEEP ERR 表示 XML-RPC fault；服务器生成的任何 XML-RPC response 都放进 RPY。所以 RPY 证明“有一份属于该请求的回复”，并不证明“远程过程返回正常值”。

这种设计保留了故障所属层次。BEEP ERR 表明通道、profile 或交换本身无法按约工作。RPY 内的 fault 则表明请求已经到达足以解释调用的应用逻辑，并由该逻辑给出否定结果。两者都可能需要处置，却不能共享一个错误代码或一条恢复策略。

地址选择又位于更外层。xmlrpc.beep URI 的 authority 对应 BEEP serverName，path 对应 bootmsg 的资源。没有显式端口时，客户端先按 SRV 规则寻找 _xmlrpc-beep._tcp；没有合适记录时，再解析地址并使用已分配端口。DNS 成功只说明选出了目的地，不能说明端口正在监听，更不能说明资源、方法或调用结果。

xmlrpc.beeps 沿用同一地址算法，却要求在启动 XML-RPC profile 前先把 BEEP session 调整为具备隐私保护。使用 TLS 时，客户端还要把 URI authority 与证书中的服务器身份进行匹配。这可以回答“受保护地连接到哪个对端”，但回答不了“此身份是否有权调用该方法”，也不能保证参数合规、业务条件成立或数据已经落盘。

安全章节也留下了鲜明年代。规范要求提供 DIGEST-MD5，以及采用 RSA/3DES 套件的 TLS profile；合并保密与认证时还提到客户端证书。后来的 SASL 与 TLS 文档改变了这些选择的地位。因此，RFC 3529 可用于理解 2003 年的分层设计，却不应被当成今天的密码配置清单。

IANA 登记同样只是最小公共语义。文档申请登记 BEEP profile、xmlrpc.beep 与 xmlrpc.beeps 两种 URI scheme，以及 TCP 602 上的 xmlrpc-beep 服务名。登记能证明名称被协调，不能证明实现存在、服务在线、流量发生或方法成功。符号表不是运行现场。

这一实验处在 XML 调用协议与可复用会话协议相遇的阶段。BEEP core 提供 session、channel 与消息类型，TCP mapping 管理共享连接上的传输，SOAP over BEEP 展示了相邻做法，XML media type 则约束文档表示。层次越丰富，越不能用最外层的一个绿色指示灯代表全部结果。

审计一次调用，至少要保留原始 authority、SRV 或地址选择、对端身份、channel、资源、BEEP message number、外层帧类型，以及内层 methodResponse 是正常参数还是 fault。若方法修改状态，还要补上应用自己的持久证据，例如操作标识、版本号、审计记录或后续读取。

重试最能暴露证据缺口。连接在收到回复前断开，调用是否执行可能仍不确定。收到含 fault 的 RPY，能证明应用给出否定结果，却未必证明绝无部分副作用，除非方法契约明确保证。若监控系统只看外层，可能把 fault 记为成功；若只看超时，又可能重复执行非幂等动作。

RFC 3529 的状态是 Experimental。它不支持关于市场采用率或现行部署的宏大叙事。它留下的历史教训更朴素：协议层可以成功地运送一份失败判决。可靠系统应同时保存“送达了什么”和“内容判定了什么”。

Sources