摘要

  • RFC 8334 区分“启动期注册”和“启动期申请”。在申请模型下，服务器可以为同一域名接受多份申请；一次有效创建会返回 EPP 结果码1001、applicationID 与 pendingCreate，但域名尚未分配。
  • 这份成功回执只证明命令被接受、申请对象已建立。它不证明商标优先权、最终分配、注册局公开记录、DNS 委派或服务可达。
  • 可审计证据必须连接客户端与服务器事务标识、阶段和政策版本、按顺序保存的状态与 poll 消息、最终 domain:panData，随后再分别读取域名对象、注册局公开面、权威 DNS 和服务状态。

技术系统最容易误用的词往往不是术语，而是“成功”。它让运营面板变绿，让下游任务启动，也让人误以为一件业务事实已经成立。

RFC 8334 的示例响应恰好同时给出两层时间：Command completed successfully; action pending。结果码是1001，响应里还有启动阶段与 applicationID。成功完成的是命令；仍待处理的是决定申请命运的行动。

这份《EPP 启动阶段映射》于2018年3月成为 IETF 标准轨 RFC，由 J. Gould、W. Tan 与 G. Brown 共同署名。IANA 的 EPP 扩展注册表以 RFC 8334 作为该扩展的参考。本文选择 Gavin Brown，是因为这项集体标准工作提供了一个极其清楚的证据边界；它不把 Brown 写成唯一作者、注册局、验证者或分配决策者。

2026年8月31日保存的 IETF 档案称，Brown 在 DNS 与域名行业有25年经验，曾在 Team Internet PLC（原 CentralNic）工作22年，其中14年任首席技术官，现就职于 ICANN。档案列出四份 RFC，包括 RFC 8334；当时公开角色还包括 RESTful Provisioning Protocol 主席与 ARTART 审稿人。这些带日期的事实说明专业背景，不产生对任何注册局政策的个人控制权。

“创建”到底创建了什么

RFC 8334 先把两类对象分开。启动期注册用于先到先得模型中的单一域名注册；启动期申请则表达注册意图。采用申请模型的服务器可以为同一个域名收下多份申请，以后再选出一份分配为注册。

“可以有多份”不是所有启动期的通则。服务器可以不支持这一模型，阶段也可以采用不同规则。标准负责让双方说清使用哪种形式，注册局的带外政策负责选择、验证与分配。

当启动期申请创建有效时，服务器必须建立申请对象、分配申请标识、设置 RFC 5731 的 pendingCreate，并返回 applicationID。即使几份申请指向同一域名，后续操作也能凭这个标识找到具体的一份。

这当然是有效结果。申请已经进入服务器状态，不能因为尚未分配就称它失败。但新对象是申请，不是稳态域名注册；标识属于申请，不是域名权利凭证；pendingCreate 也明确保留了行动尚未闭合的事实。

如果数据表只写 domain_create_success=true，关键名词就丢失了。客户通知可能把“申请已受理”写成“域名已创建”；财务开始确认收入；DNS 团队寻找本不可能存在的委派；安全系统把尚未分配的名字加入允许清单。正确做法不是弱化成功，而是在每个事件里写明对象：申请受理、申请验证、申请分配、域名对象建立、委派发布、服务上线。

1001 精确证明什么

RFC 5730 是 EPP 核心规范。结果码1001表示命令完成成功，但所请求的行动仍待处理。服务器响应可以带回客户端提供的事务标识，并必须提供服务器事务标识，从而把双方日志连接起来。

因此，一份完整申请回执至少应保存：客户端和服务器事务标识、服务器时间、发起客户、域名、服务器端点、阶段、子阶段、创建形式、结果码、applicationID、RFC 5731 对象状态和启动期状态。

它支持的陈述很窄：某服务器在某一政策与协议上下文中，于某时接受并记录了这项申请操作。

它不支持以下推断：申请人已经取得商标或法律优先权；验证已经完成；注册局已经在竞争申请中选中它；稳态域名对象已经存在；RDAP 已经公开；父区已经加入委派；该域名下的服务已经可达。

这些动词分别属于不同主体。注册商客户端负责提交，验证者评估适用材料，注册局执行启动政策，公开投影系统发布资料，区域运营者写入委派，权威服务器回答，服务运营者配置应用。第一个主体的成功动作不能自动继承后面主体的权限。

阶段名称不是政策全文

RFC 8334 定义 sunrise、landrush、claims、open 和 custom 等阶段。客户端必须指明目标阶段；服务器应验证阶段，也可以验证子阶段。阶段可以重叠，名称属性还能表达子阶段或自定义阶段。

