摘要

  • RFC 1049 提议为结构化邮件正文加上 Content-Type：PostScript、TeX、TROFF 等文本仍按当时的 ASCII 邮件规则传送，阅读软件可根据标签调用相应处理程序。
  • 标签还可写版本与资源引用；收件端缺少程序或宏包时，寄件人需自行掌握对方的能力。RFC 2045 后来明确把 MIME 的 Content-Type 称为这项设计的扩展。

设想 1988 年的一封技术邮件：正文是一份 PostScript 文档，作者排好了公式，收件人的屏幕却直接显示绘制公式的命令。邮路完成了任务，邮件程序也照实显示每个字符，最终还得由人猜这到底是哪种文档。Martin Sirbu 在 1988 年 3 月发表的 RFC 1049，就是要让这封信自己说出答案。

当时的 RFC 822 邮件已经有明确的抬头格式，正文则主要是一串 ASCII 字符。人们开始把 TROFF、TeX、Scribe、SGML、DVI 和 PostScript 的结构化材料塞进正文。它们能以合法字符跨过邮件系统，却需要专门的处理程序才能变成作者想给人看的页面。Sirbu 提议加入 Content-Type，让阅读软件先看标签，再把正文交给合适的程序；传送邮件的路径继续搬运那些字符。

标签里装的东西比一个文件名细。第一个值说类型，例如 POSTSCRIPT 或 TROFF，也给双方私用的 X- 类型留门。第二个可注明版本，第三个可引用解释正文所需的资源，末尾还可以写注释。RFC 给出的例子尤其有生活气：PostScript 文档可能依赖某个 LaserPrep 版本；TROFF 可能要 eqn、tbl 或 me。知道菜名是一回事，厨房里有没有那口锅是另一回事。

这个资源栏暴露了早期格式交换的真成本。两端都说自己会处理同一种文档，具体字体、宏和预处理器仍可能不同。把依赖写进邮件，至少让收件软件有机会按名字寻找。要使名字有用，双方还要共享对版本和资源的理解。Sirbu 把原先靠熟人默契完成的猜测，变成可以写在信封上的操作信息。

真正麻烦的是收件人的设备清单。对方没有处理程序，ASCII 邮件照样能到，屏幕上也就铺满原始命令。格式名片能告诉机器去找 PostScript 解释器，却不能把解释器装到对方电脑里。RFC 1049 摆出了三条路：寄件系统各自维护远端能力数据库；SMTP 在传送前协商并转换；目录服务公布主机的处理能力。第一条要不停更新，第二条要动现有邮件软件且照顾不到所有跨网转发，第三条把邮件发送和目录系统一起拉进工程。每个方案都有人要付账。

Sirbu 最终给试验阶段选了一个几乎带着苦笑的办法：先统一格式标签，寄件人自己记住哪些收件人能读 PostScript。邮件正文有了标准名片，人却还得维护一份朋友设备的私家账本。RFC 还把收到合法标签后采取什么动作留给阅读软件。标签可以帮程序识别工作，安装程序、备齐资源、安排显示仍在各地解决。

几年后，RFC 2045 明确说明 MIME 的 Content-Type 是从 RFC 1049 扩展而来。MIME 加入媒体类型与子类型、参数，并配合 MIME-Version 和 Content-Transfer-Encoding 描述更丰富的正文。1996 年的文件说，旧语法较简单，与新机制大体兼容。1988 年的这一步值得单独看：先给邮件写上它需要怎样被阅读，再把“对方到底读不读得了”留给人处理。

这张小标签让邮件阅读程序不必再靠人盯着一屏命令猜谜。它也把更贵的问题推到了台前：谁有那个解释器，版本对不对，配套资源齐不齐？机器开始认识内容的名字，寄件人脑中的通讯录暂时还兼任能力数据库。