摘要

  • RFC 3354 要求设想中的 IOTP v2 能够动态提议任意交易步骤，但一项步骤出现在序列里，并不代表客户已经同意付款，也不代表该步骤已经发生。
  • 有上限的未来购买许可、发货通知、外部支付授权、实际扣款、结算和交给客服的签名收据，必须保留为彼此独立的事实。

仓库发出一条“已经发货”的消息，支付处理方随后看到扣款步骤。机器最容易犯的错误，是把这两件事之间的先后关系理解成命令。可是一笔真实交易还需要回答：谁报告了发货？客户允许扣多少、扣几次？支付机构是否授权？资金是否已经捕获并结算？流程的箭头没有资格代替这些答案。

2002 年 8 月发布的 RFC 3354 是一份 Informational 级别的需求文件，讨论 Internet Open Trading Protocol 第二版可能怎样设计。IOTP v1 已经用角色、交易块和消息组织电子交易。需求工作的目标是在尽量保留现有功能的前提下，摆脱“一次付款，然后一次交付”的固定模式。未来的协议应允许参与者提出任意顺序的交易步骤。

这里最重要的动词不是“执行”，而是“提议”。交易方可以提出先询价、后确认，可以在 IOTP 步骤之间调用外部支付协议，也可以等到物流事件出现后再请求付款。这个序列描述候选依赖关系，却不会自动产生客户同意、支付方授权或执行证明。

RFC 3354 本身也不是 IOTP v2 的完成版规范。它把需求分成“将包括”“可以包括”和“不在范围内”三类。IETF TRADE 工作组历史显示，v2 需求里程碑已经完成。这只能证明需求整理工作完成，不能证明 v2 协议、实现或部署随后完成。

必备能力已经相当广泛：动态交易序列、报价请求块、更好的问题处理、定义更清楚的 Customer Care 角色、无需封装在 IOTP 内部的外部支付协议，以及服务器端钱包。出现争议时，客户可以向客服展示签名收据。但收据只是受范围约束的证据，并不会强迫客服退款，也不能证明接收者拥有处理争议的权限。

服务器钱包同样只是一项被委托的能力。钱包存在，不等于当前操作者已经通过身份验证，更不等于旧许可可以无限扩张。支持外部支付协议则说明交易编排与支付执行属于不同控制面：IOTP 可以协调一次支付，却不能借此吞并支付系统自己的认证、授权、拒绝和结算结果。

持续或重复付款只在“可以包括”的可选清单中。RFC 给出的例子十分克制：客户可以批准有限次数的未来购买，并设置总金额或单笔金额上限。有效的授权至少要标明对象、用途、币种、剩余次数、单笔和累计上限、到期时间以及撤销状态。交易模板里出现“以后付款”几个字，并不能补齐这些条件。

此后的每一次请求都需要重新与授权范围比较。请求可能没有超过次数，却超过单笔上限；也可能金额很小，但已经过期；还可能来自错误的商户或用途。编排引擎可以安排这项检查，却不能因为付款块排在同意块之后，就宣布检查已经通过。

发货通知从事件一侧揭示了同样的区别。RFC 3354 设想，增强的服务器间消息可以让 Delivery Handler 告诉 Payment Handler 货物已经发出；这一消息可以成为信用卡扣款的一项前提。前提不是命令。它最多证明某个可识别的处理方，在特定认证范围内作出了一项陈述。

它没有证明商品已经送达，没有证明客户接受，也没有证明发卡方授权、支付完成或资金结算。可审计系统应分别保存发货陈述、把该陈述用于某项付款请求的规则判断，以及支付系统给出的授权或拒绝。如果真的扣款，捕获与结算还会产生新的回执。把全过程压成“发货触发付款”，会恰好抹去重复、乱序、撤销和争议发生时最需要的证据。

相邻 RFC 进一步说明这些层次。RFC 2801 定义 IOTP v1 的交易、角色、标识符与幂等处理；那解决的是重复消息等问题，并不把 v2 的新序列变成购买授权。RFC 2802 用 manifest 限定数字签名覆盖哪些组成部分。签名只能认证被选中的内容和处理范围，不能创造缺失的同意。

RFC 2935 规定通过 HTTP 传输 IOTP。消息被送达，不代表它拥有某种商业效力。RFC 3106 统一电子商务信息的字段名称；共同词汇让系统更容易交换数据，却不会验证地址、身份或权利。RFC 3275 提供 XML Signature 的语法与处理规则，RFC 2246 则提供 TLS 通道保护。

RFC 3354 明确承认：IOTP 自身不提供机密性，应依赖 TLS 或 IPsec；支付保护仍由选用的支付系统负责。加密通道、签名内容、客户同意和扣款授权彼此相关，却绝不能互相替代。一个消息通过安全连接到达，只能说明通道属性，不能说明收款权利。

给现有交易块添加字段和属性，也是可选扩展能力。扩展提高的是表达容量，不是数据权威。即使字段名叫“已批准”，它仍然只是一项断言；只有弄清生产者、签名范围、决策依据、适用对象和当前有效性，系统才能决定是否依赖它。

法律和监管问题被明确排除在范围外。遵守协议不能证明合同可执行、符合消费者保护规则，或在特定司法辖区拥有扣款权。这不是遗漏一段 XML 就能修复的问题，而是通用协议必须承认地方制度与商业权力不会自动汇入同一套消息语法。

RFC 3538 后来为 IOTP v1 与 SET 提供补充；RFC 3867 则定义 IOTP 应用核心与支付模块之间的接口。后者让分界更加具体：交易应用协调动作，支付模块执行特定支付系统的逻辑，两边保留不同结果和错误。它们提供背景，却不能倒推出 RFC 3354 的 v2 需求已经成为部署事实。

RFC 3354 的历史价值，正在于它扩展表达能力时没有虚构权力。序列是计划；未来购买同意是有界许可；发货通知是事件证据；签名认证有限内容；TLS 保护传输；支付系统决定授权、执行和结算；客服补救又是后续制度行为。

今天，物流状态放款、订阅周期发起扣款、使用量跨过阈值生成账单，都重现了同一问题。自动化流程越可组合，越不能把“下一步是什么”误当成“谁有权让它发生”。RFC 3354 给出的设计方向并不保守：序列可以自由， irreversible 的动作却必须在执行时拿出自己的授权和回执。

Sources