摘要

  • RFC 3017 把漫游电话簿做成可供软件选择接入点、设置拨号脚本、DNS、代理、网关与用户名的 XML 配置包，但明确不规定电话簿的更新或传送协议。
  • 书级与 POP 级递增计数只能在已知发布者、书名和版本分支内提示变化；它们不能证明数据由谁签发、客户端已经提交新状态，或名单里的接入服务仍可用。

旅客的电脑里留下两本电话簿。一本写着版本 41，另一本写着版本 73。若只看数字，选择似乎毫无悬念。

可这两个数字未必属于同一条版本线。漫游联盟可以为不同用户群发放不同版本；用户还可以从收到的全集里抽取某个国家、某种接入介质的子集。phoneBook 的 name 只是任意字符串，并没有自动携带全球唯一的发布者身份。73 大于 41，却不因此证明它适用于眼前这位旅客、这次行程和这台机器当前安装的基线。

这正是 2000 年 12 月 RFC 3017 留下的证据边界。它的题名是 XML DTD for Roaming Access Phone Book，但“电话簿”并不只是号码清单。条目可以告诉程序怎样选择网络接入点，支持哪种介质与隧道，最低和最高速率是多少，还能携带拨号脚本、价格说明、DNS 与邮件服务器、Web/FTP 代理、默认网关、客服入口，以及拼接到用户名之前或之后的字符串。

它描述网络，也能改变主机如何进入网络。

联盟汇编的是一个视图，不是唯一现实

RFC 3017 描绘的信息链从接入服务商开始。联盟成员把各自的接入点与服务资料交给漫游联盟，联盟再汇编成面向客户的统一电话簿。规范预期不同人群收到定制版本，也允许用户自己生成更小的子集。

这种设计便于携带和筛选，却让每条记录拥有一段来源链：运营商作出声明，联盟进行汇编，某类用户拿到一个裁剪版，本地程序又保存或抽取其中一部分。每一步都可能继续通过 XML 校验，同时改变记录是否完整、引用怎样连接、下一次增量更新应以什么为基线。

RFC 2194 提供了更早的实际背景。它审视的一个漫游系统由成员向秘书处提交服务商和 POP 资料，秘书处手工汇总号码，再通过 FTP、Web 和客户端更新。资料不只有电话号码，还可包括地点、代理、拨号器配置、客服与服务器设置。这个例子不能证明 RFC 3017 被该系统采用，却说明统一格式为何重要：多家机构已经在把分散声明汇编成旅客会执行的配置。

DTD 给了这些参与者共同语法。它没有把各自的视图变成同一个事实。

只有先确定作用域，版本号才有意义

顶层 phoneBook@version 是一个应在电话簿改变时递增的整数。服务器可以拿客户端报来的数字同当前数字比较，判断是否需要动作。RFC 举的例子是：若不同，服务器可以返回一个包含差异文件的 URL。

但 RFC 没有定义这个差异文件，也没有定义请求消息、传输方式、认证交换、原子提交、失败回滚或恢复步骤。引言反而明确说，这份文档不打算规定任何电话簿更新或传送协议。

所以计数器只能支持有限判断：服务器认为某个已知电话簿与客户端版本不同。单独一个整数无法回答：

  • 计数空间属于哪个发布者？
  • 当前文件是全集、用户群版本，还是本地抽取的子集？
  • 差异文件以哪个基线为前提？
  • 每个字节是否到达并通过完整性检查？
  • 新书是在校验成功后一次性替换，还是同旧书混合了一半？
  • 客户端真正启用了哪一组 DNS、代理与拨号规则？
  • 这次加一是纠正了失效号码，还是只换了一枚服务商品牌图标？

更大的整数不是时钟，不是签名，也不是提交回执。

RFC 2477 把这条分界写得很清楚。它对电话簿更新协议提出的要求包括：客户端能认证发送更新的服务器；能从任意旧版本更新到最新版本；在应用更新之前检查收到内容的完整性；更新后再次检查成品电话簿；传输要轻量；还能请求特定语言与字符集。之所以需要这些要求，正是因为格式中的版本字段无法替它们完成工作。

条目计数器周围仍缺少完整合并语义

每个 pop 有一个同样应递增的 entryVersion，RFC 说它可用于合并与更新。但 POP 本身没有 XML ID。setup、support 和 provider 容器有 ID，也能在同一文档中被引用；接入点则主要由地址、介质和其他内容描述。

如果电话号码改变，更新程序仍需要知道这是同一个 POP 改号、旧 POP 被替换，还是新增了第二个 POP。如果一条记录消失，它可能表示正式删除、此用户群的版本不含该条目、传输只带了部分数据，或汇编过程漏掉了它。RFC 3017 没有定义 tombstone、冲突处置或合并事务，也从未声称定义过。

