摘要

  • RFC 1927 用电子订书钉与回形针表达多部分文档的“绑定程度”，又把外观、层级、工作流、计费、回收和文内锚点都塞进同一件办公用品。
  • 后续 MIME 规范把职责分开：Content-Disposition 只给出呈现建议，multipart/related 定义复合对象及其根，cid: 与 mid: 为内部引用补上身份和上下文。
  • 图标可以说明关系；只有接收方能够本地验证的明确语义，才有资格决定存储、执行、删除和完整性。

一件办公用品装进了八种关系

RFC 1927 的第一条设想极其直观：被电子订书钉钉住的多部分文档，应当在桌面上始终留在一起；夹着回形针的文档，则应当容易摊开。现实世界的手感替协议省下了解释。

接下来的清单却让这种省略变得危险。大、小回形针既可能代表文件大小，也可能构成层级。每枚钉子可以附带证书，用来收费和识别“私造”产品。删除文件夹时，回收程序还要寻找可再用的钉夹。color= 与 shape= 决定外观，src= 从 URL 取图，银色与金色甚至触发不同办公流程。回形针还能标记某一页、某一段或某一句，被弯成雕塑，并记录弯折次数直到疲劳失效。

这不是一种关系的不同参数，而是容器、顺序、呈现、身份、授权、会计、生命周期、定位与状态被压在一个符号上。笑话成立，是因为人在纸面上会自行补足上下文；互操作失败，也会从这里开始。复制、转发、保存、拆分或删除时，另一个程序究竟必须保住哪一层含义？

原文提醒，电子钉夹可能弄坏高速复制程序，随后又说安全问题不在讨论范围内。可一旦颜色能够选择工作流，安全边界已经出现：发送者是在装饰文件，还是在要求接收方执行命令？

“信息性文档”挡住了隐喻的越权

原始状态声明明确说，这份备忘录仅向互联网社区提供信息，并不规定任何互联网标准。RFC Editor 当前条目 将其列入 Independent Stream，并记录一条勘误。发布日期是 1996 年 4 月 1 日，再加上儿童、软盘和虚拟现实回形针雕塑，幽默性质没有疑问。

但幽默不等于没有分析价值。它把“附件”这个看似明确的词追问到底：到底是一起显示、一起保存、不能分离、保持次序、验证同一身份，还是收到后必须采取动作？界面通常把这些差别藏在一个图标下面。

已核验的勘误 把 “data flines” 改成 “data files”，又把 “very small children” 调整为 “very young children”。编辑能够判断笑话原本想写什么，却不能据此生成电子订书钉的互操作行为。修正文献与定义运行语义，证据责任并不相同。

内容参数被限制在较小的职责里

同年 11 月发布的 RFC 2046 对 Content-Type 的任务做了清楚限制：它声明 MIME 实体内容的性质。参数可以修饰子类型，却不应从根本上改变内容本性；实现还必须忽略不认识的参数。复合格式应当由 multipart 或 application 类型承载。

用这条规则审视想象中的 color=、shape= 与 src=，问题就很明显。装饰字段可以是可选的，因为不认识它仍不应破坏对象；关键依赖和执行命令却不能寄托在允许被忽略的字段上。可扩展性要求未知内容能够安全降级，正确性则要求关键语义不能随降级一起消失。

multipart/mixed 本身也只表达有序包装，其中各部分仍是独立数据。几个文件同信封抵达，只证明它们被一起运输，不能证明它们构成不可分割的对象。

呈现是一项建议，不是发送者的远程控制

RFC 2183 用 Content-Disposition 明确承载呈现信息。inline 建议立即显示，attachment 建议由用户进一步操作。文件名也只是保存时的建议基础，而非接收系统必须执行的路径指令。

它的安全章节把这条边界落到文件系统：客户端不能盲目信任路径，不能覆盖已有文件，也不能把可执行内容放进会自动运行的位置。发送者可以提出名称，本地软件必须依据自己的环境做验证。

