Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.topJiangsu Bangning Science & Technology Co.,Ltd.55hl.comView
25. EPP (Extensible Provisioning Protocol)
25.1. Overview
The Applicant provides services to the public through KSRP provided by the Back-End Service Provider. KSRP provides Registrars with a registry service interface for the domain name .STRINGʺ over EPP 1.0. The Back-End Service Provider has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.

25.2. Introduction to EPP
EPP is an xml-based text protocol. It is widely used as a standard protocol for domain name registration between Registry and Registrar.
The EPP protocol suite consists of RFCs 5730~5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731~5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.
EPP provides four basic service elements: service discovery, commands, response and an extension framework.
The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.
The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.
KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).
25.3. APIs Provided for Registrars via EPP
KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.
a) Session Management
APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).
A Registrar sends the Login command to request ID authentication and session establishment with the EPP server; Upon successful authentication and session establishment, Registrars begin to send other EPP commands. Each of the subsequent commands shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.
b) Query
APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domain, contact and host objects. (Please refer to Table 25-1 in Q25_attachment)

The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).
The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.
The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.
In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.
c) Object Change
APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)

The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.
The Renew command is used by Registrars to renew a domain name.
The Transfer command is used by Registrars to transfer domain names or contacts.
The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).
d) Miscellaneous
KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrar deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.
If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.
25.4. Compatibility
The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.
25.4.1. Compliance with RFCs
The interfaces for Registrars mainly follow the RFCs 5730~5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.
a) Compliance with RFC 5730
RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.
b) Compliance with RFC 5731
KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.
c) Compliance with RFC 5732
KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.
d) Compliance with RFC 5733
KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.
e) Compliance with RFC 5734
KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate–based authentication via TLS to ensure the data security.
f) Compliance with RFC 5735
KSRP has not yet used RFC 5735 to extend EPP protocol. However, if the Applicant’s business requires functional expansion to be made to the standard EPP, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement.
25.4.2. Specification Related to Redemption Period (RFC 3915)
KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.
25.4.3. Specification Related to DNSSEC (RFC 5910)
KSRP complies with RFC 5910 and RFCs 4033~4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.
25.5. Consistency
25.5.1. Consistency with Technical Plan
The SRS of KSRP fully implements EPP1.0, covering all functions required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.
25.6. Resourcing Plan
The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.
gTLDFull Legal NameE-mail suffixDetail
.wangZodiac Leo Limitedzodiac-corp.comView
25. EPP (Extensible Provisioning Protocol)
25.1. Overview
The Applicant provides services to the public through KSRP provided by the Back-End Service Provider. KSRP provides Registrars with a registry service interface for the domain name .STRINGʺ over EPP 1.0. The Back-End Service Provider has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.

25.2. Introduction to EPP
EPP is an xml-based text protocol. It is widely used as a standard protocol for domain name registration between Registry and Registrar.
The EPP protocol suite consists of RFCs 5730~5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731~5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.
EPP provides four basic service elements: service discovery, commands, response and an extension framework.
The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.
The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.
KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).
25.3. APIs Provided for Registrars via EPP
KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.
a) Session Management
APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).
A Registrar sends the Login command to request ID authentication and session establishment with the EPP server; Upon successful authentication and session establishment, Registrars begin to send other EPP commands. Each of the subsequent commands shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.
b) Query
APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domain, contact and host objects. (Please refer to Table 25-1 in Q25_attachment)

The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).
The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.
The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.
In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.
c) Object Change
APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)

The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.
The Renew command is used by Registrars to renew a domain name.
The Transfer command is used by Registrars to transfer domain names or contacts.
The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).
d) Miscellaneous
KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrar deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.
If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.
25.4. Compatibility
The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.
25.4.1. Compliance with RFCs
The interfaces for Registrars mainly follow the RFCs 5730~5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.
a) Compliance with RFC 5730
RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.
b) Compliance with RFC 5731
KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.
c) Compliance with RFC 5732
KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.
d) Compliance with RFC 5733
KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.
e) Compliance with RFC 5734
KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate–based authentication via TLS to ensure the data security.
f) Compliance with RFC 5735
KSRP has not yet used RFC 5735 to extend EPP protocol. However, if the Applicant’s business requires functional expansion to be made to the standard EPP, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement.
25.4.2. Specification Related to Redemption Period (RFC 3915)
KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.
25.4.3. Specification Related to DNSSEC (RFC 5910)
KSRP complies with RFC 5910 and RFCs 4033~4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.
25.5. Consistency
25.5.1. Consistency with Technical Plan
The SRS of KSRP fully implements EPP1.0, covering all functions required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.
25.6. Resourcing Plan
The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.