摘要

  • RFC 3504 修复了 IOTP 第一版的三类可执行表面：DTD 语法、认证后的原交易连续性，以及 IOTP 签名能够声明的内容类型列表。
  • 应用勘误只能证明实现对齐了修正规范，不能证明认证成功、签名者有权、扣款获批、资金结算、商品交付、实际部署或行业采用。

普通文章把“重启”改成“继续”，看起来只是编辑。在交易状态机里，这个词决定软件是保留抵达认证关口的商务上下文，还是假装整段交换从起点重新发生。

RFC 3504 于 2003 年 3 月以 Informational 文档发布，汇集 IOTP 第一版规范发布后发现的错误，尤其是篇幅巨大的 RFC 2801。IOTP 是与具体支付系统无关的互联网商务框架，购物站、支付处理方、交付方和客服可以由不同组织承担。

角色分散使共同语义格外重要。交易穿过组织边界时，消息必须保留自己属于哪一笔交易、代表哪一种动作。一处语法或状态差异不会只留在本地解析器里，它会改变另一组织接收到的商业上下文。

第一项修正涉及 PackagedContent。原 DTD 把 Name 和 Content 的属性类型写反了。勘误把 Name 定为 NMTOKEN，把 Content 定为 CDATA。这个扩展容器并非边角字段；认证挑战、订单、品牌、支付方案资料、收据和交付数据都可能使用它。

从旧声明生成的代码会把词法限制加在错误位置。一个生成器认为有效的值，可能被另一个解析器拒绝。“支持 RFC 2801”于是隐藏了版本问题：支持印刷出来的 DTD，还是支持勘误后的 DTD？

第二项修正更短。名为 Attribute 的元素使用了错误的 ( ANY ) 内容模型，正确声明是 ANY。验证器无权猜测一个无效语法原本想表达宽松内容。没有共同勘误，不同团队可能各自改写、关闭验证或加入互不兼容的特例。

通过修正后的 DTD 仍只是狭窄凭据。它说明元素、属性类别和内容结构符合修复后的合同，不说明嵌入声明真实，也不说明交易对手有权或外部支付系统已经转移资金。

最能说明问题的是状态修正。RFC 2801 讲述如何把认证交易与另一笔 IOTP 交易组合。原文说认证成功后，原 IOTP 交易会被“重启”；RFC 3504 把它改为“继续”。

修正让身份穿过关口而不重建交易。认证是更大交换中的条件，成功并不会制造第二次购买，也不会清空先前决定。交易标识、累计组件、幂等记录与授权范围可以继续归属原上下文。

“继续”也不声称认证真的成功。它只定义成功这一条件成立后的动作。真实系统仍要产生与参与者、方法、挑战、响应和交易绑定的认证决定。即使身份获证，也不自动授权随后的付款或交付。

第四项修正补齐签名类型分派。原列表包含报价、付款、交付、认证请求与响应，以及 ping 请求与响应，却遗漏 AuthenticationStatus、InquiryRequest 和 InquiryResponse。

RFC 3504 加入这三类，并在角色表中允许任何角色使用。依照旧白名单的严格验证器可能拒绝修正后合法的类型；过度宽松的验证器又可能在没有明确规则时接受。勘误恢复了类型标记与所声称签署内容类别之间的共同映射。

识别类型不等于验证签名，验证签名也不等于签名者具有商务权力。真实的查询响应可以报告某种协议状态，却不能单独证明银行完成结算、交付方送出商品或客户接受结果。

RFC 3504 说这些错误并非特别与安全有关，紧接着又警告：因未修正规范错误造成的错误实现可能危害安全。两句话并不矛盾。勘误没有发明密码算法，却修正支撑安全敏感处理的语法、状态转换和分派表。

因此，勘误可以成为可执行依赖。资产清单不能只写“实现 RFC 2801”，还应记录基础文档、采用的修正集、解析器或 schema 构建产物，以及针对变化行为的测试。缺少这些来源信息，两份相同的兼容声明可能对应两台不同的机器。

文档元数据本身也展示了这一问题。RFC 3504 的页眉没有声明 Updates: 2801。RFC Editor 当前保留待文档更新的勘误 2947，认为它进行了规范性修改，因此应标示这一关系。也就是说，修正文已经影响执行，而关系元数据没有完整表达这种力量。

一条诚实凭据链应从精确的文档版本与勘误集合开始，随后记录可重复构建的解析器、具体文档被接受、原交易身份被保留、认证决定、签名类型识别、密码验证、商务动作授权，以及外部付款或交付结果。

每一级回答不同问题。语法说明消息可解释；连续性说明哪个上下文仍存在；类型标记说明签名声称覆盖什么。它们都不能单独或合并成“购买已经付款并履约”。RFC 3504 的历史意义恰在于：六页修正可以决定大型协议如何运行，却不能取代现实结果的凭据。

来源