Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
Extracted elements (31)
Launch phases MAY overlap (e.g., "claims" and "landrush" simultaneously); the recommended approach is to set "claims" as the <launch:phase> value and "landrush" as the sub-phase via the "name" attribute, rather than introducing new phase values.
The extension is designed to be flexible, requiring only a minimum set of required elements and not prescribing server or client interpretation; processing is typically highly policy-dependent and specific to implementations, with server policy communicated out-of-band.
The <launch:claimKey> is used as the lookup key to the CNIS instead of the domain name itself, to securely query the service without exposing a well-known value like a domain name that could be observed or enumerated by third parties.
This extension builds on RFC 5731 (EPP domain name mapping) and RFC 7848 (mark and signed mark formats). The <mark:mark> and <smd:signedMark> elements and their schemas are defined in RFC 7848 and imported by the launch schema; new mark formats can be supported by substituting for the <mark:abstractMark> element.
A Launch Application or Launch Registration MUST set the "pendingCreate" status if a launch status is supported and is not one of the final statuses ("allocated" and "rejected").
A server MUST support at least one of the four mark validation models (code, mark, code with mark, signed mark) for validating trademark information.
A server that does not support Launch Applications during its launch phase MUST return an EPP error result code of 2102 when receiving an EPP <update> or <delete> command with the launch extension.
All subsequent launch operations on a Launch Application MUST be qualified by the previously assigned application identifier using the <launch:applicationID> element to facilitate correlation.
For final statuses ("allocated" and "rejected"), the server MUST insert a <domain:panData> poll message per RFC 5731 with the <launch:infData> extension; for intermediate statuses the server SHOULD insert poll messages.
If the Claims Check command is processed successfully, the EPP response MUST contain an <extension> <launch:chkData> element identifying the launch namespace with <launch:phase> and one or more <launch:cd> elements.
If the ICANN TMCH is not used or multiple Trademark Validators are used, the Validator Identifier MUST be defined using the "validatorID" attribute, and the server MUST define and make the list of supported validator identifiers available to clients via an out-of-band mechanism.
Implementations MUST NOT depend on XML namespace prefixes ("launch", "smd", "mark") and instead MUST employ a proper namespace-aware XML parser and serializer to interpret and output XML documents.
The availability check information defined in the EPP domain name mapping MUST NOT be returned for the Claims Check Command or the Trademark Check Command.
The <launch:phase> element MUST be included by the client to define the target launch phase. The server SHOULD validate the phase and MAY validate the sub-phase, returning EPP error 2306 on mismatch.
The server MUST return an EPP error result code of 2307 if it receives a check form (Claims Check, Availability Check, or Trademark Check) that is not supported by server policy.
Upon receiving a valid <domain:create> command to create a Launch Application, the server MUST create an application object, assign an application identifier, set the pendingCreate status, and return the application identifier to the client with the <launch:applicationID> element.
When using digital signatures with the "signed mark" validation model, the server MUST validate the digital signature.
Four EPP <create> extension forms: Sunrise Create Form (includes verified trademark info), Claims Create Form (includes claims notice acceptance info with noticeID, notAfter, acceptedDate), General Create Form (phase identifier only), and Mixed Create Form (combination of forms, typically with "custom" phase).
Four mark validation models are defined: "code" (mark code alone), "mark" (mark information alone with custom server validation), "code with mark" (code plus mark validated via external party), and "signed mark" (digitally signed mark validated via public key).
Launch application status values: pendingValidation, validated, invalid, pendingAllocation, allocated (final), rejected (final), and custom. Statuses MAY be skipped per server policy.
Launch phases defined: "sunrise" (trademark holder registrations with validation), "landrush" (post-sunrise non-trademark registrations), "claims" (requires trademark claims notice display), "open" (steady-state), and "custom" (server-defined, using the "name" attribute).
The <launch:notice> element in the Claims Create Form carries: <launch:noticeID> (unique notice identifier with optional validatorID attribute), <launch:notAfter> (notice expiry), and <launch:acceptedDate> (timestamp of registrant acceptance).
Three EPP <check> extension forms: Claims Check Form (type="claims", default) returns trademark match status and claim keys; Availability Check Form (type="avail") checks domain availability per phase; Trademark Check Form (type="trademark") checks trademarks independent of active launch phase.
RFC 8334 registers the EPP extension identifier "urn:ietf:params:xml:ns:launch-1.0" in the EPP Extension Registry per RFC 7451, with reference to this document.
RFC 8334 registers the XML namespace "urn:ietf:params:xml:ns:launch-1.0" in the IANA XML Namespace registry, with URI, registrant (IETF), and XML schema reference per RFC 3688.
The security considerations of RFC 5730 (EPP core), RFC 5731 (domain name mapping), and RFC 7848 (mark and signed mark) apply to this extension. Transport-layer security (e.g., TLS) is required for protecting sensitive trademark and claims notice data in transit.
The signed mark validation model provides cryptographic assurance that mark information has not been tampered with; the server MUST validate the digital signature using the public key of the external party. Other models (code, mark) rely on server-side policy and out-of-band secrets with weaker guarantees.
Launch application status transitions: new request enters pendingValidation; from there transitions to validated or invalid; invalid MAY loop back to pendingValidation; validated transitions to pendingAllocation; pendingAllocation transitions to allocated (final) or rejected (final); invalid MAY also transition directly to rejected.
The <launch:claimKey> element is returned in Claims Check and Trademark Check responses; it includes an optional "validatorID" attribute and is used as the lookup key to the CNIS in place of the domain name to avoid exposing well-known values.
The <launch:creData> response element contains <launch:phase> (mirrors the create request phase) and <launch:applicationID> (server-assigned application identifier string); returned only when multiple applications of a domain name are supported.
The <launch:infData> response element contains <launch:phase>, optional <launch:applicationID>, optional <launch:status> (with "s" attribute), and zero or more <mark:mark> elements (only if includeMark="true" was requested).