Summary

  • The RPP core draft, revision 01, dated 2 November 2026, maps provisioning of shared-database objects such as domain names to HTTP. It is active IETF working-group work, with the data objects draft defining the object model separately.
  • A domain transfer changes the sponsoring client, but RPP models the transfer as a Process Object. The initiating client uses POST /domainNames/{name}/processes/transferProcesses; the draft's response example is 201 Created with a Location pointing to a transfer-process URL.
  • The initiator can cancel a pending process; the current sponsor can reject or approve it. A durable messages endpoint can later report asynchronous completion, and a retrieved message stays in the queue until the client explicitly acknowledges it.

Domain transfers are often described as movement: a name leaves one registrar and arrives at another. The RPP core record presents a proposed HTTP interface for the work behind that sentence. Its transfer route does not compress request, approval, completion and receipt into one web response. It creates a process with its own lifecycle. The word “Created” on the first response applies to the process resource in the draft's example. It does not certify a new sponsor in the registry's domain record.

RPP is designed as its own protocol, even where an operator bridges it to an EPP backend. The core draft maps operations to URL paths, HTTP methods, headers and status codes; a companion data-objects draft supplies the model, and representation formats are specified elsewhere. That division matters for operators reading a trace. An HTTP result tells them which step the server accepted. They must identify the object of that result before turning it into a claim about the domain.

The created object is a process

Section 16.9.5 calls a transfer a change of sponsoring client and treats it as a Process Object. To start one, the gaining registrar sends a POST to the domain's transferProcesses collection. The example response is 201 Created, with Location ending in /transferProcesses/latest and an RPP result code. The named resource represents the latest transfer process. The draft does not say that this first 201 has already rewritten the sponsor field. A dashboard that converts it directly into “your domain moved” has skipped the central decision.

The client can ask for process status with GET. If the transfer is pending, the initiating client can cancel using DELETE on the process. The currently sponsoring client can POST transferReject or transferApprove to the corresponding operation under the latest process. These are different actors with different authority. A gaining registrar can start a request; it cannot make the losing registrar's approval appear by changing a URL. The operational record needs the submitted request, the process state, the decision and the resulting domain record.

The draft also limits what the URL promises. If a server exposes process instances, it must support access to the most recent instance through latest; it may also assign a persistent process identifier. When the server chooses not to expose a persistent process resource at all, it must return 200 OK rather than 201 Created. Operators cannot assume that every implementation will preserve a long-lived process URL. They can demand an equivalent evidence trail in their own integration: transaction identifiers, process status when available, and a final object readback.

The inbox is another receipt, with its own acknowledgement

The draft's messages endpoint is a durable queue of asynchronous notices to a client. Completion of a transfer requiring another party's approval is one example. The client retrieves messages with GET and acknowledges a specific message with DELETE. A message that was merely fetched remains in the queue until explicit acknowledgement. This separation keeps “we saw the notice” from being silently promoted to “we handled the notice.” It also means the first transfer response and the eventual completion notice are separate evidence events.

Process signalling has its own precision. When a normal operation creates a process as a side effect, section 15 uses a Link response header with rel="rpp-process"; the process attribute identifies its type, and a processId appears if the server assigned a persistent identifier. The latest flag points to the most recent process of that type. These links help a client find the work it must follow. A link to unfinished work is a useful control surface, not the work's final verdict.

The official draft packet contains no measured registry deployment or completed domain transfer trace. A test using a controlled domain would record the POST response, process GET results, any current-sponsor decision, queued completion message, explicit message acknowledgement and final sponsor readback. That sequence would show when the customer-facing status can honestly change. The draft already gives the editorial point a crisp form: an HTTP URL can name a transfer request while the domain is still at home with its old sponsor.

RPP core revision 01 · Datatracker status · RPP data objects · RFC 5730