摘要

  • RFC 1197 把 ODA 描述成复合文档的抽象表示架构；有效互换还需要 document application profile 选定共同实体，再由各系统把这些实体映射到自己的原生模型。
  • NSF 资助的 EXPRES 采用 NIST DAP，并面对 Andrew、Diamond 与 Interleaf 三套功能表面。RFC 只确认研究范围，没有给出保真率、往返测试或部署结论。
  • 后来的 MIME/X.400 规则把 ODA 正文、profile 与文档 class 分开处理。字节复制可以证明正文未被改写，不能证明接收端以同样方式理解、呈现或继续编辑。

一个默认值会让机器继续，却不会替发送者回忆

1993 年的 RFC 1494 规定，MIME 一侧缺少 ODA 的 profile 或 class 时，网关可以采用 Q112 与 formatted-processable。这样转换就有了确定答案，不必因为缺字段停住。

但“确定”不是“原意”。默认值说明规则在信息不足时如何行动，不说明发送者曾选择过它。若后来的记录只留下 Q112，而丢掉“由网关补入”这一来源，人们就会把系统的应急决定误读成作者的声明。

这正是 RFC 1197 更早揭示的问题：共同格式、共同配置与应用解释不是同一层。文件可以有合法表示，交换双方却还没有把所有有用概念变成共同约定。

ODA 的抽象从段落之上开始

Mark Sherman 在 1990 年 12 月发布 RFC 1197，介绍 EXPRES 项目使用 ISO 8613 Office Document Architecture 的经验。RFC Editor 档案与 IETF Datatracker 档案都将其列为 Informational；它没有制定 Internet Standard。

文档说，ODA 能表示多字体文本、光栅图像与几何图形，也已被用于 X.400 等相关标准。它追求的不是某一家编辑器的存储格式，而是一种可以覆盖多类复合文档的通用架构。

通用性也带来距离。RFC 1197 说 ODA 定义的是 composite logical object classes 之类的抽象实体，而不是“段落”这样的常用实体。这不等于 ODA 永远无法表现类似段落的结构；更窄的事实是，基础架构没有替互换共同体选定那个应用对象及其行为。

若标准直接采用某个产品的段落、样式与页面模型，它会降低该产品的适配成本，却可能把其他系统变成二等公民。ODA 把中心做得更一般，代价是边缘必须承担显式选择。

DAP 先缩小语言，本地映射再让语言可执行

RFC 1197 把第一层选择称为 document application profile，简称 DAP。DAP 在庞大的 ODA 空间里定义一组共同实体。每个参与系统还要建立另一张图，把 DAP 实体接到本地真正使用的实体上。

两者不能合并成“支持 ODA”。配置维护者决定交换共同体承诺使用什么；产品实现者决定这些承诺如何落到内部结构、排版规则与编辑命令。一个工具可以识别 ODA，却不支持同一 DAP；也可以支持同一 DAP，却在可选属性或扩展上出现差异。

因此，较小的 profile 不是较差的标准。它把广阔的可能性压缩成可测试的契约。产品仍可以保留更丰富的原生能力，只是不能在没有证据时把它们称为可移植能力。

真正的互操作交集至少包括 profile 版本、文档 class、所用扩展、发送端映射与接收端映射。母标准的功能总表不能替代这组交集。

EXPRES 没有假装三套编辑系统天然相同

National Science Foundation 资助 EXPRES，研究通过电子邮件提交研究提案时能否使用 ODA 作为互换媒介。项目包括 Carnegie Mellon University 与 University of Michigan 的团队，并与 McDonnell-Douglas Aerospace Information Systems、NIST 和 Interleaf 合作。

RFC 1197 说，策略以 NIST DAP 以及 Andrew、Diamond、Interleaf 所提供的功能为基础。这个表述把工作面暴露出来：一个共同 profile 面对的是三套不同的本地能力，而不是三个同名接口。

