Summary

  • RFC 8334 distinguishes a Launch Registration from a Launch Application. In the application model, a valid create can receive EPP result 1001, an assigned applicationID and pendingCreate while the registry has not yet allocated the domain.
  • The result is a precise receipt for command acceptance, not a compressed proof of trademark priority, allocation, registration, registry publication, DNS delegation or service reachability. Those verbs belong to different owners and different clocks.
  • An auditable account joins transaction IDs, phase and policy, application state, ordered poll messages and final domain:panData, then checks the resulting domain object and DNS planes separately. A single green “success” light destroys that chain.

The most revealing line in RFC 8334 is not an exotic XML element. It is an ordinary-looking success message.

The example server response says Command completed successfully; action pending. Its result code is 1001. The response carries the launch phase and an applicationID. For an operator reading a dashboard at speed, the first half of the sentence can dominate: completed successfully. For a customer, success can sound like the domain is theirs. For an executive, a completed create may look like a registration event.

The second half changes the object of the claim. The command succeeded. The allocation decision did not yet happen.

That distinction is the centre of the Launch Phase Mapping for the Extensible Provisioning Protocol. RFC 8334 was published on the IETF Standards Track in March 2018 and is collectively authored by J. Gould, W. Tan and G. Brown. The IANA EPP Extension Registry records the mapping with RFC 8334 as its reference. Gavin Brown is the person followed here because his standards work offers a clean way to inspect the interval between accepted instruction and operational fact. He is not the sole author, the registry, the validation authority or the allocator.

The IETF Datatracker profile captured on 31 August 2026 says Brown has spent 25 years in the DNS and domain-name industries, including 22 years at Team Internet PLC, formerly CentralNic, 14 of them as CTO, and now works for ICANN. It lists four RFCs, including RFC 8334, and current public roles including chair of the RESTful Provisioning Protocol work and ARTART reviewer. Those dated facts explain the domain expertise. They do not transfer any registry’s launch discretion to him.

Two different things called create

RFC 8334 begins by separating two launch models that ordinary status language often merges.

A Launch Registration is a single registration made during a launch phase when the server uses a first-come, first-served model. The server creates the domain registration as the operation succeeds. A Launch Application is different. It represents an intention to register a domain in a model where the server may accept multiple applications for that same domain and later select one for allocation.

“Multiple applications” is a capability of this model, not a universal fact about launches. A registry can choose other models. A phase can impose its own rules. A server that does not support Launch Applications must reject that form. The standard gives interoperable language for the choice; it does not choose the registry’s allocation policy.

When a Launch Application create is valid, the protocol consequence is exact. The server must create an application object, assign it an application identifier, set the RFC 5731 pendingCreate status and return the applicationID. That identifier lets later operations refer to one application even when several applications concern the same domain name.

This is genuine success. The server has accepted a correctly formed operation under the applicable protocol context and has created state that must be tracked. It would be wrong to call it a failure merely because the domain is not yet allocated.

It would be equally wrong to promote the receipt into a registration. The object created is an application object. Its status is pending. Its identifier identifies the application. None of those facts says that a steady-state domain object now belongs to the applicant.

The grammar matters because production systems routinely flatten nouns. A database column named domain_create_success can hide whether it contains an application acceptance or a registration. A customer notification can say “created” without naming the object. A financial system can recognise revenue before the allocation decision. A security review can search for a domain object when only an application record exists.

The repair is simple in principle: never store a bare verb. Record which object changed, under which phase and policy, at what time, and what remains unresolved.

What result 1001 actually receipts

RFC 5730 defines the EPP core. Result 1001 means the command completed successfully while the requested action remains pending. The transaction response can retain the client transaction identifier supplied by the client and must provide the server transaction identifier. Those values make the request and response correlatable across logs.

For a Launch Application, the useful receipt therefore includes at least the client and server transaction IDs, server time, sponsoring client, domain name, phase, optional subphase, create form, result code, application identifier, RFC 5731 object status and launch status.

That bundle supports a narrow statement: this server, under this protocol and policy context, accepted and recorded this application operation at this time.

It does not support six broader statements that often travel with the word success:

  1. The applicant has proved a legal or trademark entitlement.
  2. The registry has selected this application over competing applications.
  3. A domain registration now exists in its final state.
  4. Public registry data or RDAP already exposes the domain.
  5. The domain is delegated in the authoritative zone.
  6. A service at the domain is reachable or controlled by the applicant.

Each statement can become true later. None is encoded by 1001.

This is an agency problem as much as a protocol problem. The registrar client can submit. A validation provider can assess a mark or notice artefact. The registry can apply launch policy and allocate. The registry publication system can expose data. The zone operator can publish delegation. Authoritative name servers can answer. A service operator can configure an application. One actor’s successful verb does not silently grant the next actor’s mandate.

Phase names do not contain the policy

RFC 8334 defines launch phase values including sunrise, landrush, claims, open and custom. The client must identify the target phase. The server should validate the phase and may validate a subphase against its active configuration. Phases can overlap, and the optional name attribute can refine a subphase or name a custom phase.

Those fields are necessary correlation evidence. They are not a complete policy document.

Two registries can use the same phase label while applying different submission windows, validation providers, fee rules, tie-breaking procedures, applicant restrictions or allocation schedules. RFC 8334 deliberately leaves much server policy out of band. The protocol can say which phase a command targeted without explaining every rule that made the result possible.