这些字段是必要的关联键，却不包含全部业务规则。两家注册局都使用 sunrise，仍可能采用不同时间窗口、验证服务、费用、申请资格、竞争处理和分配时点。标准有意让一部分政策留在协议之外。

所以，事务证据必须同时冻结政策版本、生效时间与适用形式。只有“sunrise”这个词，无法回答是否必须使用某类商标材料、能否提交多份申请、哪些状态可跳过，或最终分配按什么规则进行。

RFC 7848 定义相关机制使用的商标与签名商标对象。RFC 8334 会依阶段和形式携带商标、签名对象、验证码或通知信息。它们是来源证据，不是自动分配权。有效的签名商标可以满足某项验证条件，通知确认可以证明流程发生，验证者标识可以说明上下文；最终解释和选择仍由注册局政策负责。

反过来也不能看到字段缺失就判错。审计者必须先证明当时的阶段、子阶段、命令形式与政策确实要求该材料。最小共同规范负责互操作，本地政策负责可追责的选择；两者都要留证，不能相互冒充。

pendingCreate 是历史，不是一个标签

启动期状态包括 pendingValidation、validated、invalid、pendingAllocation、allocated、rejected 和 custom。只要使用启动期状态且尚未进入最终的分配或拒绝，对象就保持 pendingCreate。RFC 允许依政策跳过中间状态。

因此，只保存最后一格状态会毁掉流程证据。系统需要知道哪项判断发生过、哪项按政策跳过、何时转移、哪条消息送达发起客户，以及每一步由谁负责。

RFC 5730 的 poll 队列承载异步变化。消息有自己的 ID，客户端请求后还要确认。RFC 8334 建议用它报告中间状态；对于最终 allocated 或 rejected，服务器必须放入 RFC 5731 的 domain:panData 待处理行动消息。

可审计记录应按顺序保存消息 ID、入队、收取、确认、状态、applicationID 与相关事务。allocated 证明这份申请被选中，可进一步形成 RFC 5731 域名对象；rejected 证明它没有成为该注册。超时、沉默或一次公开搜索无结果，都不能代替最终消息。

保密规则让这条边界更加重要。申请是否存在、申请内容本身，都可能是机密。未授权操作必须返回2201，服务器也可以按政策向部分客户提供过滤结果。公开看不到，只能证明公开观察面没有显示；它不一定证明申请不存在。

分配之后还有四层事实

即使最终 panData 是 allocated，也不能立刻说“域名已经在互联网上运行”。首先要读取由分配产生的 RFC 5731 域名对象。随后分别检查注册局或 RDAP 的公开投影、父区委派、权威 DNS 回答，以及实际服务的可达与控制。

每个落差指向不同责任人。已分配却没有域名对象，问题在注册局 provisioning；有对象却无委派，检查区域发布或注册人配置；有委派却无权威回答，检查 DNS 托管；DNS 正常但服务失败，检查应用、证书、网络或主机。

运行代码优先并不是只相信最后一跳，而是只让每个系统证明它实际观察到的事实。EPP 证明 EPP 状态，注册局读回证明域名对象，RDAP 证明它在某时公开的投影，DNS 证明某观察点收到的答案，连接尝试证明服务观察。完整性来自保留连接，而不是让第一张回执替整个系统说话。

一条不能压扁的证据链

任何重要判断至少应能重建：

  1. 客户端与服务器事务标识、创建时间、发起客户、域名、端点和结果；
  2. 阶段、子阶段、命令形式、政策版本、生效期和分配程序；
  3. applicationID、初始 pendingCreate、启动状态与获准查看者；
  4. 只在政策适用时记录验证者、商标、签名对象、代码和通知来源；
  5. 按顺序记录状态、poll 消息、接收与确认、跳过原因和例外；
  6. 最终 allocated 或 rejected 的 domain:panData；
  7. 分配后产生的 RFC 5731 域名对象；
  8. 注册局/RDAP、父区、权威 DNS 与服务的独立、带时点观察；
  9. 保密依据、过滤规则、授权读者、保存期限与审计负责人。

这不是给成功增加手续，而是把成功限定在它真实发生的层面。申请人能证明服务器受理，注册局能证明受理不是分配，验证者能说明自己评估了什么，运营团队能定位等待在哪一层，同时不用为了证明流程存在而公开机密申请。

RFC 8334 最值得保留的设计，是让“尚未完成”拥有身份、历史和闭合点。applicationID 给等待命名，状态与 poll 保存过程，panData 记录结局。治理的第一步，就是不再用一个绿色的“成功”把这三件事删掉。

来源