两页 RFC 没有公布页面对比、结构丢失率、往返编辑结果、转换耗时或提案受理结论。详细策略在另一本 1991 年出版的书中，当前证据包不包含该书。因而不能用项目名称填补结果空白。

参与机构也不是永久背书。RFC 的免责声明明确把书中信息归于作者意见，而不是各机构政策。来源能确认谁参与了所述研究，不能确认今天的支持状态或某个产品的总体质量。

MIME 把 profile 放到了格式名称旁边

RFC 1341 在 1992 年为早期 MIME 定义 application/oda。这个 subtype 声明正文按照 ODA 标准采用 ODIF 表示；同一 Content-Type 还应通过 profile 参数指出 DAP，示例为 profile=Q112。

若“ODA”一词已经完整决定应用语义，旁边无需再放 profile。把二者分开，说明媒体类型回答表示家族，profile 回答其中哪一套共同约束。

这仍是声明，不是执行结果。收件程序可以凭它选择处理器，也可以宣布不支持。它不能仅凭头字段证明 Q112 已正确实现、正文没有使用未知实体、排版保持一致或编辑意图仍可恢复。

RFC 1341 现已过时。这里引用它，只是为了定位 1992 年的历史边界，并不把它当作当前 MIME 操作手册。

Byte copy 保存了正文，却没有消灭元数据决策

RFC 1494 为 1988 X.400 body 与 MIME body 建立对应关系。ODA 正文的 conversion type 是 “Byte copy”；网关可以不重写 ODA 数据。

同一规则却另外把 X.400 的 document-application-profile 对象标识符映射成 MIME profile，把 document-architecture-class 映射成 formatted、processable 或 formatted-processable。正文、配置与类别各有自己的转换记录。

所以“无损复制”有明确边界：它证明网关没有更改那些正文 bytes。它不证明另一端支持所声明的 profile，也不证明 processable 结构仍成为同样的本地对象。字节身份与应用保真相隔几步。

网关可以选择从 ODA 内部读取 profile 与 class，也可以因这些内部特征是可选项而直接使用默认规则。审计若不保存值的来源，就无法区分作者声明、对象内部信息与网关推断。

Experimental 记录保留了复杂内容的时间风险

RFC 2161 在 1998 年把 ODA 的 MIME/X.400 定义独立整理出来。它明确是 Experimental，不是任何种类的 Internet Standard。它继续保留 profile、class、Q112 与三种文档类别。

表中的 “Conversion: None” 只表示 ODA 数据正文不转换；外围仍要映射参数、补默认值并处理 X.400 envelope 的对象标识符。“不转换”不能被扩张成“不解释”或“效果相同”。

它的安全章节指出，ODA body 具有复杂结构，很难预先知道各部分具有什么能力；ODA 又可扩展，新内容部分会让威胁随时间变化。文档同时说，当时没有已知的 ODA 特有安全风险。正确结论是保留能力与版本的不确定性，而不是事后捏造漏洞。

同一个外层媒体类型可以多年不变，内部扩展、解析器与本地映射却持续变化。“支持 ODA”因此是一条会过期的粗粒度记录。

直到结果被观察，互换才完成自己的证明

一条完整证据链包括：原始 ODIF bytes；媒体类型；profile 的声明、提取或默认来源；class；网关动作；接收端支持范围；本地映射版本；呈现结果；保留下来的结构；可编辑性；往返结果；最终制度性任务。

hash 能证明文件是否改变。profile 能界定预期子集。映射版本能解释某种结构为何消失。视觉与结构比较才能回答输出发生了什么。每一步都有价值，也都不能借用下一步的权威。

RFC 1197 的“段落”提醒并不是说抽象标准无用。恰恰相反，标准因为没有垄断边缘模型，才可能成为共同中心。它需要 profile 把共同承诺缩到可执行范围，需要各端承担翻译，也需要接收者对实际结果作出最后判断。

来源与边界

这些来源不证明当前部署、市场份额、产品质量、EXPRES 的量化保真、已知安全事件或某份提案的成功。