From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8334.txt | 3251 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3251 insertions(+) create mode 100644 doc/rfc/rfc8334.txt (limited to 'doc/rfc/rfc8334.txt') diff --git a/doc/rfc/rfc8334.txt b/doc/rfc/rfc8334.txt new file mode 100644 index 0000000..dc52047 --- /dev/null +++ b/doc/rfc/rfc8334.txt @@ -0,0 +1,3251 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Gould +Request for Comments: 8334 VeriSign, Inc. +Category: Standards Track W. Tan +ISSN: 2070-1721 Cloud Registry + G. Brown + CentralNic Ltd + March 2018 + + + Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) + +Abstract + + This document describes an Extensible Provisioning Protocol (EPP) + extension mapping for the provisioning and management of domain name + registrations and applications during the launch of a domain name + registry. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8334. + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Gould, et al. Standards Track [Page 1] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 + 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Application Identifier . . . . . . . . . . . . . . . . . 4 + 2.2. Validator Identifier . . . . . . . . . . . . . . . . . . 5 + 2.3. Launch Phases . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3.1. Trademark Claims Phase . . . . . . . . . . . . . . . 6 + 2.4. Status Values . . . . . . . . . . . . . . . . . . . . . . 9 + 2.4.1. State Transition . . . . . . . . . . . . . . . . . . 11 + 2.5. Poll Messaging . . . . . . . . . . . . . . . . . . . . . 12 + 2.6. Mark Validation Models . . . . . . . . . . . . . . . . . 14 + 2.6.1. Element . . . . . . . . . . . . . . 15 + 2.6.2. Element . . . . . . . . . . . . . . . . . 16 + 2.6.3. Digital Signature . . . . . . . . . . . . . . . . . . 16 + 2.6.3.1. Element . . . . . . . . . . . . 16 + 2.6.3.2. Element . . . . . . . . . 16 + 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 17 + 3.1. EPP Command . . . . . . . . . . . . . . . . . . . 17 + 3.1.1. Claims Check Form . . . . . . . . . . . . . . . . . . 17 + 3.1.2. Availability Check Form . . . . . . . . . . . . . . . 22 + 3.1.3. Trademark Check Form . . . . . . . . . . . . . . . . 23 + 3.2. EPP Command . . . . . . . . . . . . . . . . . . . 26 + 3.3. EPP Command . . . . . . . . . . . . . . . . . . 30 + 3.3.1. Sunrise Create Form . . . . . . . . . . . . . . . . . 30 + 3.3.2. Claims Create Form . . . . . . . . . . . . . . . . . 36 + 3.3.3. General Create Form . . . . . . . . . . . . . . . . . 39 + 3.3.4. Mixed Create Form . . . . . . . . . . . . . . . . . . 40 + 3.3.5. Create Response . . . . . . . . . . . . . . . . . . . 42 + 3.4. EPP Command . . . . . . . . . . . . . . . . . . 43 + 3.5. EPP Command . . . . . . . . . . . . . . . . . . 44 + 3.6. EPP Command . . . . . . . . . . . . . . . . . . . 46 + 3.7. EPP Command . . . . . . . . . . . . . . . . . 46 + 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 46 + 4.1. Launch Schema . . . . . . . . . . . . . . . . . . . . . . 46 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 + 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 54 + 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 55 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 55 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 56 + 7.2. Informative References . . . . . . . . . . . . . . . . . 57 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 + + + + + + +Gould, et al. Standards Track [Page 2] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +1. Introduction + + This document describes an extension mapping for version 1.0 of the + Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping + specifies a flexible schema that can be used to implement several + common use cases related to the provisioning and management of domain + name registrations and applications during the launch of a domain + name registry. + + It is typical for domain registries to operate in special modes as + they begin operation to facilitate allocation of domain names, often + according to special rules. This document uses the term "launch + phase" and the shorter form "launch" to refer to such a period. + Multiple launch phases and multiple models are supported to enable + the launch of a domain name registry. Server policy determines what + is supported and validated. Communication of the server policy is + typically performed using an out-of-band mechanism that is not + specified in this document. + + The EPP domain name mapping [RFC5731] is designed for the steady- + state operation of a registry. During a launch period, the model in + place may be different from what is defined in the EPP domain name + mapping [RFC5731]. For example, registries often accept multiple + applications for the same domain name during the "sunrise" launch + phase, referred to as a Launch Application. A Launch Registration + refers to a registration made during a launch phase when the server + uses a "first-come, first-served" model. Even in a "first-come, + first-served" model, additional steps and information might be + required, such as trademark information. In addition, RFC 7848 + [RFC7848] defines a registry interface for the Trademark Claims or + "claims" launch phase that includes support for presenting a + Trademark Claims Notice to the registrant. This document proposes an + extension to the domain name mapping in order to provide a uniform + interface for the management of Launch Applications and Launch + Registrations in launch phases. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + XML [W3C.REC-xml11-20060816] is case sensitive. Unless stated + otherwise, XML specifications and examples provided in this document + MUST be interpreted in the character case presented in order to + develop a conforming implementation. + + + +Gould, et al. Standards Track [Page 3] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + In examples, "C:" represents lines sent by a protocol client and "S:" + represents lines returned by a protocol server. Indentation and + whitespace in examples are provided only to illustrate element + relationships and are not a REQUIRED feature of this protocol. The + use of "..." is used as shorthand for elements defined outside this + document. + + A Launch Registration is a domain name registration during a launch + phase when the server uses a "first-come, first-served" model. Only + a single registration for a domain name can exist in the server at a + time. + + A Launch Application represents the intent to register a domain name + during a launch phase when the server accepts multiple applications + for a domain name, and the server later selects one of the + applications to allocate as a registration. Many Launch Applications + for a domain name can exist in the server at a time. + + The XML namespace prefix "launch" is used for the namespace + "urn:ietf:params:xml:ns:launch-1.0", but implementations MUST NOT + depend on it and instead employ a proper namespace-aware XML parser + and serializer to interpret and output the XML documents. + + The XML namespace prefix "smd" is used for the namespace + "urn:ietf:params:xml:ns:signedMark-1.0" [RFC7848], but + implementations MUST NOT depend on it and instead employ a proper + namespace-aware XML parser and serializer to interpret and output the + XML documents. + + The XML namespace prefix "mark" is used for the namespace + "urn:ietf:params:xml:ns:mark-1.0" [RFC7848], but implementations MUST + NOT depend on it and instead employ a proper namespace-aware XML + parser and serializer to interpret and output the XML documents. + +2. Object Attributes + + This extension adds additional elements to the EPP domain name + mapping [RFC5731]. Only those new elements are described here. + +2.1. Application Identifier + + Servers MAY allow multiple applications, referred to as a Launch + Application, of the same domain name during its launch phase + operations. Upon receiving a valid command to create + a Launch Application, the server MUST create an application object + corresponding to the request, assign an application identifier for + the Launch Application, set the pendingCreate status [RFC5731], and + return the application identifier to the client with the + + + +Gould, et al. Standards Track [Page 4] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + element. In order to facilitate correlation, + all subsequent launch operations on the Launch Application MUST be + qualified by the previously assigned application identifier using the + element. + +2.2. Validator Identifier + + The Validator Identifier is unique to the server and is the + identifier for a Trademark Validator, which validates marks and has a + repository of validated marks. The OPTIONAL "validatorID" attribute + is used to define the Validator Identifier of the Trademark + Validator. Registries MAY support more than one third-party + Trademark Validator. The unique set of Validator Identifier values + supported by the server is up to server policy. The Internet + Corporation for Assigned Names and Numbers (ICANN) Trademark + Clearinghouse (TMCH) is the default Trademark Validator and is + reserved for the Validator Identifier of "tmch". If the ICANN TMCH + is not used or multiple Trademark Validators are used, the Validator + Identifier MUST be defined using the "validatorID" attribute. + + The Validator Identifier MAY be related to one or more issuer + identifiers of the and elements defined in + [RFC7848]. Both the Validator Identifier and the Issuer Identifier + used MUST be unique in the server. If the ICANN TMCH is not used or + multiple Trademark Validators are used, the server MUST define the + list of supported validator identifiers and MUST make this + information available to clients using a mutually acceptable, out-of- + band mechanism. + + The Validator Identifier may define a non-Trademark Validator that + supports a form of claims, where claims and a Validator Identifier + can be used for purposes beyond trademarks. + +2.3. Launch Phases + + The server MAY support multiple launch phases sequentially or + simultaneously. The element MUST be included by the + client to define the target launch phase of the command. The server + SHOULD validate the phase and MAY validate the sub-phase of the + element against the active phase and OPTIONAL sub- + phase of the server, and return an EPP error result code of 2306 + [RFC5730] if there is a mismatch. + + The following launch phase values are defined: + + sunrise: The phase during which trademark holders can submit + registrations or applications with trademark information that can + be validated by the server. + + + +Gould, et al. Standards Track [Page 5] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + landrush: A post-"sunrise" launch phase when non-trademark holders + are allowed to register domain names with steps taken to address a + large volume of initial registrations. + + claims: The phase, as defined in Section 2.3.1, in which a claims + notice must be displayed to a prospective registrant of a domain + name that matches trademarks. + + open: A phase that is also referred to as "steady state". Servers + may require additional trademark protection during this phase. + + custom: A custom server launch phase that is defined using the + "name" attribute. + + For extensibility, the element includes an OPTIONAL + "name" attribute that can define a sub-phase or the full name of the + phase when the element has the "custom" value. For + example, the "claims" launch phase could have two sub-phases that + include "landrush" and "open". + + Launch phases MAY overlap to support the "claims" launch phase, + defined in Section 2.3.1, and to support a traditional "landrush" + launch phase. The overlap of the "claims" and "landrush" launch + phases SHOULD be handled by setting "claims" as the + value and setting "landrush" as the sub-phase with the "name" + attribute. For example, the element should be + claims. + +2.3.1. Trademark Claims Phase + + The Trademark Claims Phase is when a claims notice must be displayed + to a prospective registrant of a domain name that matches trademarks. + See [ICANN-TMCH] for additional details of trademark claims handling. + The source of the trademarks is a Trademark Validator, and the source + of the claims notice information is a Claims Notice Information + Service (CNIS), which may be directly linked to a Trademark + Validator. The client interfaces with 1) the server to determine if + a trademark exists for a domain name, 2) a CNIS to get the claims + notice information, and 3) the server to pass the claims notice + acceptance information in a create command. This document supports + the Trademark Claims Phase in two ways, including: + + Claims Check Form: Is defined in Section 3.1.1 and is used to + determine whether or not there are any matching trademarks for a + domain name. If there is at least one matching trademark that + exists for the domain name, a claims key is returned. The mapping + of domain names and the claims keys is based on an out-of-band + interface between the server and the Trademark Validator. The + + + +Gould, et al. Standards Track [Page 6] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + CNIS associated with the claims key Validator Identifier + (Section 2.2) MUST accept the claims key as the basis for + retrieving the claims information. + + Claims Create Form: Is defined in Section 3.3.2 and is used to pass + the claims notice acceptance information in a create command. The + notice identifier () format, validation rules, + and server processing is up to the interface between the server + and the Trademark Validator. The CNIS associated with the + Validator Identifier (Section 2.2) MUST generate a notice + identifier compliant with the element. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 7] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following shows the Trademark Claims Phase registration flow: + + .------------. .--------. .--------. .------. + | Registrant | | Client | | Server | | CNIS | + '------------' '--------' '--------' '------' + | Request Domain | | | + | Registration | | | + |--------------->| Domain Check | | + | |--------------------------->| | + | Domain | Domain Unavailable .------------. | + | Unavailable |<---------------------( Available? ) | + |<---------------| No '------------' | + | | Domain Available | Yes | + | |<---------------------------| | + | | Domain Claims Check | | + | |--------------------------->| | + | | .---------. | + | | Claims Don't Exist / Does \ | + | |<--------------------( Domain have ) | + | | No \ Claims? / | + | | '---------' | + | | Domain Create | | Yes | + | |--------------------------->| | | + | Domain | Domain Registered | | | + | Registered |<---------------------------| | | + |<---------------| | | + | | | + | | Claims Exist with Claims Keys | | + | |<------------------------------' | + | | | + .-----. | | Request Claims Info with Claims Key | + |Abort| | Display |-------------------------------------->| + '-----' | Claims | Return Claims Info | + ^ | Notice |<--------------------------------------| + | No |<---------------| | + | .------. Yes | | + '-( Ack? )----------->| Domain Claims Create Form | | + '------' |--------------------------->| | + | Registration | Error .----------------------. | + | Error |<-----------( Validation Successful? ) | + |<---------------| No '----------------------' | + | | | Yes | + | Domain | Domain Registered | | + | Registered |<---------------------------| | + |<---------------| | | + + Figure 1 + + + + +Gould, et al. Standards Track [Page 8] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +2.4. Status Values + + A Launch Application or Launch Registration object MAY have a launch + status value. The element is used to convey the + launch status pertaining to the object, beyond what is specified in + the object mapping. A Launch Application or Launch Registration MUST + set the "pendingCreate" status [RFC5731] if a launch status is + supported and is not one of the final statuses ("allocated" and + "rejected"). + + The following status values are defined using the required "s" + attribute: + + pendingValidation: The initial state of a newly created application + or registration object. The application or registration requires + validation, but the validation process has not yet completed. + + validated: The application or registration meets relevant registry + rules. + + invalid: The application or registration does not validate according + to registry rules. Server policies permitting, it may transition + back into "pendingValidation" for revalidation, after + modifications are made to ostensibly correct attributes that + caused the validation failure. + + pendingAllocation: The allocation of the application or registration + is pending based on the results of some out-of-band process (for + example, an auction). + + allocated: The object corresponding to the application or + registration has been provisioned. This is a possible end state + of an application or registration object. + + rejected: The application or registration object was not + provisioned. This is a possible end state of an application or + registration object. + + custom: A custom status that is defined using the "name" attribute. + + Each status value MAY be accompanied by a string of human-readable + text that describes the rationale for the status applied to the + object. The OPTIONAL "lang" attribute, as defined in [RFC5646], MAY + be present to identify the language if the negotiated value is + something other than the default value of "en" (English). + + + + + + +Gould, et al. Standards Track [Page 9] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + For extensibility, the element includes an OPTIONAL + "name" attribute that can define a sub-status or the full name of the + status when the status value is "custom". The server SHOULD use one + of the non-"custom" status values. + + Status values MAY be skipped. For example, an application or + registration MAY immediately start at the "allocated" status, or an + application or registration MAY skip the "pendingAllocation" status. + If the launch phase does not require validation of a request, an + application or registration MAY immediately skip to + "pendingAllocation". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 10] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +2.4.1. State Transition + + The transitions between the states is a matter of server policy. + This diagram defines one possible set of permitted transitions. + + | request + | + | +--------------------------+ + | | | + v v | + +-------------------+ | + | | | + | pendingValidation +--------------+ | + | | | | + +---------+---------+ | | + | | | + | | | + v v | + +-----------+ +---------+ | + | | | | | + | validated | | invalid +--+ + | | | | + +-----+-----+ +----+----+ + | | + | | + v | + +-------------------+ | + | | | + | pendingAllocation +-----------+ | + | | | | + +---------+---------+ | | + | | | + | | | + | | | + | | | + | | | + v v v + +---------+ +--------+ + / \ / \ + | allocated | | rejected | + \ / \ / + +---------+ +--------+ + + + Figure 2 + + + + + + +Gould, et al. Standards Track [Page 11] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +2.5. Poll Messaging + + A Launch Application MUST be handled as an EPP domain name object as + specified in RFC 5731 [RFC5731], with the "pendingCreate" status and + launch status values defined in Section 2.4. A Launch Registration + MAY be handled as an EPP domain name object as specified in RFC 5731 + [RFC5731], with the "pendingCreate" status and launch status values + defined in Section 2.4. As a Launch Application or Launch + Registration transitions between the status values defined in + Section 2.4, the server SHOULD insert poll messages, per [RFC5730], + for the applicable intermediate statuses, including the + "pendingValidation", "validated", "pendingAllocation", and "invalid" + statuses, using the element with the + extension. The element MAY contain + non-mandatory information, like contact and name server information. + Also, further extensions that would normally be included in the + response of a command, per [RFC5731], MAY be included. + For the final statuses, including the "allocated" and "rejected" + statuses, the server MUST insert a poll message, per + [RFC5731], with the extension. + + The following is an example poll message for a Launch Application + that has transitioned to the "pendingAllocation" state. + + S: + S: + S: + S: + S: Command completed successfully; ack to dequeue + S: + S: + S: 2013-04-04T22:01:00.0Z + S: Application pendingAllocation. + S: + S: + S: + S: domain.example + S: ... + S: + S: + S: + S: + S: sunrise + S: abc123 + S: + S: + + + +Gould, et al. Standards Track [Page 12] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + + The following is an example poll message for an + "allocated" Launch Application. + + S: + S: + S: + S: + S: Command completed successfully; ack to dequeue + S: + S: + S: 2013-04-04T22:01:00.0Z + S: Application successfully allocated. + S: + S: + S: + S: domain.example + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: 2013-04-04T22:00:00.0Z + S: + S: + S: + S: + S: sunrise + S: abc123 + S: + S: + S: + S: + S: BCD-23456 + S: 65432-WXY + S: + S: + S: + + + + + +Gould, et al. Standards Track [Page 13] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example poll message for an + "allocated" Launch Registration. + + S: + S: + S: + S: + S: Command completed successfully; ack to dequeue + S: + S: + S: 2013-04-04T22:01:00.0Z + S: Registration successfully allocated. + S: + S: + S: + S: domain.example + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: 2013-04-04T22:00:00.0Z + S: + S: + S: + S: + S: sunrise + S: + S: + S: + S: + S: BCD-23456 + S: 65432-WXY + S: + S: + S: + +2.6. Mark Validation Models + + A server MUST support at least one of the following models for + validating trademark information: + + code: Use of a mark code by itself to validate that the mark matches + the domain name. This model is supported using the + element with just the element. + + + + + +Gould, et al. Standards Track [Page 14] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + mark: The mark information is passed without any other validation + element. The server will use some custom form of validation to + validate that the mark information is authentic. This model is + supported using the element with just the + (Section 2.6.2) element. + + code with mark: A code is used along with the mark information by + the server to validate the mark utilizing an external party. The + code represents some form of secret that matches the mark + information passed. This model is supported using the + element that contains both the and + the (Section 2.6.2) elements. + + signed mark: The mark information is digitally signed as described + in the Digital Signature section (Section 2.6.3). The digital + signature can be directly validated by the server using the public + key of the external party that created the signed mark using its + private key. This model is supported using the + (Section 2.6.3.1) and (Section 2.6.3.2) + elements. + + More than one , (Section 2.6.3.1), + or (Section 2.6.3.2) element MAY be + specified. The maximum number of marks per domain name is up to + server policy. + +2.6.1. Element + + The element is used by the "code", "mark", and + "code with mark" validation models and has the following child + elements: + + : OPTIONAL mark code used to validate the + (Section 2.6.2) information. The mark code is a mark-specific + secret that the server can verify against a third party. The + OPTIONAL "validatorID" attribute is the Validator Identifier + (Section 2.2) whose value indicates which Trademark Validator the + code originated from, with no default value. + + : OPTIONAL mark information with child elements defined + in the Mark section (Section 2.6.2). + + + + + + + + + + +Gould, et al. Standards Track [Page 15] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example element with both a + and (Section 2.6.2) element. + + + + 49FD46E6C4B45C55D4AC + + ... + + + +2.6.2. Element + + A element describes an applicant's prior right to a given + domain name that is used with the "mark", "mark with code", and + "signed mark" validation models. The element is defined + in [RFC7848]. A new mark format can be supported by creating a new + XML schema for the mark that has an element that substitutes for the + element from [RFC7848]. + +2.6.3. Digital Signature + + Digital signatures MAY be used by the server to validate the mark + information, when using the "signed mark" validation model with the + (Section 2.6.3.1) and + (Section 2.6.3.2) elements. When using digital signatures, the + server MUST validate the digital signature. + +2.6.3.1. Element + + The element contains the digitally signed mark + information. The element is defined in [RFC7848]. + A new signed mark format can be supported by creating a new XML + schema for the signed mark that has an element that substitutes for + the element from [RFC7848]. + +2.6.3.2. Element + + The element contains an encoded form of the + digitally signed (Section 2.6.3.1) element. The + element is defined in [RFC7848]. A new + encoded signed mark format can be supported by creating a new XML + schema for the encoded signed mark that has an element that + substitutes for the element from [RFC7848]. + + + + + + + +Gould, et al. Standards Track [Page 16] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in the EPP core protocol specification [RFC5730]. The command + mappings described here are specifically for use in the Launch Phase + Extension. + + This mapping is designed to be flexible, requiring only a minimum set + of required elements. + + While it is meant to serve several use cases, it does not prescribe + any interpretation by the client or server. Such processing is + typically highly policy dependent and therefore specific to + implementations. + + Operations on application objects are done via one or more of the + existing EPP commands defined in the EPP domain name mapping + [RFC5731]. Registries MAY choose to support a subset of the + operations. + +3.1. EPP Command + + There are three forms of the extension to the EPP command: + the Claims Check Form (Section 3.1.1), the Availability Check Form + (Section 3.1.2), and the Trademark Check Form (Section 3.1.3). The + element "type" attribute defines the form, with the + value of "claims" for the Claims Check Form (Section 3.1.1), "avail" + for the Availability Check Form (Section 3.1.2), and "trademark" for + the Trademark Check Form (Section 3.1.3). The default value of the + "type" attribute is "claims". The forms supported by the server is + determined by server policy. The server MUST return an EPP error + result code of 2307 [RFC5730] if it receives a check form that is not + supported. + +3.1.1. Claims Check Form + + The Claims Check Form defines a new command called the Claims Check + Command that is used to determine whether or not there are any + matching trademarks, in the specified launch phase, for each domain + name passed in the command, that require the use of the "Claims + Create Form" on a Domain Create Command. The availability check + information defined in the EPP domain name mapping [RFC5731] MUST NOT + be returned for the Claims Check Command. This form is the default + form and MAY be explicitly identified by setting the + "type" attribute to "claims". + + + + + + +Gould, et al. Standards Track [Page 17] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + Instead of returning whether the domain name is available, the Claims + Check Command will return whether or not at least one matching + trademark exists for the domain name, which requires the use of the + "Claims Create Form" on a Domain Create Command. If there is at + least one matching trademark that exists for the domain name, a + element is returned. The client MAY then use the + value of the element to obtain information needed + to generate the Trademark Claims Notice from the Trademark Validator + based on the Validator Identifier (Section 2.2). The unique notice + identifier of the Trademark Claims Notice MUST be passed in the + element of the extension to the Create Command + (Section 3.3). + + The elements in the EPP command of EPP domain + name mapping [RFC5731] define the domain names to check for matching + trademarks. The element contains the following child + element: + + : Contains the value of the active launch phase of the + server. The server SHOULD validate the value according to + Section 2.3. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 18] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example Claims Check Command using the + domain command and the extension with the "type" + explicitly set to "claims", to determine if "domain1.example", + "domain2.example", and "domain3.example" require claims notices + during the "claims" launch phase: + + C: + C: + C: + C: + C: + C: domain1.example + C: domain2.example + C: domain3.example + C: + C: + C: + C: + C: claims + C: + C: + C: ABC-12345 + C: + C: + + If the command has been processed successfully, the EPP + MUST contain an element that + identifies the launch namespace. The element + contains the following child elements: + + : The phase that mirrors the element + included in the . + + : One or more elements that contain the + following child elements: + + : Contains the fully qualified name of the queried + domain name. This element MUST contain an "exists" attribute + whose value indicates if a matching trademark exists for the + domain name that requires the use of the "Claims Create Form" + on a Domain Create Command. A value of "1" (or "true") means + that a matching trademark does exist and that the "Claims + Create Form" is required on a Domain Create Command. A value + + + + + +Gould, et al. Standards Track [Page 19] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + of "0" (or "false") means that a matching trademark does not + exist or that the "Claims Create Form" is NOT required on a + Domain Create Command. + + : Zero or more OPTIONAL claim keys that MAY be + passed to a third-party Trademark Validator such as the ICANN + TMCH for querying the information needed to generate a + Trademark Claims Notice. The is used as + the key for the query in place of the domain name to securely + query the service without using a well-known value like a + domain name. The OPTIONAL "validatorID" attribute is the + Validator Identifier (Section 2.2) whose value indicates + which Trademark Validator to query for the claims notice + information, with the default being the ICANN TMCH. The + "validatorID" attribute MAY reference a non-trademark claims + clearinghouse identifier to support other forms of claims + notices. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 20] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example Claims Check response when a claims + notice for the "claims" launch phase is not required for the domain + name domain1.example, is required for the domain name domain2.example + in the "tmch", and is required for the domain name domain3.example in + the "tmch" and "custom-tmch": + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: claims + S: + S: domain1.example + S: + S: + S: domain2.example + S: + S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 + S: + S: + S: + S: domain3.example + S: + S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 + S: + S: + S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + + + + + + + + +Gould, et al. Standards Track [Page 21] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.1.2. Availability Check Form + + The Availability Check Form defines additional elements to extend the + EPP command described in the EPP domain name mapping + [RFC5731]. No additional elements are defined for the EPP + response. This form MUST be identified by setting the + "type" attribute to "avail". + + The EPP command is used to determine if an object can be + provisioned within a repository. Domain names may be made available + only in unique launch phases, whilst remaining unavailable for + concurrent launch phases. In addition to the elements expressed in + the , the command is extended with the + element that contains the following child element: + + : The launch phase to which domain name availability + should be determined. The server SHOULD validate the value and + return an EPP error result code of 2306 [RFC5730] if it is + invalid. + + The following is an example Availability Check Form Command using the + domain command and the extension with the + "type" set to "avail", to determine the availability of two domain + names in the "idn-release" custom launch phase: + + C: + C: + C: + C: + C: + C: domain1.example + C: domain2.example + C: + C: + C: + C: + C: custom + C: + C: + C: ABC-12345 + C: + C: + + + + + + +Gould, et al. Standards Track [Page 22] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The Availability Check Form does not define any extension to the + response of a domain command. After processing the command, + the server replies with a standard EPP response as defined in the EPP + domain name mapping [RFC5731]. + +3.1.3. Trademark Check Form + + The Trademark Check Form defines a new command called the Trademark + Check Command that is used to determine whether or not there are any + matching trademarks for each domain name passed in the command, + independent of the active launch phase of the server and whether the + "Claims Create Form" is required on a Domain Create Command. The + availability check information defined in the EPP domain name mapping + [RFC5731] MUST NOT be returned for the Trademark Check Command. This + form MUST be identified by setting the "type" + attribute to "trademark". + + Instead of returning whether the domain name is available, the + Trademark Check Command will return whether or not at least one + matching trademark exists for the domain name. If there is at least + one matching trademark that exists for the domain name, a + element is returned. The client MAY then use the + value of the element to obtain Trademark Claims + Notice information from the Trademark Validator based on the + Validator Identifier (Section 2.2). + + The elements in the EPP command of EPP domain + name mapping [RFC5731] define the domain names to check for matching + trademarks. The element does not contain any child + elements with the "Trademark Check Form": + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 23] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example Trademark Check Command using the + domain command and the extension with the "type" set + to "trademark", to determine if "domain1.example", "domain2.example", + and "domain3.example" have any matching trademarks: + + C: + C: + C: + C: + C: + C: domain1.example + C: domain2.example + C: domain3.example + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + If the command has been processed successfully, the EPP + MUST contain an element that + identifies the launch namespace. The element + contains the following child elements: + + : One or more elements that contain the + following child elements: + + : Contains the fully qualified name of the queried + domain name. This element MUST contain an "exists" attribute + whose value indicates if a matching trademark exists for the + domain name. A value of "1" (or "true") means that a + matching trademark does exist. A value of "0" (or "false") + means that a matching trademark does not exist. + + : Zero or more OPTIONAL claim keys that MAY be + passed to a third-party Trademark Validator such as the ICANN + TMCH for querying the information needed to generate a + Trademark Claims Notice. The is used as + the key for the query in place of the domain name to securely + query the service without using a well-known value like a + domain name. The OPTIONAL "validatorID" attribute is the + Validator Identifier (Section 2.2) whose value indicates + + + +Gould, et al. Standards Track [Page 24] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + which Trademark Validator to query for the claims notice + information, with the default being the ICANN TMCH. The + "validatorID" attribute MAY reference a non-trademark claims + clearinghouse identifier to support other forms of claims + notices. + + The following is an example Trademark Check response for the "claims" + launch phase when no matching trademarks are found for the domain + name domain1.example, matching trademarks are found for the domain + name domain2.example in the "tmch", and matching trademarks are found + for domain name domain3.example in the "tmch" and "custom-tmch": + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: domain1.example + S: + S: + S: domain2.example + S: + S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 + S: + S: + S: + S: domain3.example + S: + S: 2013041500/2/6/9/rJ1NrDO92vDsAzf7EQzgjX4R0000000001 + S: + S: + S: 20140423200/1/2/3/rJ1Nr2vDsAzasdff7EasdfgjX4R000000002 + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + + + +Gould, et al. Standards Track [Page 25] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.2. EPP Command + + This extension defines additional elements to extend the EPP + command and response to be used in conjunction with the EPP domain + name mapping [RFC5731]. + + The EPP command is used to retrieve information for a Launch + Registration or Launch Application. The Application Identifier + (Section 2.1) returned in the element of the create + response (Section 3.3) can be used for retrieving information for a + Launch Application. A element is sent along with the + regular domain command. The element includes an + OPTIONAL "includeMark" boolean attribute, with a default value of + "false", to indicate whether or not to include the mark in the + response. The element contains the following child + elements: + + : The phase during which the application or + registration was submitted or is associated with. Server policy + defines the phases that are supported. The server SHOULD + validate the value and return an EPP error result code of 2306 + [RFC5730] if it is invalid. + + : OPTIONAL application identifier of the + Launch Application. + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 26] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command with the + extension to retrieve information for the sunrise + application for domain.example and application identifier "abc123": + + C: + C: + C: + C: + C: + C: domain.example + C: + C: + C: + C: + C: sunrise + C: abc123 + C: + C: + C: ABC-12345 + C: + C: + + The following is an example domain command with the + extension to retrieve information for the sunrise + registration for domain.example: + + C: + C: + C: + C: + C: + C: domain.example + C: + C: + C: + C: + C: sunrise + C: + C: + C: ABC-12345 + C: + C: + + + + +Gould, et al. Standards Track [Page 27] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + If the query was successful, the server replies with a + element along with the regular EPP . The + contains the following child elements: + + : The phase during which the application was submitted + or is associated with that matches the associated command + . + + : OPTIONAL Application Identifier of the + Launch Application. + + : OPTIONAL status of the Launch Application using one + of the supported status values (Section 2.4). + + : Zero or more (Section 2.6.2) elements only + if the "includeMark" attribute is "true" in the command. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 28] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain response using the + extension with the mark information: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: domain.example + S: EXAMPLE1-REP + S: + S: jd1234 + S: sh8013 + S: sh8013 + S: ClientX + S: ClientY + S: 2012-04-03T22:00:00.0Z + S: + S: 2fooBAR + S: + S: + S: + S: + S: + S: sunrise + S: abc123 + S: + S: + S: ... + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + + + + + + +Gould, et al. Standards Track [Page 29] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.3. EPP Command + + There are four forms of the extension to the EPP command + that include the Sunrise Create Form (Section 3.3.1), the Claims + Create Form (Section 3.3.2), the General Create Form (Section 3.3.3), + and the Mixed Create Form (Section 3.3.4). The form used is + dependent on the supported launch phases (Section 2.3) as defined + below. + + sunrise: The EPP command with the "sunrise" launch phase is + used to submit a registration with trademark information that can + be verified by the server with the value. The + Sunrise Create Form (Section 3.3.1) is used for the "sunrise" + launch phase. + + landrush: The EPP command with the "landrush" launch phase + MAY use the General Create Form (Section 3.3.3) to explicitly + specify the phase and optionally define the expected type of + object to create. + + claims: The EPP command with the "claims" launch phase is + used to pass the information associated with the presentation and + acceptance of the claims notice. The Claims Create Form + (Section 3.3.2) is used, and the General Create Form + (Section 3.3.3) MAY be used for the "claims" launch phase. + + open: The EPP command with the "open" launch phase is + undefined, but the form supported is up to server policy. The + Claims Create Form (Section 3.3.2) MAY be used to pass the + information associated with the presentation and acceptance of the + claims notice if required for the domain name. + + custom: The EPP command with the "custom" launch phase is + undefined, but the form supported is up to server policy. + +3.3.1. Sunrise Create Form + + The Sunrise Create Form of the extension to the EPP domain name + mapping [RFC5731] includes the verifiable trademark information that + the server uses to match against the domain name to authorize the + domain create. A server MUST support one of four models in Mark + Validation Models (Section 2.6) to verify the trademark information + passed by the client. + + A element is sent along with the regular + domain command. The element has an OPTIONAL "type" + attribute that defines the expected type of object ("application" or + "registration") to create. The server SHOULD validate the "type" + + + +Gould, et al. Standards Track [Page 30] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + attribute, when passed, against the type of object that will be + created, and return an EPP error result code of 2306 [RFC5730] if the + type is incorrect. The element contains the + following child elements: + + : The identifier for the launch phase. The server + SHOULD validate the value according to Section 2.3. + + or or : + + : Zero or more elements. The + child elements are defined in + " Element" (Section 2.6.1). + + : Zero or more elements. The + child elements are defined in + " Element" (Section 2.6.3.1). + + : Zero or more + elements. The child elements are + defined in " Element" + (Section 2.6.3.2). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 31] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, following the "code" validation model, + with multiple sunrise codes: + + C: + C: + C: + C: + C: + C: domain.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: sunrise + C: + C: + C: 49FD46E6C4B45C55D4AC + C: + C: + C: 49FD46E6C4B45C55D4AD + C: + C: + C: + C: 49FD46E6C4B45C55D4AE + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + + + + + + + +Gould, et al. Standards Track [Page 32] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, following the "mark" validation model, + with the mark information: + + C: + C: + C: + C: + C: + C: domainone.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: sunrise + C: + C: + C: ... + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 33] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, following the "code with mark" validation + model, with the code and mark information: + + C: + C: + C: + C: + C: + C: domain.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: sunrise + C: + C: + C: 49FD46E6C4B45C55D4AC + C: + C: ... + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 34] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, following the "signed mark" validation + model, with the signed mark information for a sunrise application: + + C: + C: + C: + C: + C: + C: domainone.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: sunrise + C: + C: ... + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 35] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, following the "signed mark" validation + model, with the base64-encoded signed mark information: + + C: + C: + C: + C: + C: + C: domainone.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: sunrise + C: + C: ... + C: + C: + C: + C: ABC-12345 + C: + C: + +3.3.2. Claims Create Form + + The Claims Create Form of the extension to the EPP domain name + mapping [RFC5731] includes the information related to the + registrant's acceptance of the claims notice. + + A element is sent along with the regular + domain command. The element has an OPTIONAL "type" + attribute that defines the expected type of object ("application" or + "registration") to create. The server SHOULD validate the "type" + attribute, when passed, against the type of object that will be + created, and return an EPP error result code of 2306 [RFC5730] if the + type is incorrect. The element contains the + following child elements: + + + + +Gould, et al. Standards Track [Page 36] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + : Contains the value of the active launch phase of the + server. The server SHOULD validate the value according to + Section 2.3. + + : One or more elements that contain + the following child elements: + + : Unique notice identifier for the claims + notice. The element has an OPTIONAL + "validatorID" attribute that is used to define the Validator + Identifier (Section 2.2); it's value indicates which + Trademark Validator is the source of the claims notice, with + the default being the ICANN TMCH. + + : Expiry of the claims notice. + + : Contains the date and time that the + claims notice was accepted. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 37] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension with the information for + the "tmch" and the "custom-tmch" validators, for the "claims" launch + phase: + + C: + C: + C: + C: + C: + C: domain.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: claims + C: + C: + C: 370d0b7c9223372036854775807 + C: 2014-06-19T10:00:00.0Z + C: + C: 2014-06-19T09:00:00.0Z + C: + C: + C: + C: + C: 470d0b7c9223654313275808 + C: 2014-06-19T10:00:00.0Z + C: + C: 2014-06-19T09:00:30.0Z + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + +Gould, et al. Standards Track [Page 38] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.3.3. General Create Form + + The General Create Form of the extension to the EPP domain name + mapping [RFC5731] includes the launch phase and optionally the object + type to create. The OPTIONAL "type" attribute defines the expected + type of object ("application" or "registration") to create. The + server SHOULD validate the "type" attribute, when passed, against the + type of object that will be created, and return an EPP error result + code of 2306 [RFC5730] if the type is incorrect. + + A element is sent along with the regular + domain command. The element contains the following + child element: + + : Contains the value of the active launch phase of the + server. The server SHOULD validate the value according to + Section 2.3. + + The following is an example domain command using the + extension for a "landrush" launch phase application: + + C: + C: + C: + C: + C: + C: domain.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: landrush + C: + C: + C: ABC-12345 + C: + C: + + + + + +Gould, et al. Standards Track [Page 39] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.3.4. Mixed Create Form + + The Mixed Create Form supports a mix of the create forms where, for + example, the Sunrise Create Form (Section 3.3.1) and the Claims + Create Form (Section 3.3.2) MAY be supported in a single command by + including both the verified trademark information and the information + related to the registrant's acceptance of the claims notice. The + server MAY support the Mixed Create Form. The "custom" launch phase + SHOULD be used when using the Mixed Create Form. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 40] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command using the + extension, with a mix of the Sunrise Create Form + (Section 3.3.1) and the Claims Create Form (Section 3.3.2), including + both a mark and a notice: + + C: + C: + C: + C: + C: + C: domainone.example + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: custom + C: + C: + C: ... + C: + C: + C: + C: + C: 49FD46E6C4B45C55D4AC + C: + C: 2012-06-19T10:00:10.0Z + C: + C: 2012-06-19T09:01:30.0Z + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + + + + + +Gould, et al. Standards Track [Page 41] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.3.5. Create Response + + If the create was successful, the server MAY add a + element to the regular EPP to indicate that the server + generated an Application Identifier (Section 2.1), when multiple + applications of a given domain name are supported; otherwise, no + extension is included with the regular EPP . The + element contains the following child elements: + + : The phase of the application that mirrors the + element included in the . + + : The application identifier of the + application. + + The following is an example response when multiple overlapping + applications are supported by the server: + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: domain.example + S: 2010-08-10T15:38:26.623854Z + S: + S: + S: + S: + S: sunrise + S: 2393-9323-E08C-03B1 + S: + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + + + + + + +Gould, et al. Standards Track [Page 42] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.4. EPP Command + + This extension defines additional elements to extend the EPP + command to be used in conjunction with the domain name mapping. + + When an EPP command with the extension is sent to a server + that does not support Launch Applications, it will fail. A server + that does not support Launch Applications during its launch phase + MUST return an EPP error result code of 2102 [RFC5730] when receiving + an EPP command with the extension. + + Registry policies permitting, clients may update an application + object by submitting an EPP command along with a + element to indicate the application object to be + updated. The element contains the following child + elements: + + : The phase during which the application was submitted + or is associated with. The server SHOULD validate the value and + return an EPP error result code of 2306 [RFC5730] if it is + invalid. + + : The application identifier for which the + client wishes to update. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 43] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + The following is an example domain command with the + extension to add and remove a name server of a + sunrise application with the application identifier "abc123": + + C: + C: + C: + C: + C: + C: domain.example + C: + C: + C: ns2.domain.example + C: + C: + C: + C: + C: ns1.domain.example + C: + C: + C: + C: + C: + C: + C: sunrise + C: abc123 + C: + C: + C: ABC-12345 + C: + C: + + This extension does not define any extension to the response of an + domain command. After processing the command, the server + replies with a standard EPP response as defined in the EPP domain + name mapping [RFC5731]. + +3.5. EPP Command + + This extension defines additional elements to extend the EPP + command to be used in conjunction with the domain name mapping. + + A client MUST NOT pass the extension on an EPP command to a + server that does not support Launch Applications. A server that does + + + + + +Gould, et al. Standards Track [Page 44] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + not support Launch Applications during its launch phase MUST return + an EPP error result code of 2102 [RFC5730] when receiving an EPP + command with the extension. + + Registry policies permitting, clients MAY withdraw an application by + submitting an EPP command along with a + element to indicate the application object to be deleted. The + element contains the following child elements: + + : The phase during which the application was submitted + or is associated with. The server SHOULD validate the value and + return an EPP error result code of 2306 [RFC5730] if it is + invalid. + + : The application identifier for which the + client wishes to delete. + + The following is an example domain command with the + extension: + + C: + C: + C: + C: + C: + C: domain.example + C: + C: + C: + C: + C: sunrise + C: abc123 + C: + C: + C: ABC-12345 + C: + C: + + This extension does not define any extension to the response of a + domain command. After processing the command, the server + replies with a standard EPP response as defined in the EPP domain + name mapping [RFC5731]. + + + + + + + +Gould, et al. Standards Track [Page 45] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +3.6. EPP Command + + This extension does not define any extension to the EPP + command or response described in the EPP domain name mapping + [RFC5731]. + +3.7. EPP Command + + This extension does not define any extension to the EPP + command or response described in the EPP domain name mapping + [RFC5731]. + +4. Formal Syntax + + The EPP Launch Phase Mapping schema is presented in Section 4.1. + + The formal syntax presented is a complete schema representation of + the object mapping suitable for automated validation of EPP XML + instances. The BEGIN and END tags are not part of the schema; they + are used to note the beginning and ending of the schema for URI + registration purposes. + +4.1. Launch Schema + + Copyright (c) 2018 IETF Trust and the persons identified as authors + of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions + are met: + + o Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + + o Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in + the documentation and/or other materials provided with the + distribution. + + o Neither the name of Internet Society, IETF or IETF Trust, nor the + names of specific contributors, may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + + + +Gould, et al. Standards Track [Page 46] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + BEGIN + + + + + + + + + + + Extensible Provisioning Protocol v1.0 + domain name + extension schema + for the launch phase processing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 48] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 49] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 51] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 53] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + + + + + + + + + + + + + + + END + +5. IANA Considerations + +5.1. XML Namespace + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in [RFC3688]. + + IANA has registered the launch namespace as follows: + + URI: urn:ietf:params:xml:ns:launch-1.0 + + Registrant Contact: IESG + + XML: None. Namespace URIs do not represent an XML specification. + + + + + + + + + + +Gould, et al. Standards Track [Page 54] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + IANA has registered the launch XML schema as follows: + + URI: urn:ietf:params:xml:schema:launch-1.0 + + Registrant Contact: IESG + + XML: See the "Formal Syntax" section of this document. + +5.2. EPP Extension Registry + + IANA has registered the EPP extension described in this document in + the "Extensions for the Extensible Provisioning Protocol (EPP)" + registry described in [RFC7451]. The details of the registration are + as follows: + + Name of Extension: "Launch Phase Mapping for the Extensible + Provisioning Protocol (EPP)" + + Document Status: Standards Track + + Reference: RFC 8334 + + Registrant Name and Email Address: IESG, + + TLDs: Any + + IPR Disclosure: None + + Status: Active + + Notes: None + +6. Security Considerations + + The mapping extensions described in this document do not provide any + security services beyond those described by EPP [RFC5730], the EPP + domain name mapping [RFC5731], and protocol layers used by EPP. The + security considerations described in these other specifications apply + to this specification as well. + + Updates to, and deletion of, an application object MUST be restricted + to clients authorized to perform the said operation on the object. + + Information contained within an application, or even the mere fact + that an application exists, may be confidential. Any attempt to + operate on an application object by an unauthorized client MUST be + rejected with an EPP 2201 (authorization error) return code. Server + policy may allow an operation with filtered output by clients + + + +Gould, et al. Standards Track [Page 55] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + + other than the sponsoring client, in which case the + and responses SHOULD be filtered to include only + fields that are publicly accessible. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + . + + [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", + RFC 7848, DOI 10.17487/RFC7848, June 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [W3C.REC-xml11-20060816] + Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., + Yergeau, F., and J. Cowan, "Extensible Markup Language + (XML) 1.1 (Second Edition)", World Wide Web Consortium + Recommendation REC-xml11-20060816, August 2006, + . + + + + + + + +Gould, et al. Standards Track [Page 56] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +7.2. Informative References + + [ICANN-TMCH] + Lozano, G., "ICANN TMCH functional specifications", Work + in Progress, draft-ietf-regext-tmch-func-spec-03, July + 2017. + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, . + +Acknowledgements + + The authors wish to acknowledge the efforts of the leading + participants of the Community TMCH Model that led to many of the + changes to this document, which include Chris Wright, Jeff Neuman, + Jeff Eckhaus, and Will Shorter. + + Special suggestions that have been incorporated into this document + were provided by Harald Alvestrand, Ben Campbell, Spencer Dawkins, + Jothan Frakes, Keith Gaughan, Seth Goldman, Scott Hollenbeck, Michael + Holloway, Jan Jansen, Rubens Kuhl, Mirja Kuehlewind, Warren Kumari, + Ben Levac, Gustavo Lozano, Klaus Malorny, Alexander Mayrhofer, Alexey + Melnikov, Patrick Mevzek, James Mitchell, Francisco Obispo, Mike + O'Connell, Eric Rescorla, Bernhard Reutner-Fischer, Sabrina Tanamal, + Trung Tran, Ulrich Wisser, and Sharon Wodjenski. + + Some of the description of the Trademark Claims Phase was based on + the work done by Gustavo Lozano in the ICANN TMCH functional + specifications. + + + + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 57] + +RFC 8334 Launch Phase Mapping for EPP March 2018 + + +Authors' Addresses + + James Gould + VeriSign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: jgould@verisign.com + URI: http://www.verisign.com + + + Wil Tan + Cloud Registry + Suite 32 Seabridge House + 377 Kent St + Sydney, NSW 2000 + Australia + + Phone: +61 414 710899 + Email: wil@cloudregistry.net + URI: http://www.cloudregistry.net + + + Gavin Brown + CentralNic Ltd + 35-39 Mooregate + London, England EC2R 6AR + United Kingdom + + Phone: +44 20 33 88 0600 + Email: gavin.brown@centralnic.com + URI: https://www.centralnic.com + + + + + + + + + + + + + + + + + + +Gould, et al. Standards Track [Page 58] + -- cgit v1.2.3