RFC 3632：同一命令为何代表两种不同权限

摘要

在 RFC 3632 中，当前赞助注册商以 -Approve:No 拒绝待处理转移，申请注册商却用完全相同的参数撤回自己的申请。认证会话、当时角色与先前状态共同决定命令含义。
200 Command completed successfully 证明 RRP 服务器成功处理命令，不证明注册人意愿、人工同意、赞助关系最终变化、DNS 发布或服务结果。
可问责记录不能只保存载荷；它要串起操作者、角色、对象、前态、规则、截止时间、响应、后态与带外通知，否则精确日志仍可能把责任归给错误机构。

日志保存了句子，却删掉了主语

RFC 3632 于 2003 年 12 月以信息类文档发布，记录 VeriSign Registry Registrar Protocol 2.0.0。它不是互联网标准，也不是今天部署 RRP 的建议。它留下的价值，是一个极其清楚的证据问题：协议字段并不总能独立表达制度动作。

-Approve:No 看似只有一个含义。可是由当前赞助注册商发送时，它拒绝另一个注册商提出的转移；由最初提出转移的注册商发送时，它取消自己的申请。前者是对他人请求行使否决，后者是撤回自身请求。字节相同，权力来源不同。

RFC Editor 记录、IETF Datatracker、文档历史与勘误检索能证明出版与维护状态，不能证明某个注册局如何部署，更不能证明某次真实转移的结果。本文讨论的是文档明确揭示的权限结构，而非虚构个案。

身份不是参数自报，而是会话输入

较早的 RFC 2832 说明，提出转移的注册商身份来自当前活跃的认证会话；注册局已经知道哪个注册商是域名当前赞助方。服务器把会话主体、对象关系与转移状态连接起来，才知道发送者可以做什么。

这比在载荷里写一个“我是赞助方”字段更重要。字段只是声明，认证会话和注册局记录才是验证声明的依据。没有授权的注册商尝试批准或拒绝转移，操作必须失败。

RFC 2832 还要求以电子邮件或报告等带外方式通知可能失去域名的注册商。这意味着制度事实从一开始就分布在多个系统：会话证明谁连接，命令记录说了什么，注册局状态记录发生了什么，通知系统证明谁被告知。

文档也承认 RRP 响应不返回时间戳或事务标识。所述日报和周报会用注册局本地时间提供时间。事后还原时，团队必须解决时区、排序与关联键问题。只有命令和 200 响应，无法可靠回答两条记录是否属于同一转移。

撤回权有一个会关闭的时间窗口

RFC 3375 先规定了制度要求：申请注册商发起转移，也只能在决定前撤回自己的申请；当前赞助注册商可以批准或拒绝；未获授权者的尝试应被拒绝；双方都要能够监测待处理与已完成状态。

RFC 3632 为撤回加入了 RRP 表达，却复用了“不批准”参数。撤回必须发生在显式决定之前，也必须早于注册局基于计时器作出的隐式批准或拒绝。状态一旦离开 pending，同一命令就不再有原来的合法迁移。

所以时间不是便于检索的附属字段，而是权限判断的组成部分。证据至少要保存服务器接收时间、时钟基准、当时生效的计时策略、关闭窗口的事件，以及处理前后的状态。客户端时间戳如果没有与服务器时钟建立关系，只能证明客户端如何标记事件。

不可逆点就在窗口关闭处。之后可以启动新的流程，却不能把旧申请重新当作尚未决定。若系统只保留最终状态，日后就分不清撤回太迟、撤回与自动决定竞争，还是赞助方先作出有效拒绝。

200 响应只对它自己的问题负责

RFC 3632 的撤回示例返回 200 Command completed successfully。这不是无意义的绿灯：它是 RRP 服务器对命令处理结果的正式陈述。问题在于管理界面常把它扩写成“转移问题已经解决”。

200 不证明注册人要求撤回，不证明注册商内部获得了客户授权，不证明赞助关系在所有系统中同步，不证明 DNS 委派改变，也不证明用户看到了任何不同。它的准确主语是：这个 RRP 服务完成了这条命令。

Lu Heng 在《On Authority and Belief》中提供了判断方式：每个可信陈述都要问发布者是谁、对象是什么、权限止于哪里。注册局可以权威陈述它如何处理注册对象，却不能替注册人证明意愿，也不能替网络观察者证明可达性。

因此审计表要把客户授权、注册商动作、注册局记录、DNS 发布和服务观察分列。它们可以相互印证，但任何一列的绿色都不能抹掉其他列的未知。

EPP 把动作写得更明白，但不会自动保存证据

