25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

25.1. EPP
.ntt will be firmly committed to supporting EPP 1.0 through the use of our SRS. Additionally, in order to stay current with evolving standards, .ntt will implement support for updates to RFCs 5730, 5731, 5732, 5733, 5734, and other related updates that will be adopted as the ʺProposed Standard [RFC 2026, section 4.1.1].ʺ This support will become available in production within 180 days of ICANNʹs approval of the ʺProposed Standardʺ specifications. Additionally, in order for us to become compatible with the most current protocol, we will adopt flexible policies to support the use of the obsolete extensions by registrars, and will implement applicable EPP extensions which meet the current standards and make them available in a test environment.
Thick Model:
We will adopt the ʺthickʺ data model to provide the .ntt Registry. We will operate the Registry with complete thick data and provide the EPP interface compatible with domains, hosts, contacts and other required commands. The referenced schemas are epp-1.0 eppcom-1.0, domain-1.0, host-1.0, contact-1.0, idn-1.0, rgp-1.0, secDNS-1.1 or later versions.
Localized Message Support:
The .ntt SRS will allow specifying the language for ʺOPTIONALʺ messages in several EPP responses, and the languages available will be notified by 〈greeting〉 with a language code specified in RFC4646. If the language is not specified in the 〈login〉 command, then the message in ʺenʺ (English) will be used as default. .ntt will support the message output in ʺjaʺ (Japanese) and support the encoding as UTF-8.
IDN:
.ntt will support IDN in compliance with IDNA2008. IDN is discussed in more detail in the answer for #44 (IDNs). .ntt will support and accept the XML encoding such as UTF-8 and UTF-16, and UTF-8 will be used as default.
Redemption Grace Period (RGP) :
.ntt will support the RGP which conforms to RFC3915. The EPP will accept ʺrestore requestʺ and ʺrestore reportʺ submitted in the format specified in RGP 1.0.
EPP Applications Security:
The .ntt SRS will conform to RFC5734, and implement the protection via SSL⁄TLS protocol to offer the TCP communications between servers and clients. In addition, the .ntt SRS will follow the technical updates released by IETF.
Information Notice via Polling:
Notice using poll commands will be available to registrars as a method of notification. The poll command notifies registrars of the transition state during the transfer, insufficient funds in the account, and other appropriate information.
25.1.1. Domain Object
For DOMAIN object, .ntt will allow to set all the OPTIONAL items described in RFC5731. Following are the server policies for setting values:
〈check〉 command
One or more 〈name〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈name〉 element, whether or not the registration is available or not. In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element, and at the same time, if a specific language had been selected for the ʺlangʺ attribute as a result of the negotiation with the client, then the information will be shown in such language.
〈create〉 command
.ntt will support DNSSEC. The DNSSEC will conform to RFC5910, and the schema used for the application will be secDNS-1.1, but secDNS-1.0 will not be supported:More details will be provided in the answer for #43 (DNSSEC).
.ntt will support the IDN registration, and the detailed description is provided in the answer for #44 (IDNs).
Since .ntt will handle the complete thick data model, the registration of 〈registrant〉 and 〈contact〉 element will be mandatory. The 〈contact〉 element must contain one or more values for each of ʺadmin,ʺ ʺbilling,ʺ and ʺtech.ʺ
The 〈period〉 element will be OPTIONAL. If no value is set in the request, a one year registration period will be set as a default, and a value of one to ten years can be permitted as the registration period. The period must be set in units of years, and if the period is set in units of months or more than ten years, then the request will generate a server policy error response.
〈info〉 command
The 〈info〉 command will control the content of response according to 〈authInfo〉 element. If the 〈authInfo〉 element is not specified, then the response for domain information will consist only of 〈name〉, 〈roid〉 and 〈clID〉. If the request includes an appropriate 〈authInfo〉 element, then all the items available as domain information will be returned in the response. This response will include the grace period information conforming to RFC3915. If the request includes an illegal 〈authInfo〉 element, then the error response will be returned without any domain information.
〈renew〉 command
The 〈period〉 element will be OPTIONAL. If no value is set in the request, a one year of registration period will be set as a default, and a value of one to ten years will be permitted as the registration period. The period must be set in units of years, and if the period is set in units of months or more than ten years, then the request will generate a server policy error response.
25.1.2. Host Object
For the host object, .ntt will conform to RFC5732, and all the items will be allowed to use. Following are the server policies for setting values:
〈check〉 command
One or more 〈name〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈name〉 element, whether or not the registration is available or not.
In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element, and at the same time, if a specific language had been selected for the ʺlangʺ attribute as a result of the negotiation with the client, then the information will be shown in such language.
25.1.3. Contact Object
For the contact object, .ntt will conform to RFC5733, and all the items will be allowed to be used. Following are the server policies for setting values:
〈check〉 command
One or more 〈id〉 elements can be contained in a request of 〈check〉 command. In return, the response will indicate, for each 〈id〉 element, whether or not the registration is available or not. In the response, the value of 〈avail〉 attribute will be set to ʺ1ʺ when the registration is available and the attribute will be set to ʺ0ʺ when the registration is not available. The reasons for the registration unavailability will be sent in the 〈reason〉 element.
〈create〉 command
All the items described in Section 2 of RFC5733, can be registered. In principle, the information in the English language must be registered, and for OPTIONAL, the registration in the Japanese language will be accepted, if ʺlocʺ is specified in postalInfoEnumType of 〈potalInfo〉. Languages other than English and Japanese will not be accepted.
〈info〉 command
The 〈info〉 command controls the content of response according to 〈authInfo〉 element. If the 〈authInfo〉 element is not specified, then the contact information excluding the items not subject to public posting (〈disclose flag=ʺ0ʺ〉) will be returned. If the request includes appropriate 〈authInfo〉 element, then all the items available as contact information will be returned in the response, regardless of the specification of disclose flags. When Request includes an inappropriate 〈authInfo〉 element, the error response is returned with no contact information.
25.2. EPP Extension
We do not plan for proprietary EPP extensions for .ntt. If we decide to create a proprietary EPP extension in the future, then we will follow the guideline described in RFC3735, and document the Extension according to the ʺInternet-Draftʺ format. Prior to implementation, we will then provide ICANN with the documents related to the supported EPP objects and the Extension, and we will update the documents accordingly.

25.3. Technical Resources
25.3.1. Implementations and Operations Experiences
The Registry Operator for .ntt is an ICANN accredited Registrar. The Registry⁄Registrar has the experiences in implementing and operating the SRS and EPP Registrar systems that require network communications, and has the knowledge in implementing and operating the RFC-compliant SRS.
Also, the Registry Operator has the sufficient know-how to operate as the Registrar in building the EPP Client system, specifically for example, know-how of the XML Schema management associated with each TLD, the TCP communication management, the session management and the implementation of polling functions through resident processes. The Registry Operator will be ready to promptly respond to any changes that take place in the specifications such as DNSSEC and IDN. Additionally, as a registrar serving various TLDs, the Registry Operator has built the architecture flexible enough to cope with proprietary EPP extensions of each SRS, and therefore has the abundant practical experiences and understanding on EPP extensions as well as the standard EPP specifications.

25.4. Resource Planning
25.4.1. Initial Implementation
The resources required for the EPP in terms of its implementations are described in the answer for (b-1) of #31.5.1 (Initial Implementation).
25.4.2. Ongoing Maintenance
The resources required for the EPP in terms of its ongoing maintenance are described in the answer for (d-1) of #31.5.2 (Ongoing Maintenance).

Similar gTLD applications: (2)