这正是“金色回形针触发流程”的严肃版本。在一个团队内部，颜色可以很好地帮助人辨认队列；若要跨系统执行，它就必须具备经认证的命令语法、授权判断、版本规则和失败处理。颜色本身不提供其中任何一项。

真正的复合对象先要知道谁是根

RFC 2387 用 multipart/related 处理更强的关系：各部分彼此相关，分别展示不足以正确呈现整个对象。type 参数说明根部分的媒体类型，start 可以通过 Content-ID 指定根；没有 start 时，第一部分就是根。组件内部链接再表达对其他部分的依赖。

根的出现改变了问题。系统不再只问“哪些文件一起到达”，而是问“哪个组件组织这个对象，它需要哪些资源”。理解该复合类型的应用负责解释。当 multipart/related 与 Content-Disposition 同时存在时，结构处理优先，因为呈现建议在这里可能多余，甚至造成误导。

不了解 multipart/related 的客户端也有明确退路：把整体当作 multipart/mixed。它可以展示独立部分，却不会假装自己理解了一枚陌生回形针所代表的结构承诺。诚实降级比猜测绑定含义更可靠。

引用不仅要有名字，还要有上下文

在两个图标上画一条线，仍然没有说明究竟哪些字节依赖哪些字节。RFC 2392 定义 cid: 来引用 MIME 正文部分，定义 mid: 来引用消息，或引用指定消息中的某一部分。Content-ID 设计为全局唯一，但许多消息存储并不脱离消息上下文单独索引正文部分，因此较长的 mid: 形式把必要上下文带回来。

精度直接影响保存能力。指向“第三段”的页签会在编辑后漂移；外部 URL 会变化或失效。带作用域的标识至少让接收方知道目标是谁、应在哪里解析。但标识符不会自动证明内容可信，也不会赋予执行权限。可寻址性、完整性与授权必须分别核验。

完整文档必须连同依赖和证据一起搬走

RFC 2557 把这些机制用于一个实际目标：用一封消息传输完整 HTML 文档及其图片等附属资源。multipart/related 内含一个 text/html 根，再通过 Content-ID 或 Content-Location 指向同一结构里的其他部分。

规范细致区分聚合对象 URI 与根 URI。Content-Location 可以标记某个部分，却不保证所有接收者都能在网络上取回它。它还尽量避免重写既有 HTML 引用，因为改写可能使消息完整性校验失效。同处一包、能够定位与字节未变，是相互关联却不能互换的三件事。

这套方案不如屏幕上的订书钉可爱，却能被实现和审计。根、从属资源、引用方法与负责处理的应用都有明确位置；复制时要保存的是关系结构，不只是一个小图标。

最小共同层应保存语义，而不是办公室审美

Heng Lu 在 Running-Code Primacy 中把现实性放在实现、验证、部署和采用上。文档里声明一枚钉子，并不会让接收程序自动保持文件关系；只有共同运行的语义才能做到。

Minimum Initial Specification 也不是要求把规范写得含糊，而是只对必须共同的部分写得严格。对于复合文档，这可能包括根、标识符作用域、关系规则、完整性边界和未知值的安全处理。颜色、形状与本地流程应留在本地层。

现实层与符号层 的区分则说明了权力变化。图标在符号层告诉人“它们属于一起”；软件拒绝拆分、启动流程或删除资源时，已经进入执行层。把两层混在一起，就会让亲切的界面成为没有经过审查的控制面。

RFC 1927 最有价值的笑点，不是电脑缺少办公用品，而是熟悉图像仿佛能免除定义关系的工作。它不能。图标负责解释；可验证语义负责决定。

来源

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — RFC 1927 当前条目
  3. RFC Editor — RFC 1927 勘误
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — Content-Disposition
  6. RFC 2387 — MIME Multipart/Related
  7. RFC 2392 — Content-ID 与 Message-ID URL
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — On Reality Layers