摘要

  • RFC 1357 为技术报告的电子邮件书目通知规定了可供人阅读、机器解析的字段格式；它规定如何发送记录，把收到后的处理留给接收方。
  • 修订必须寄出完整的新记录，撤回属于修订的一种。版本、发布者范围内的 ID、建档日期和结束标记仍要保留，标题则可以删去或留空。

纸质邮件把大学的新技术报告送进别人的信箱，速度慢，收件人还得手工归档，才能在以后找回。Danny Cohen 编辑的 RFC 1357 于 1992 年 7 月提出：把书目记录写成普通文本，用电子邮件发送。它要加速的是通知和检索的入口，不是替各家图书馆经营同一套目录。

这份格式最有意思的地方，恰好发生在第一封邮件之后。发布机构发现取得报告的地址写错了，可以再发修订；报告不再作为有效告示，也可以发撤回。问题是旧记录早已被不同机构各自抄进目录。发布者能把新声明送达，不能隔着网络替每个收件人抽走旧卡片。

RFC 给记录安排了一根不容易断的骨架。BIB-VERSION 必须第一，ID 第二，ENTRY 第三，END 最后。字段名后接两个冒号。ID 由受控的发布机构代号、两个斜线和该机构自己的报告号组成。标题、作者、取件方式、摘要等反而是可选字段。接收方据此能把后来的消息对准同一条报告记录，而不是只凭一个可能被改过的标题猜测。

修订不是“把第三行改一下”的补丁。REVISION 带整数编号和说明，较大的编号代表较后的版本；新邮件必须包含完整替换记录。如果某个目录漏收了第一封邮件，它仍能读懂第二封记录的全部字段。如果只寄差异，接收方还得赌自己手里的旧版本正好与发布者预想的一样。

撤回沿用这条路。RFC 的示例保留必要的版本、ID、日期和结束字段，加上较高修订号，在 NOTES 说明撤回，并允许省略或清空 TITLE。示例里出现的人名和地址只是格式演示，不是一桩真实撤回。技术上的赌注是：收件箱里出现“撤回”，与公共检索结果不再显示旧标题之间，还隔着本地处理、排序和更新。

格式还特意挡住测试材料。以 X 开头的版本号被视为实验；发布者代号 DUMMY、TEST 或以 X 开头时，收件人不应把记录纳入永久数据库。这些标记让导入程序能辨认测试记录，不能代替接收机构自己的采纳决定。邮件宣称的类别，与目录实际收录的状态，是两份证据。

整套语法朴素得近乎吝啬：只用可打印 ASCII，行长限 79 个字符，字段可重复，续行不另加标记，遇到下一个“双冒号”字段才结束。人可以用文本编辑器填写，机器也能拆出作者、日期和取得方式。RETRIEVAL 可以指向 FTP，也可以说明邮寄办法。读者找到一条书目，并不等于已经拿到了报告全文。

1995 年的 RFC 1807 修订了格式，补入 HANDLE、OTHER_ACCESS、KEYWORD、WITHDRAW 等字段，并记载 Cornell Dienst 与 Stanford SIFT 使用它。后来的系统把这套记录带进了服务；1992 年的原文已经把边界说清：它规定记录怎样传，接收后怎样处理由接收方决定。

撤回邮件可以很快。改掉旧目录，需要握有那本目录的人真正执行。

来源：RFC 1357 原文；RFC 1807 原文；RFC Editor 的 RFC 1357 记录。