摘要

  • RFC 3073 登记了 application/font-tdpfr，公开了识别 PFR 文件所需的名称和元数据，却把完整技术细节指向 Bitstream 所掌管的原始规范。
  • 登记名称可以帮助软件选择处理器；它不能证明接收方拥有正确版本的规范、兼容代码、成功解析或忠实呈现。

2001 年 3 月，Bitstream 的 John Collins 以 RFC 3073 为 Portable Font Resource 文件登记 MIME 子类型。登记内容很具体：媒体类型是 application/font-tdpfr，没有必需或可选参数，传输编码须为 binary 或 base64，文件开头的魔数为十六进制 50 46 52 30，扩展名为 PFR，预期用途写作 common。发送者和接收者由此得到一个共同的公开标记，可以说明一段数据声称自己是什么。

这个标记本身并不是格式。RFC 对 PFR 作了足以辨认对象的概述：它把与字符编码关联的字形压缩进一种不依赖平台的资源；轮廓不依赖输出分辨率，可以缩放到任意尺寸，也可包含位图字形。但当读者需要完整功能和技术细节时，文档让其回到原始 PFR 规范。RFC 明言该规范由 Bitstream 定义，可以向 Bitstream 索取，也给出当时的厂商网址。联系人以及作者／变更控制者同样是 Bitstream 的 Collins。

这不是藏在脚注里的偶然缺口，而是登记本身呈现出的制度分工。公共协调层保存名称、模板和简要说明；完整描述性契约仍由另一个机构维护。RFC 还记录了名称的前身：同一种媒体类型此前登记为 application/vnd.truedoc。文档称 DAVIC、DVB 和 DTG 采用该格式之后，才以新的名称重新登记。名称从厂商树迁移到当时用于广泛互联网用途的无前缀树，并不等于完整规范已经复制进 RFC，更不等于每台接收机器上都出现了一个渲染器。

媒体类型首先是分派线索。应用看到 Content-Type，可以查找映射，选择候选处理器，再把字节交给它。每一步产生的凭证都不同：认出字符串，只能证明名称匹配；选择处理器，只能证明配置把名称映射到了某段代码；解析返回成功，只能证明该实现接受了这份输入；画面出现，只能证明它产生了某种输出。这些凭证都不能单独证明处理器采用了制作者所依赖的同一版 PFR 规则、保存了全部字符映射与度量，或者让读者看到了作者预期的字形。

RFC 3073 的安全说明也必须放回其有限范围内理解。文档称当时定义的字段都是描述性的，不会诱使接收端执行特定行为；同时承认 PFR 可扩展，未来若出现能够诱发动作的字段，便可能带来新的风险，并称这种处理指令不受所引用规范支持，也背离格式目标。这说明的是格式设计边界，不是一份针对每个解析器的内存安全审计，也不是文件真实性机制，更不是对字形可信度或应用后续行为的授权。

登记模板中的 “Interoperability considerations: none” 同样不应被扩读为互操作证明。RFC 没有附带一致性测试套件、独立实现报告、样本语料库或逐像素渲染比较。它列出 Netscape Communicator、Bitstream WebFont Maker 和 Hexmac Typograph 等使用这种媒体类型的应用，但产品名称清单不能证明任意两种实现都能忠实交换每一个有效文件。史料支持的较窄结论是：登记提供了共同名称和公共元数据，而且当时据称已有若干应用和标准组织采用该格式。

后来的制度演变没有抹去这条边界。RFC 6838 把媒体类型登记更系统地表述为公共命名制度，规定不同树、公开要求、评审路径和变更控制责任。RFC 8081 又设立 font 顶级类型，并登记 font/ttf、font/otf、font/sfnt、font/woff 和 font/woff2。今天的 IANA 注册表把较早的 application/font-sfnt 与 application/font-woff 标为弃用并指向相应的 font/* 名称，却仍列出以 RFC 3073 为依据的 application/font-tdpfr，没有同样的弃用注记。这只能说明当前台账怎样记录该名称，不能证明 PFR 已迁移、仍在部署、已退出使用或在现实中互操作。

RFC 2045 有助于还原当年的操作逻辑。MIME 需要一种共同语法，为接收方可能理解、也可能不理解的消息体标注类型和传输方式。标签减少了内容自我声明时的歧义，却不会凭空创造通用解码能力。RFC 2048 的登记程序则试图让新名称可审查、可记录。如此看来，RFC 3073 确实改进了协调；但把名称纳入公共登记，不等于公共机构已经接管底层规范及其实现链。

从后来提出的 Running-Code Primacy 视角看，真正需要验证的是一条连续链：登记名称仍然存在；正确版本的规范可以取得；解码器被维护并实际安装；处理器映射指向该实现；具体输入能够解析；所得画面符合预期。Reality Layers 又提醒我们，公共名称带来的象征权威，不应代替产生实际效果的执行依据。两者只是后来的分析工具，不能倒过来归因于 Collins、Bitstream、IANA 或 IETF。

因此，问题不在于厂商维护的格式能否借助公共注册表协调。现实中往往必须这样做。现有记录也不支持把 PFR 规范说成秘密或不可得：RFC 明确称其可以索取，并提供了网址。更准确的历史教训是，公开发现一个名称、取得一份登记记录、掌握完整格式、运行兼容代码和观察到正确呈现，是五个不同条件。任何一个条件继续存在，都不会自动保存其余条件。

RFC 3073 让发送者与接收者能够长期引用同一种声称的内容类型，这是实实在在的基础设施。它的限度也同样真实：登记册可以告诉我们胶囊叫什么、文档当时被说成存放在哪里；只有规范、实现和经过观察的输出，才能说明某个接收方究竟能对其中的字节做什么。

来源