RPP 创建域名转移流程，不等于域名已转移

Summary

2026 年 11 月 2 日的 RPP 核心草案第 01 版把域名等共享数据库对象的管理操作映射到 HTTP；数据对象草案另行定义对象模型。它仍是 IETF 工作草案。
域名转移是赞助注册商的改变，但 RPP 将其建模为有独立生命周期的流程对象。新注册商用 POST /domainNames/{name}/processes/transferProcesses 发起；草案示例返回 201 Created 和指向流程的 Location。
发起方能取消待处理转移，当前注册商可拒绝或批准。持久消息队列可在异步处理结束后通知客户端；读取消息与明确确认消息是两步。

“域名转移”四个字让人想到一件从甲方交到乙方手里。IETF 的 RPP 核心记录把这段路拆开：先申请，后判断，再得知结果。开头的 HTTP 成功响应，在草案示例里创建的是流程资源。它并未逐字证明域名登记记录里的赞助方已变。一个漂亮的成功弹窗如果只看这一行，就会提前替注册局宣布结案。

RPP 是独立设计的协议，虽然运营方可以把它接到 EPP 后端。核心草案安排 URL、HTTP 方法、请求头和状态码；数据对象以及具体消息表示分别由其他文件处理。这种分工并不抽象。看一条请求日志时，运营人员必须先认清“成功”的对象：是域名本身，还是对域名发起的一项流程。

新建的是流程，不是新归属

草案第 16.9.5 节明确把转移定义为赞助客户端的改变，并给转移流程单独的生命周期。新注册商向域名下的 transferProcesses 集合发 POST。示例回复 201 Created、RPP 结果码，以及以 /transferProcesses/latest 结尾的 Location。这条路径帮客户端找到最近的流程。它不是域名最终赞助方的读取结果。

客户端可以 GET 流程状态。申请未决时，发起方可用 DELETE 取消；当前赞助注册商可以调用 transferReject 或 transferApprove。每个动词背后是不同的机构权力。想接手的一方能递交申请，不能替还握有赞助关系的一方批准。要讲清一次转移，就得把申请、流程状态、批准或拒绝以及域名最终记录串成一条证据链。

流程网址也有边界。如果服务器暴露流程实例，必须支持 latest 指向最近的一项，还可以另设持久流程 ID。如果服务器完全不暴露持久流程资源，草案要求回复 200 OK，不能用 201 Created。因此不能假设每个注册局都给转移一个永久网址。系统集成方仍可保留事务标识、可取得的流程状态，以及最终域名归属读取。