摘要

  • 1992 年 7 月的 RFC 1357 为计算机科学技术报告设计电子邮件书目格式。格式版本、出版机构及报告编号、记录建立日期、与编号相同的结束标记是四个必填字段；标题、作者、摘要和索取说明均可选。
  • 纠错与撤回通过同一编号下较高版本号的完整记录完成。索取说明可以是匿名 FTP、邮寄或付款办法；文件自动获取的机器可读指令当时尚未定义。

先寄通知，报告随后再说

RFC 1357 开篇描写的工作方式很老派：研究机构把新技术报告的书目信息印出来，交给邮政系统寄往各处。邮资和路程耗费时间，收件人还要把纸面资料重新整理，才能在电脑里检索。Danny Cohen 编辑的提案把这张通知改成纯文本电子邮件。写的人可以用普通文本编辑器，收的人可以自己决定是阅读、存档，还是交给程序处理。

格式要求很少，但位置严密。第一项 BIB-VERSION 声明书目格式版本，第二项 ID 写出版机构符号、双斜线和机构自己给报告的编号，第三项 ENTRY 记这条书目记录的建立日期，最后由 END 再写一次相同编号。四项构成一条消息的骨架。标题、作者、发表日期、页数、摘要、全文索取方式都属于可选内容。

读者会觉得次序古怪：找文章的人先问标题，制定格式的人却先问编号。关键在于谁负责纠错。机构决定什么算一份出版物，为它分配报告号，然后把这个号发给各地目录。标题可以补写、改写或清空；编号使收件方知道后来的消息要替换哪一条。形式上有效的记录仍可能很难让人判断内容，这正是行政可识别性与阅读便利性之间的差价。

撤回时，编号反而更重要

RFC 1357 要求修订版带上完整记录，而不是只列“第七行改成什么”。修订号升高，收件方就可以用新版本整体替换旧版本。示例里的撤回也是一次修订：同一个 ID，新 ENTRY 日期，更高的修订号，标题留空，旧的索取说明消失。编号仍在，目录才知道被撤回的是哪份报告。标准示例记录大约 1750 个字符，重复发送整条记录的代价，换来较简单的版本判断。

这个小格式还给机器处理划了边界。每行最多 79 个字符，只用可打印 ASCII。多个作者字段可以重复，原来的顺序保留。实验性格式版本和测试用机构符号，不应进入收件人的永久数据库。这些不是一座中央图书馆的命令，而是每个收件目录在接纳消息前可检查的条件。

机构符号本身也有管理问题。两家实验室若选了同一个符号，双斜线后各自的报告号就可能撞名。Cohen 提议由自己通过电子邮件协调出版者符号及机构名称。文中提到与 IANA 登记相关的讨论，讨论仍在进行。编号权来自出版机构，跨机构的唯一性则需要有人维护。

书目记录会跑，书未必跑

最能说明分工的是 RETRIEVAL 字段。它允许自由文本；示例同时写了两条索取路线：寄一个贴好邮票的回邮信封，换取带彩色图片的全文，或者用匿名 FTP 下载 ASCII 版本。格式还允许写价钱或“给某人发邮件”。RFC 明说，供软件自动取回文件的信息规范仍待制定。收到记录的人可能立刻看见标题和摘要，却仍要人工解释一句取件说明。

书目记录的传播与报告的权利安排也分开。提案允许记录自由传播；若报告本身有限制，应由另一个保护办法处理。收件箱里出现一条记录，只能证明通知到达那里。拿到正确文件，还取决于服务器、邮寄地址、权限和保存者的实际服务。

这段历史的笑点很准：互联网能让一份没有标题的报告先拥有完整编号，并把它的撤回通知送遍邮件系统；真正的报告可能还躺在办公室，等有人寄来邮票。网络改变了书目传播的速度，目录管理员和读者则继承了核对版本、维护路径、取得全文的工作。

来源