摘要

  • RFC 2223 把可搜索的 ASCII 定为主版本，PostScript 只是需要编辑部核验的附加呈现。
  • 它先发布一份共同文本，再允许更适合图表和纸面阅读的文件进入档案。

如果两份文件都标着同一个 RFC 编号，读者要先知道该引用哪一份。1997 年，RFC 2223 给出了明确排序：ASCII 文本是主版本；PostScript 可以作为次级或替代呈现，但 RFC Editor 必须先判断它与已经发布的文本是否“相同”。排版更精致，本身不等于拥有更高权威。

Jon Postel 和 Joyce Reynolds 编写这份作者指南时，RFC 已经以公共在线文件的形式流通。读者会把文件复制下来，在屏幕上查看，也会用自己的设备打印。设备和阅读习惯都不统一。一张图在纸上能看清，未必能用一行 ASCII 说清；一份纯文本容易检索和转发，却可能把图表压成难读的字符。

RFC 2223 没把这种冲突说成审美之争。它记录了读者的实际工作：有人用 emacs 或 grep 搜索词句，再把短段落贴进电子邮件。PostScript 不适合这些用途。生成工具也并不总可靠；指南指出，一些声称能输出 PostScript 的系统实际生成了非标准文件。另一方面，PostScript 可以更清楚地呈现图形和图表，纸面效果也更好。两种格式各自解决问题，也各自带来风险。

编辑流程把两者的地位写进了发布顺序。RFC Editor 先处理 ASCII 稿件，直到 RFC 正式发布。到了这一步，作者才可以提交 PostScript 版本。它只有在编辑部认可其内容与 ASCII 主文本相同时，才能进入 RFC 仓库并向社区公告。附加文件可以不交；一旦要公开发布，就必须通过这一关。

这项权力对应一项具体责任。作者要提交可编辑的原稿。RFC Editor 可以重新排版、加入最终 RFC 编号、要求修改，或把稿件退回作者继续处理。若作者再交一份 PostScript，编辑部还要判断它是否仍然代表同一份公共文件。文件扩展名不能替内容作证。

RFC 2223 还把格式要求写得很具体。它规定页面尺寸、边距、字号，并把可用字体限制在常见范围；图表应使用普通打印机较容易处理的 PostScript 子集。更换排版方式后，页数和章节所在的页码可能变化。因此，指南更倾向于用章节编号交叉引用，而不是写“见第几页”。章节编号属于文本结构，页码则会跟着版面走。

纯文本规则并非 1997 年才出现。1989 年的 RFC 1111 已经列出 ASCII 与 PostScript 两种提交格式，并要求 ASCII 每页不超过 58 行、每行不超过 72 个字符。RFC 2223 延续这套机械约束，同时把“主文件”和“更好看的附加版本”之间的关系讲得更清楚。

2014 年，RFC 7322 取代了 RFC 2223。后来的风格指南把系列基本格式惯例追溯到 1970 年代和首任 RFC Editor Jon Postel。屏幕、打印机和制版工具会变，档案仍需说清哪份文件是依据。现存 RFC 说明了核验机制，却没有记录 PostScript 版本争议的数量或使用比例。

官方来源