摘要

  • RFC 2056 的两个方案首先区分用户要进入可继续交互的检索会话，还是请求一条由服务器标识的特定数据库记录；这种意图区分发生在不透明 URL 部分被解释之前。
  • z39.50s 与 z39.50r 对会话寿命、数据库要求、查询构造和记录交付有不同约束；字段集合与记录语法又分别控制“取哪些逻辑元素”和“以何种外部表示包装”。
  • RFC、RFC Editor、Datatracker 与 IANA 的公开元数据能够说明规范和登记的文献状态，却不能证明今天仍有实际流量、服务支持、对象未被替换、授权持续有效或最终用户获得了预期结果。

两个方案，先区分意图

RFC 2056 于 1996 年 11 月发布在 Standards Track，状态为 Proposed Standard。当前公开查阅到的 RFC Editor 元数据把它列在 Legacy 流中；所查元数据没有给出明确的更新或废止关系。这里的“当前”只指文献目录今天如何呈现这份 RFC，不能据此推断任何 z39.50 URL 的现实部署规模、服务器支持程度或实际使用状况。

它面对的基础协议 Z39.50 本来就是有会话状态、可分多步推进的检索机制。一次一般询问可能建立会话、执行 Search，再依据结果执行 Present；服务器也可能要求进一步参数，而用户是否参与这些步骤取决于客户端界面。Search 的结果并不是把全部记录立即搬到客户端，而是在服务器一侧形成指向数据库记录的结果集。

RFC 2056 因而定义了两个不同方案，让接口在解释 URL 的不透明部分之前就知道请求的大致意图。z39.50s 面向会话式访问：主机必需，端口可省略并默认使用 210，其余部分都可选。客户端应开始一个会话，或者复用通往同一主机和端口的既有会话。若 URL 带有 docid，数据库名也必须存在，并以检索形式执行 Search；若没有 docid，其他参数对客户端可能是要求、偏好，也可能只是可忽略的提示。无论如何，这一路径要求把会话保持开放，以便用户继续操作。

z39.50r 则把目标收窄到服务器定义的一条记录。主机和数据库均必需，端口仍默认 210；没有 docid 时，其含义未定义。这个不透明的服务器标识必须作为单一检索词放进 Type-1 一般格式查询，属性集采用 Bib-1，其中 Use=docid、Structure=URx，对应通用格式的 tag 45。Search 返回的命中数 MUST 等于 1；否则该操作不成功，而应用随后如何处理并未定义。唯一记录可以随 Search Response 返回；若没有随响应交付，则再用 Present 取得。记录收到之后，客户端可以关闭会话，也可以保留它。

这一约束没有授权模糊匹配，也没有授权客户端在多个候选结果中任意挑一条。“唯一命中”是操作成功的条件，而不是一个可由界面自行放宽的建议。

从数据库内部记录到交付表示

RFC 2056 还隐含着一个容易被 URL 外观遮蔽的分层：数据库中的本地记录、参与者共同理解的抽象数据库记录，以及最终导出的检索记录，并不是同一个对象。elementset 决定希望取得哪些逻辑元素，recordsyntax 决定这些元素以什么记录语法封装并传输。因此，“字段选了什么”和“外部表示是什么”是两项不同观察。

esn 未给出时，由客户端自行选择；若给出，则可在 Search 的 small-set-element-set-names 或 medium-set-element-set-names 中使用，也可以在随后 Present 时使用。rs 未给出时同样由客户端选择；若提供一组记录语法，客户端最好从中选取首个自己支持的值，作为 PreferredRecordSyntax。

语法本身也保留了这种层次。数据库名以 + 分隔，之后可以有可选的 ?docid、;esn=，以及一个 ;rs= 参数；当 rs 中存在多个记录语法值时，值之间再以 + 分隔，而不是重复书写多个 ;rs=。其共同 URL 语法基础来自 RFC 1738。

这一区分与 RFC 1729 所讨论的表示互操作问题形成历史上的呼应：网络两端即使谈论“同一资源”，数据模型、表示和转换仍可能造成差异。RFC 2056 并没有因此把一个 URL 提升为对象身份的终极证明；它规定的是如何构造一次特定的协议动作。

一条定位符能证明到哪里

从这些机制可以得到一条重要但有限的解释：方案名、主机与端口、数据库名、不透明标识、查询构造、唯一命中数、元素集合、记录语法和最终交付，都是彼此可分开的观察。知道其中一项，不自动证明其余各项。

因此，一个语法正确的 z39.50r URL 可以表明调用者打算按规定构造唯一记录检索，却不能单凭字符串证明服务器今天仍把 docid 指向当年的同一对象；一次命中数为 1 的 Search 可以满足该次协议条件，却不能证明对象从未被替换、书目描述绝对正确或记录内容完整；成功取得某种记录语法，也不能反向证明用户界面正确解析了全部字段。类似地，复用同一主机和端口的会话机制说明协议允许连续交互，却不能单独证明中间所有应用状态都连续，更不能证明用户最后完成了预期任务。

这不是 RFC 作者意图的延伸声明，而是把规范中分别出现的动作和条件按证据能力重新排列后的解释。Heng 关于“最低共同规范、未来决策本地化与自愿采用”、现实层次以及运行代码优先性的文章，可用于帮助理解这种分层：共同规则只约束共同部分，之后的选择仍可能留给本地实现；规范文字、软件行为和现实结果属于不同层面。但这些文章只能支撑这种解释框架，不能倒推为 RFC 2056 作者当年的主观意图。

安全边界与相邻历史

RFC 2056 的安全警告尤其能说明“定位”与“安全结果”之间的距离。一个定位符后来可能不再指向原本预期的项目；而外观看似无害、可重复执行的检索，也可能在远端触发具有破坏性的操作。换言之，字符串稳定并不等于对象稳定，读操作的表面形态也不自动等于无副作用。

与它相邻的 RFC 1625 则提供了另一种历史路径：WAIS 语境使用 Type-3 文本查询，为了无会话状态的处理而删除结果集，并且不使用 Present。它与 RFC 2056 所描述的 Z39.50 会话式机制不能混为一谈；两者对查询、结果保存和后续取回的安排不同。

今天的 IANA URI Schemes registry 仍把 z39.50s 和 z39.50r 登记为 Permanent，并把 z39.50 登记为 Historical。这个登记事实说明名称在注册表中的分类，不说明现实网络上有多少流量，也不保证服务器仍提供支持，更不是对某项部署继续运行的背书。文献存在、名称登记、软件实现、服务可达与用户成功，是不同层次的事实。

资料来源