后来的 RFC 5731 为域名转移定义了独立的 request、cancel、approve、reject 与 query 操作。待处理信息可以包含申请客户端、申请日期、执行客户端、执行日期和 pending 状态。RFC 5730 还提供客户端与服务器事务标识。

这种结构降低了解读歧义。导出记录不必只凭外部角色判断一个“No”究竟是拒绝还是撤回，跨系统关联也有更好的锚点。但字段存在不等于证据存在。采集器可能丢掉事务 ID，时钟可能不可靠，申请客户端仍不等于注册人，而 EPP 成功响应仍不证明 DNS 结果。

RFC 3730 可用于理解 EPP 的早期发展，却不能证明某个注册局何时迁移或是否完整实现。标准描述可用接口，部署证据必须来自运行中的系统。这正是《Running Code Primary》所要求的检验。

编码被接受，不等于名称身份被确认

RFC 3632 还加入 510 响应码，用于 ADD 或 MOD 操作中的域名编码无效。后来 RFC 5890 为国际化域名提供更完整的定义体系。

这里的边界同样明确。注册局接受一个表示形式，证明它通过当时接口的语法与政策检查；不证明商标权、组织身份、申请人意图、委派状态或视觉安全。510 拒绝也不是对名称本身的普遍判决，只是特定接口不能接受该输入。

“有效”必须带宾语：对哪套语法有效、被哪个系统接受、在何时依据哪版规则。去掉宾语，就会把技术检查升级成它没有权限作出的制度判断。

IPv6 字符串进入对象，不代表网络已经可达

RFC 3632 允许名称服务器对象保存完整或压缩形式的 IPv6 地址。RFC 4291 描述 IPv6 寻址架构，RFC 5952 后来提出规范文本表示。

语法解析成功、注册局保存成功、父区或根区发布、路由可达、权威 DNS 正常回答，是五个不同事实。第一个事实成立时，后四个都可能尚未成立。一张“IPv6 已启用”的卡片若不标明观察层，就把表示能力误写成服务事实。

完整证据要分别保存 host 对象、委派集合、区域发布、路由视图、权威回答与多地点探测。它们一致时增强信心，不一致时暴露需要调查的层间漂移。

557 锁定码划出另一层控制权

RFC 3632 的 557 表示名称服务器对象因关联顶级域而被锁定，修改需与注册局支持进行带外协调。它没有宣称永远不能改，而是说明普通注册商路径没有单方面修改这类对象的权限。

今天的 IANA 根区管理是独立的控制面。根区管理说明、顶级域管理指南、变更同意流程、名称服务器技术要求与带权限的 RZMS API把认证用户、有限权限、联系人或管理者同意、技术检查、实施与后续核验分开。一个名称服务器地址若影响多个顶级域，还可能需要其他受影响方确认。

这些当代资料不能说明历史 RRP 交易，却证明控制面为何不能互相冒名。注册局对象改变不等于根区已改变，根区请求获准也不等于服务已正常，基础技术测试更不是完整协议合规证明。

最小证据不是更大的载荷，而是可连接的关系

一条转移收据至少要连接：协议与实现版本、认证会话、注册商标识、当时角色、域名对象、申请来源与时间、处理前状态、原始命令、计时与政策版本、授权判断、完整响应、处理后状态、带外通知、后续显式或隐式决定，以及最终赞助记录。若声称 DNS 或服务结果，还要另附相应发布与观测。

这与 Heng 的《Minimum Initial Specification》相呼应：定义一个足够互操作的最小接口，不让接口吞并后续所有权限。注册局无需成为客户授权或网络服务的最终裁判，只需让自身决定可被准确连接。

《On Reality Layers》要求把符号命令、制度授权、注册记录、DNS 发布与用户现实分别标注。它们不是彼此否定，而是不能互相替代。

RFC 3632 的服务器并不因复用参数而困惑，因为它掌握会话和状态。真正的歧义由后来的导出系统制造：它把隐含输入丢掉，只保留显式字符。审计的最低要求因此不是“逐字保存”，而是保存谁有权让这些字成为某一种动作。

同一个“不批准”，为何一个是拒绝，一个是撤回

为何重要

摘要

日志保存了句子，却删掉了主语

身份不是参数自报，而是会话输入

撤回权有一个会关闭的时间窗口

200 响应只对它自己的问题负责

EPP 把动作写得更明白，但不会自动保存证据

编码被接受，不等于名称身份被确认

IPv6 字符串进入对象，不代表网络已经可达

557 锁定码划出另一层控制权

最小证据不是更大的载荷，而是可连接的关系

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报