entryVersion 是可供更新协议使用的线索，不是更新协议本身。

扩展机制也要用同样尺度理解。RFC 把可扩展的参数实体声明与固定结构分开，并为新属性值和新信息元素安排注册策略。新增信息元素必须保持可选，以免旧文档因新规范而失效。旧文档仍然有效，不等于旧客户端会理解新文档里的每个扩展。真实兼容性还要看解析器版本、支持的扩展集合，以及遇到未知但影响选择的值时采取什么策略。

结构合法并不证明字段背后的网络存在

当时的 XML DTD 没有对运行数据做强类型验证。大量字段仍是 #PCDATA。RFC 为 FQDN、IP 地址与编码图片引入 notation，表达预期值类型；但 notation 不会查询 DNS，不会拨打一只号码，不会验证价格，也不会确认默认网关可达。

一份文件可以完全 well-formed，并且指向已经退役的号码。它可以通过 DTD 校验，而代理服务器拒绝连接。它可以列出本地软件不支持的隧道类型。最高速率是服务能力声明，不是这一次通话的实测速率。价格字段存在，也不表示费率仍然有效。

风险来自客户端可能自动执行这些字段。dialScript 装着接入 POP 时使用的脚本；setup 可以给出 DNS、邮件、代理和网关；智能拨号器还能自动把前缀、后缀接到基础用户名上。过时条目不是单纯展示错误，它可能改变拨打目标、认证身份与应用流量的去向。

“电话簿”听起来像描述性文件，实际却拥有配置权。

签名保护一项声明，不保护它持续为真

RFC 3017 的安全部分要求可靠认证信息发布者，并在分发时保护完整性。DTD 本身不承载这些功能；文档把 PGP 签名列作外部手段的例子。

这种分层是正确的。XML 结构校验和发布者认证本来就是两种测试。但通过两种测试也不能推出第三种、第四种结论。

外部签名可以证明：在相应密钥与信任规则下，被验证的字节由某个签名者认证。它不会逐个拨打号码，不会确认签名后某个 POP 是否被撤销，不会判断这份版本是不是发给当前用户群，也不会证明客户端用正确基线完成合并。

更新服务器认证成功，更不等于后续接入会成功。RFC 2486 把 Network Access Identifier 放在 PPP 认证阶段，并利用类似 realm 的部分帮助路由认证请求。那是在选定接入点并拨通之后发生的。号码正确可能仍遭 NAS 拒绝；物理链路建立可能仍过不了认证；认证通过后也可能拿到不可用的地址、DNS、代理或隧道状态。

每一阶段都需要自己的回执，不能借用上一阶段的成功。

同一配置还可能有多个来源

RFC 3017 说 Setup 描述会随服务商或 POP 改变的服务参数，其中一些也许能通过 DHCP 等其他机制取得，另一些不能。

于是运行中的客户端必须回答一个 DTD 无法回答的问题：电话簿给出一台 DNS，DHCP 给出另一台时，谁优先？答案可能取决于客户端、接入方式、安全策略与当时网络。序列化格式只表达一份候选配置，主机最终使用什么，要到运行状态里观察。

这不是 RFC 3017 的缺陷。它说明配置权威不可能只由文档语法决定。

一张只写“已经安装版本 73”的故障单没有足够证据。调查者需要保存发布者、书名、受众版本、整本摘要、书级版本、所选 POP 与条目版本、签名结果、解析器与扩展集合、下载基线、提交结果和当前生效配置摘要；随后还要分别记录拨号、链路、PPP、认证、地址分配、隧道、DNS、代理与应用可达性。

这样才分得清过时记录、错误合并、拨号失败、身份拒绝和服务故障。

这段历史的价值在于有限标准化

RFC 3017 没有假装一个 DTD 能运营整套漫游系统。它统一了最需要共同形状的部分，也明确说更新与传送在范围之外。用今天的完整软件更新体系去责备它“不够多”，反而会错过这份设计的节制。

真正的错误会发生在实施或审计中：把一件有限的协调物当成普遍证明。

Lu Heng 的 Running-Code Primacy 提供了一个分析角度：发布的配置必须同运行网络相遇，才能成为运行事实。Reality Layers 要求把文档合法、发布者认证、客户端安装和服务成功分开。Minimum Initial Specification 则解释了为什么共同格式可以保持轻薄，同时也提醒转移规则、兼容标签、本地验证与真实采用必须在其他位置明确存在。

这些只是分析框架，不是对 RFC 作者动机或立场的归属。

旅客确实需要电话簿。没有可携带、可自动处理的名单，多服务商漫游只能靠手工和猜测。但书顶上的版本号从来承担不了全部“新鲜度”。

它只能说明记录发生过变化。网络是否仍在那里，必须由网络回答。

信息源