An investigation must therefore preserve the applicable policy version and effective time beside the EPP record. “Sunrise” alone cannot show whether a particular mark form was mandatory, whether more than one application was allowed, when validation occurred, or how competing valid applications were ranked. “Claims” alone cannot prove that every required notice was shown and acknowledged.

RFC 7848 supplies the mark and signed-mark structures used by related launch mechanisms. RFC 8334 can carry mark, signed-mark, validation code or notice material depending on the phase and command form. That provenance matters when applicable. It still does not make a mark object an allocation decision.

A valid signed mark can support a validation step. A notice acknowledgement can support proof that a notice workflow occurred. A validator identifier can name the validation context. The registry remains responsible for interpreting those inputs under its policy. Treating the artefact as automatic entitlement would collapse evidence into authority.

The reverse error is also possible. An auditor should not condemn a missing mark or notice field until establishing that the active phase, form and policy required it. The minimum initial specification coordinates the exchange; local policy supplies the accountable choice. Evidence must retain both without pretending either is the other.

Pending is a history, not a label

RFC 8334 defines launch statuses including pendingValidation, validated, invalid, pendingAllocation, allocated, rejected and custom. Where launch status is supported, an application in a non-final launch state retains RFC 5731 pendingCreate. The standard allows states to be skipped because server policies do not all use the same sequence.

The point of the state model is not to produce a prettier final badge. It is to preserve a sequence of decisions.

Consider three applications for the same domain. One may fail validation. Another may be validated but wait for an allocation procedure. A third may move directly under a policy that does not require the same validation step. If the system stores only the most recent status, it loses which checks happened, which were skipped by policy and which message informed the sponsoring client.

RFC 5730’s poll queue gives asynchronous change an operational channel. Messages have identifiers. Clients request queued messages and acknowledge the ones they have received. RFC 8334 says servers should use poll messages for intermediate application changes. For final allocated or rejected status, the server must insert the RFC 5731 domain:panData pending-action message.

That final message is more than a notification convenience. It closes the protocol history for the pending action. An auditable chain keeps the message ID, queue time, receipt time, acknowledgement, result, domain, application ID, client and server transaction identifiers, and the policy state that produced it.

Allocation and rejection are not symmetrical business outcomes, but both are final launch evidence. Allocated means the application has been selected and the corresponding registration can be represented as an RFC 5731 domain object. Rejected means this application did not become that registration. Neither word should be manufactured from silence, a timeout or an empty public search.

The confidentiality section makes that caution explicit. Even the existence of an application and its contents may be confidential. Unauthorized operations must receive result 2201, and server policy can provide filtered information to some clients. A public observer who cannot see an application is not entitled to conclude that it does not exist. Access control changes the observation surface, not the underlying state.

Allocation still is not the running domain

Suppose the final poll message says allocated. The evidentiary object has changed. The applicant now has a successful allocation outcome, and the registry should be able to expose the resulting RFC 5731 domain object to an authorized client.

The next common mistake is to let allocation swallow the rest of the operational chain.

A domain object in the registry is not necessarily public in RDAP at the same instant. Publication can have its own processing path and filtering rules. A registered domain is not necessarily delegated in the TLD zone. A delegated domain may return no useful authoritative answer yet. An authoritative answer does not prove that an HTTPS service is configured, reachable from every network or controlled by the party assumed by the observer.

These are not pedantic delays. They determine who should act when a launch appears stuck. If the application is pending, the registry allocation workflow owns the question. If allocation is final but the domain object is absent, registry provisioning or projection needs review. If the domain object exists but the parent zone lacks delegation, the zone-publication path is implicated. If delegation exists but service fails, the registrant’s nameserver or application layer may own the incident.

Running-Code Primacy supplies the discipline: accept a receipt for the layer it actually observes. EPP state proves EPP state. Registry readback proves registry state. RDAP proves what that service publishes from its vantage point. The parent zone and authoritative servers prove DNS facts at a time and vantage. A connection attempt proves a service observation. None should impersonate the others.

Reconstruct the evidence join

A consequential account of a launch application should be reconstructable as adjoining receipts:

  1. Submission: client and server transaction IDs, create time, sponsoring client, exact domain, result and server endpoint.
  2. Policy context: phase, subphase, command form, policy version, effective interval and relevant allocation procedure.
  3. Application identity: applicationID, initial pendingCreate, initial launch status and authorized viewers.
  4. Validation provenance: validator, mark or signed-mark reference, code and notice evidence only where required by the applicable form.
  5. State history: ordered statuses, poll message IDs, creation and retrieval times, acknowledgements, skipped-state rationale and exceptions.
  6. Final action: allocated or rejected domain:panData, with the related transaction and application identifiers.
  7. Domain readback: the resulting RFC 5731 domain object if allocated, including sponsoring client, object status and timestamps.
  8. Operational readback: registry or RDAP publication, parent-zone delegation, authoritative DNS answers and service reachability as separate timed observations.
  9. Confidentiality: access basis, filtering rule, retention, disclosure boundary and audit owner.

The chain is deliberately longer than a success column. It protects every participant. The applicant can prove the server accepted the application. The registry can show that acceptance was not allocation. The validator can show what it assessed without claiming the final choice. Operations can locate a delay at the correct boundary. Auditors can avoid exposing confidential application data merely to prove that a workflow existed.

RFC 8334’s achievement is not that it makes “success” simple. It makes the unfinished part nameable. The application ID gives pending state a durable identity; the status and poll model give later decisions an ordered channel; the final pending-action data records the close. Good governance begins by refusing to erase those distinctions.

Sources