摘要

  • RFC 9171 将接收、转发、本地交付、删除和状态报告界定为不同的 Bundle Protocol 状态；报告只陈述产生它的节点所声称的状态。
  • BPv7 本身不确保端到端交付，custody transfer 也不再属于基础协议的状态。因此，接收不能证明保管、应用处理、授权或外部结果。

延迟容忍网络的设计前提，是通常的连续对话可能不存在。连接会中断，时延可以很长，发送方作出动作时下一个邻居未必在线。Bundle Protocol Version 7（BPv7）把应用数据与使其在可能交付时得以使用的协议材料放在一起传递。在这样的环境里，“已发送”和“已完成”不是一条可审计的事实链。

RFC 9171 因而为不同事件保留不同的动词。Transmission 是 Bundle Protocol Agent（BPA）尝试使副本送达某个 endpoint 成员；forwarding 是调用一个或多个 convergence-layer adapter，持续努力让副本被另一节点接收；delivery 则有更窄的本地含义：依据一项本地 registration，载荷及相关元数据已经呈交给该节点的 application agent。删除、丢弃和阻止丢弃的 retention constraint 又各自是不同状态。

这不是术语洁癖，而是证据范围。一个被转发的 bundle 未必被下一节点接收；一个被接收的 bundle 未必能在当地交付；一个被交给 application agent 的载荷未必被它处理；一份描述上述任一事件的报告也未必已经到达需要据此行动的人。把所有步骤涂成同一个“已交付”状态，会让画面更简单，却使责任发生在何处变得不可追溯。

接收流程本身就说明了这一点。当 BPA 从另一节点接收 bundle 时，首先加入名为 “Dispatch pending” 的 retention constraint。若 bundle 请求报告接收状态，且状态报告已被启用，BPA 应向 report-to endpoint 生成一份接收状态报告。这支持的是一项窄而真实的观察：该节点已经启动 RFC 所规定的接收处理。

它并没有保证后续处理会保留该 bundle。BPA 要计算附加的 CRC；若 bundle 格式不合规，或者某个附加 CRC 与接收时计算的值不一致，BPA 必须以 “Block unintelligible” 原因删除它，并跳过其余接收步骤。不能处理的 extension block 同样可能先触发报告，再依其控制标志导致删除或移除。于是，“已生成接收报告”绝不能被扩大解释为“合规对象已被保留、转发或交给应用”。

转发也有自己的边界。BPA 选择要转发到的节点和适当的 convergence-layer adapter，再请求其发送。相关的数据发送程序是否已经构成成功转发，是规范明确留给实现决定的问题；若未成功，BPA 可按本地配置再次尝试。请求得到的转发报告，陈述的是这个转发状态。它不是下一节点的收据，不是路径会持续可用的保证，也不是目的 endpoint 已收到数据的证明。

抵达目的端后，边界更清晰。本地交付取决于目的 endpoint 对应 registration 的状态。fragment 可能必须先完成重组；被动 registration 或实现特定的交付失败，可以令交付延后或被放弃。即便后来生成了 bundle delivery status report，RFC 9171 仍特别说明：它只表示载荷已经交给 application agent，不表示该 agent 已经处理了载荷。

这句限制对任何自动化控制都很重要。application agent 可以按自己的规则验证、排队、拒绝、延后、转换或忽略数据。BP 状态并不会说明哪一项发生了。它不识别业务责任人，不证明有权的人审阅了结果，也不证明某项不可逆指令已被执行。若这些事实重要，就应由应用和作出决定的系统在各自层面留下独立记录。

状态报告本身也不是无所不知的审计账本。RFC 要求其生成功能默认关闭，因为大量请求可能造成过多网络流量；即使启用后，是否生成被请求的报告仍由 BPA 决定。报告里若包含时间，该时间来自报告节点的本地时钟，且属于实现问题。报告因此只是由一个节点提出、再作为另一个 bundle 发往 report-to endpoint 的有限陈述；它不是全球无损时间线，也不证明预定阅读者已收到它。

历史上的 custody 对比尤其值得保留。实验性质的 RFC 5050 定义过 custody acceptance 和 custody signal。RFC 9171 自己的注册表格将相应请求标志列为 version 6 值，附录 A 则说 custody transfer 已迁往 Bundle-in-Bundle Encapsulation 规范。基础 BPv7 仍有 retention、转发、本地交付、报告和扩展机制，但没有把接收变成承诺保管。真正需要保存责任承接的人，必须写明使用的机制、条件和失败处理，不能从一个接收位推导出这一结论。

RFC 9171 对最大的限度也说得直接：Bundle Protocol 本身不确保 bundle 到达目的地。可靠的 convergence-layer protocol 可以减小相邻节点之间的丢失；端到端交付保证需要 BP 扩展和/或应用层机制。这不是协议遗漏的承诺，而是诚实的责任划分。它记录 BPA 在一个明确位置对 bundle 做了什么，却不假装能替应用、人员或机构证明之后发生的事情。

对领导者而言，问题不在于应否相信一份接收报告，而在于记录是否只说自己知道的内容。应分别保存接收节点事件、转发事件、本地交付、应用处理、确认、业务批准和外部执行；每一项都要标明谁在陈述、依据哪一规则、送往哪里、使用何种时钟以及何时会失败。范围狭窄但真实的记录可以组合；一盏假装覆盖一切的绿灯，事后无法通过补充文字变成可靠证据。

卢恒所强调的表征、本地决定和运行现实之间的区分，在此可作为一种编辑纪律。BP 状态报告是对有限协议状态的表征，应按其所表征的事实被信任，而不应被升级成授权或成功的宣言。运行中的系统只有把已观察到的事件与仍待其他主体选择和执行的后果区分开，才能真正获得韧性。

来源