摘要

  • RFC 2158 通过正文类型名称、OID、MIME Content-Type 与原样传递的字节共同描述 JPEG 和 GIF，这些字段有关联，却不能互相替代。
  • FTAM EMA GIF 小节的标题、正文类型和 gif-image(4) 都指向 GIF，唯一的 MIME 行却写成 image/jpeg。
  • 上下文强烈支持“笔误”判断，但 RFC Editor 当前没有任何 RFC 2158 勘误；推测的修正也不能证明历史网关采用了哪一套解释。

四个标识里有一个走错了队列

1998 年 1 月发布的 RFC 2158 处理一件很具体的事：让最初在 MIME 中定义的 JPEG 与 GIF 图像通过 X.400 系统。它为 JPEG 定义 mime-jpeg-body，OID 分支是 { mixer-bp-data 3 }；为 GIF 定义 mime-gif-body，分支是 { mixer-bp-data 4 }。两者都以 OCTET STRING 携带正文，不带参数，内容含义交由 MIME 说明。

随后列出的前三组对应关系都很整齐：JPEG 扩展正文对应 image/jpeg；FTAM EMA JPEG 对应 image/jpeg，OID 末端为 jpeg-image(6)；GIF 扩展正文对应 image/gif。问题出现在第四组。标题是 image/gif - FTAM EMA GIF，正文类型写着 FTAM EMA GIF，OID 末端写着 gif-image(4)，但 Content-Type 行变成了 image/jpeg，下一句还把 GIF OID 称作 JPEG 的 OID。

同一条记录无法同时让这些字段都正确。它确实证明标准公开印出了 image/jpeg，却没有因此把另外三个 GIF 标识消除。

不转换字节，更不能让标签替字节作证

四条对应关系都写着 Conversion: None。网关不是把 GIF 解码后重新编码成 JPEG，而是在两种消息体系之间关联类型并复制图像字节。若类型标签选错，原样传递反而会把矛盾完整送到下一站：字节没有变，关于字节的声明却可能错了。

RFC 2046 明确说，image 的 subtype 用来命名具体图像格式。今天的 IANA 媒体类型登记表 也分别登记 image/gif 和 image/jpeg。RFC 2157 的配套汇总表同样把 mime-gif-body 对应 image/gif，把 mime-jpeg-body 对应 image/jpeg。这些材料让正确方向更清楚，但它们都不会自动改写 RFC 2158 的原文。

接收端可能按 MIME 标签选择解码器，也可能检查文件签名或尝试多个处理器。能够显示，只能说明某个处理器接受了这组字节；字节哈希一致，只能说明观察到的步骤没有改写正文。它们都不能反向证明出版条目没有问题。

“显然是笔误”仍然不是官方勘误

从标题、正文类型、OID 末端与相邻条目看，把 image/jpeg 改为 image/gif 是最有力的文本解释。早期 MIXER images 草案 也正确对应了 JPEG 与 GIF 的扩展正文，不过那份草案尚未加入 FTAM EMA 小节，不能充当争议行的正式修订稿。

截至当前，RFC Editor 对 RFC 2158 的全状态勘误查询明确返回没有匹配记录。因此可以写“很可能是复制遗留的笔误”，不能写“官方已经修正”。更不能从合理推断跳到部署结论：实现者可能照抄 MIME 行，也可能采用 OID 与标题，可能参考 RFC 2157，可能加入私有修复，或者根本没有实现这条 FTAM 映射。

规范、代码与输出各自需要回执

要证明某台网关做了什么，需要完整记录输入 MIME 类型与字节、X.400 正文类型、完整 OID、映射表版本、运行配置、输出类型与字节，以及接收端选择的解码器和结果。只保留文件名或 Content-Type，会在最需要判断时丢掉冲突的另一半。

Lu Heng 的运行代码优先提醒我们，标准文本是协调记录，执行事实仍要由代码与测试提供。最小初始规范要求把共同层保持在可验证的窄范围，不把某个实现的修补当成所有系统的既成事实。现实层级则解释了为什么纸面标签、编译后的规则和一次成功展示不能共享同一张凭证。

RFC 2158 最重要的教训并非“标准会出错”这么简单。真正的教训是：格式身份是一组需要对齐的主张。矛盾未被解释之前，任何一个字段都不应替字节、实现或结果发言。

来源