Back

25 Extensible Provisioning Protocol (EPP)

gTLDFull Legal NameE-mail suffixDetail
.styleTop Level Domain Holdings Limitedgmail.comView
The registry will make use of Espresso, a proprietary fork of the CoCCA SRS, which for many years has utilized an EPP API for the Registrar interface. The Registry System’s early adoption and implementation of EPP ensures that all EPP-enabled registrars will be able to easily ʺspeakʺ to the EPP enabled registry. This standardization minimizes development efforts and ensures regularity for registry transactions. The Espresso EPP implementation adheres strictly to ICANN and IETF standards, and was written according to and is fully compliant with the EPP standards as defined in the following RFCs listed below in RFCs Governing EPP Standards:

5730: Extensible Provisioning Protocol (EPP)
5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping
5732: Extensible Provisioning Protocol (EPP) Host Mapping
5733: Extensible Provisioning Protocol (EPP) Contact Mapping
3735: Extensible Provisioning Protocol (EPP) Transport over TCP

The Espresso Registry EPP provides the four basic service elements as defined in RFC 5730: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

The EPP tool used for the registry interface is compliant with IETF RFC standards, is extensible, scalable, fault-tolerant, configurable, secure, and fully auditable.

Espresso’s EPP templates and schemas match the relevant RFCs. The following is a snapshot of EPP schema used by registrars during a one-hour period. More than 30 top-level domains and over 250 registrars are already using CoCCA Tools, the EPP-based ccTLD system Espresso is based on. The registry system is already fully established, validated, and used daily in existing TLDs. When we launch .STYLE, contracted registrars will be provided immediate access and will be able to offer the TLD to their established customer bases as soon as they connect to the registry system. OTE is needed at all times for new registrars to test connectivity, and for old registrars to test new functions.

The Espresso Registry EPP component is EPP 1.0 and has all standard extensions. All the EPP Schemas and Templates that are utilized in Espresso are defined in the EPP RFCs listed above.

The Espresso EPP schema follow the IETF standardized EPP format. Please refer to “REQUEST, RESPONSEʺ in attachment “Q 25 EPP Sample Schemas” for an example of the REQUEST, RESPONSE.

Espresso supports the standard EPP schema including: login, logout, check, info, poll, transfer, create, delete, renew, transfer, update.

Please refer to “Live EPP Schema and Requestsʺ in attachment “Q 25 EPP Sample Schemas” examples showing live EPP schema and requests sent from registrars in the past. They are provided to fulfill the request for sample EPP schema demonstrating the ability to support EPP.

The secondary mode of interface offered to registrars is a secure web administration portal known as the graphic user interface (GUI). This web interface is accessible from any security-enabled browser connected to the Internet, allowing registrars to log into their accounts and manually manage domain portfolios on behalf of their customers. The web interface enables user-friendly registry system administration, TLD management, and registrar portfolio viewing. Registrars may register, renew, transfer, delete, and perform every domain management function. Offering a web interface allows administrative and finance, and customer service users to easily access the full functionality of the registry system. This extended functionality eases use, supports system clients, and expands market reach.

--EXTENSIONS--
In addition to the EPP operations detailed in RFCs 5730 - 5734, the Espresso Registry adds three extensions compliant with the extension framework described in RFC 5730. The additional functionality includes: a redemption grace period, an Intellectual Property verification mechanism, and the ability to provide contact proxies for display in Whois results. Please refer to “EPP Greeting Response Reportsʺ in attachment “Q 25 EPP Sample Schemas” for the EPP greeting response reports the extensions.


Espresso’s EPP extensions are made possible by the extension framework established in the EPP protocol. The framework provides for extensions at all of the protocol, object, and command-response levels, but Espresso has made extensions at only the command-response level. All of Espresso’s extensions relate to existing query or transform protocol commands. The specifics of each extension and the commands they relate to are described in the relevant extension sections that follow.

Espresso’s extensions have been made to query and transform commands and responses as categorized in RFC 5730. The set of query commands is: check, info, poll, and transfer. The set of transform commands is: create, delete, renew, transfer, and update. The specific commands from these sets that apply to each extension will be explicitly stated.

--REDEMPTION GRACE PERIOD (RGP)--
The redemption grace period extension is an extension of the EPP Domain mapping, and is a direct implementation of RFC 3915. Its purpose is to allow a grace period during which a registrar can reverse an action performed against a domain object and receive a refund for the original action. For instance, a registrar can renew a domain, then decide the renewal was a mistake and, by requesting that the domain be “restored” to its previous state, receive a refund. The refund and overall ability to restore a domain is contingent on the registrar exercising the restore request during the grace period. A domain’s state can be restored following any of the transform actions that typically incur a fee or result in a status change: registration, renewal, automated renewal, transfer, and delete. The redemption grace period extension is consistent with the registration life cycle as described in Question 27.

The RGP extension extends the domain info command’s response and the domain update command.

The domain info response extension simply tells the state that the domain is in with regard to the grace period by including the element rgpStatus. Please refer to “Extension Element from an Example Response for the info Commandʺ in attachment “Q 25 EPP Sample Schemas” for the extension element from an example response for the info command run on a domain that was recently registered.

The domain update command extension instructs the registry to restore a domain by including a restore element. The restore element can contain an optional report element. Until a report has been filed via EPP or the Registry’s web interface, the restore request will remain in a pending state and will not be completed.

An important requirement is that the update request must contain an empty domain:chg, domain:rem, or domain:add element within the standard domain:update element.

Please refer to “Domain Update Command (Report Not Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain but does not include a report.

Please refer to “Domain Update Command (Report Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain and includes the report.

Please refer to “Domain Name Extension Schema for Registry Grace Period Processingʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--INTELLECTUAL PROPERTY (IP) VERIFICATION--
The Espresso Registry adds an extension to support IP verification via the Trademark Clearing House (TMCH) verification.

Using TMCH verification, a client can receive automated, realtime pre-approval for a domain. This is especially helpful during the sunrise and landrush periods as the domain is registered immediately upon TMCH validation rather than going through the application process. When TMCH validation fails, the domain is given statuses pendingCreate and serverHold, thereby preventing the domain from being published to the zone files. The domain validation is then retried through the Registryʹs admin interface. A notification is sent to the administrator that a domain is pending approval. If an audit of the request proves legitimate, the domain is then published to the zone.

When a registrar includes a TMCH code in the registration request, TMCH validation is performed first against the domain, then against the registrant. If the Registry chooses to not use TMCH verification, registrars will receive an explanatory error in response to the domain:create command.

The IP verification extension extends only the domain:create command. The registrar adds the TMCH element to the extension section.

Please refer to “Example of the domain:create Extension Element with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with TMCH information.

Please refer to “Example of the domain:create Extension Element with Trademark Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with trademark information.

Please refer to “Formal Syntax for the domain:create Extension with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--WHOIS CONTACT PROXIES--
The proxy extension provides a framework for registrars to establish a full set of information to be provided in Whois responses while maintaining domain contacts’ privacy and still supplying the registry with the required contact related information. The registrar is able to create a contact proxy with similar data elements to those supplied when creating a typical contact. Once created, a proxy can be assigned to any contact controlled by the registrar. For contacts that have been assigned a proxy, Whois responses display the information from the proxy rather than the information for the actual contact.

The contact:create command and contact:create response were extended to facilitate contact proxies via EPP. A registrar may add an extension element that contains the structure to either create a new proxy or assign an existing proxy to the contact. The response to the contact:create command will contain the reference value for the proxy.

All proxies are identified by a reference. The reference can be provided during creation or is otherwise assigned by the Registry. When a proxy already exists, a registrar provides the existingProxy element which contains a reference element. The proxy identified by this reference will be assigned to the contact that is created as a result of the contact:create command.

Creating and updating a proxy is done by providing the newProxy element rather than the existingProxy element. The newProxy element contains a proxyDetails element as a container for the information necessary to create a proxy. The proxyDetails optionally contains a proxy:reference element. If the proxy:reference element matches an existing proxy, the existing proxy will be updated with the proxy details provided, otherwise a new proxy is created. When the proxy:reference element is not included, a reference value is assigned by the Registry.

The EPP aspect of the contact proxies is limited in scope. Only the contact:create command and contact:create command response were extended for contact proxies. The functional gaps in the EPP extension are adequately covered by Espresso’s GUI, described above. From the GUI a registrar can assign a proxy to an existing contact, unassign a proxy from a contact, create, update, and delete a proxy.

Please refer to “Example of the Extension Element Creating a New Contact Proxyʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when creating a new contact proxy.

Please refer to “Example of the Extension Element Assigning an Existing Contact Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when assigning an existing contact proxy to a contact.

Please refer to “Example of the Extension Section in a Response to a contact:create Command that Assigned a Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension section in a response to a contact:create command that assigned a proxy to a contact.

Please refer to “Formal Syntax for the Contact Proxy Extensionʺ in attachment “Q 25 EPP Sample Schemas” for formal syntax for the contact proxy extension.

--EPP PERSONNEL RESOURCES--
The number and type of personnel from Minds + Machines, our registry service provider, allocated to the implementation and maintenance of the EPP interface will vary depending on the stage of registry operations. Since the core registry system is already built, operational, and interfaces daily with registrars, the initial number of personnel allocated to EPP development will be limited to the man-hours required to create and fulfill any outstanding requirements, such as connecting to the Trademark Clearinghouse. Most ICANN-accredited registrars have already passed the OTE and are actively interfacing with Espresso on a daily basis for a TLD that is currently in operation. The Espresso Application Developers will actively keep the EPP extensions and connections up to date with relevant RFCs. The number of developers will scale accordingly as new requirements or functions are introduced, and new registrars that require assistance contract with the registry and require assistance passing the OTE.

The developers will collaborate with the Database Developers and Database Administrators to keep the EPP schema and Espresso platform up to date and in compliance with the relevant RFCs (as detailed in the introduction to Question 25: EPP). The Registrar Technical Customer Service personnel will assist the Registrars during their implementation and operation of the Espresso EPP schema. The Information Security Officer will ensure that all security policies and procedures are followed during the development, implementation, and daily use of the Espresso EPP functionality.

The technical resources required to manage the EPP are adequate, on hand or committed, and⁄or readily available. We have contracted with Cybercoders of Los Angeles for staff resources. Their analysis of the industry indicates that resourcing for the technical functions of the registry will be fully possible in years 1, 2, or 3 of operations.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 5% 5% 5% 5%
Developer 1 30% 30% 30% 30%
Developer 2 -- -- 30% 30%
Developer 3 -- -- -- 30%
Database Dev 1 5% 5% 5% 5%
Database Dev 2 -- -- -- 5%
Database Admin 1 -- 5% 5% 5%
Database Admin 2 -- -- -- 5%
Cust Serv Tech 1 3% 3% 3% 3%
Cust Serv Tech 2 -- -- 3% 3%
ISO 1% 1% 1% 1%
gTLDFull Legal NameE-mail suffixDetail
.spaTop Level Domain Holdings Limitedgmail.comView
The registry will make use of Espresso, a proprietary fork of the CoCCA SRS, which for many years has utilized an EPP API for the Registrar interface. The Registry System’s early adoption and implementation of EPP ensures that all EPP-enabled registrars will be able to easily ʺspeakʺ to the EPP enabled registry. This standardization minimizes development efforts and ensures regularity for registry transactions. The Espresso EPP implementation adheres strictly to ICANN and IETF standards, and was written according to and is fully compliant with the EPP standards as defined in the following RFCs listed below in RFCs Governing EPP Standards:

5730: Extensible Provisioning Protocol (EPP)
5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping
5732: Extensible Provisioning Protocol (EPP) Host Mapping
5733: Extensible Provisioning Protocol (EPP) Contact Mapping
3735: Extensible Provisioning Protocol (EPP) Transport over TCP

The Espresso Registry EPP provides the four basic service elements as defined in RFC 5730: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

The EPP tool used for the registry interface is compliant with IETF RFC standards, is extensible, scalable, fault-tolerant, configurable, secure, and fully auditable.

Espresso’s EPP templates and schemas match the relevant RFCs. The following is a snapshot of EPP schema used by registrars during a one-hour period. More than 30 top-level domains and over 250 registrars are already using CoCCA Tools, the EPP-based ccTLD system Espresso is based on. The registry system is already fully established, validated, and used daily in existing TLDs. When we launch .SPA, contracted registrars will be provided immediate access and will be able to offer the TLD to their established customer bases as soon as they connect to the registry system. OTE is needed at all times for new registrars to test connectivity, and for old registrars to test new functions.

The Espresso Registry EPP component is EPP 1.0 and has all standard extensions. All the EPP Schemas and Templates that are utilized in Espresso are defined in the EPP RFCs listed above.

The Espresso EPP schema follow the IETF standardized EPP format. Please refer to “REQUEST, RESPONSEʺ in attachment “Q 25 EPP Sample Schemas” for an example of the REQUEST, RESPONSE.

Espresso supports the standard EPP schema including: login, logout, check, info, poll, transfer, create, delete, renew, transfer, update.

Please refer to “Live EPP Schema and Requestsʺ in attachment “Q 25 EPP Sample Schemas” examples showing live EPP schema and requests sent from registrars in the past. They are provided to fulfill the request for sample EPP schema demonstrating the ability to support EPP.

The secondary mode of interface offered to registrars is a secure web administration portal known as the graphic user interface (GUI). This web interface is accessible from any security-enabled browser connected to the Internet, allowing registrars to log into their accounts and manually manage domain portfolios on behalf of their customers. The web interface enables user-friendly registry system administration, TLD management, and registrar portfolio viewing. Registrars may register, renew, transfer, delete, and perform every domain management function. Offering a web interface allows administrative and finance, and customer service users to easily access the full functionality of the registry system. This extended functionality eases use, supports system clients, and expands market reach.

--EXTENSIONS--
In addition to the EPP operations detailed in RFCs 5730 - 5734, the Espresso Registry adds three extensions compliant with the extension framework described in RFC 5730. The additional functionality includes: a redemption grace period, an Intellectual Property verification mechanism, and the ability to provide contact proxies for display in Whois results. Please refer to “EPP Greeting Response Reportsʺ in attachment “Q 25 EPP Sample Schemas” for the EPP greeting response reports the extensions.


Espresso’s EPP extensions are made possible by the extension framework established in the EPP protocol. The framework provides for extensions at all of the protocol, object, and command-response levels, but Espresso has made extensions at only the command-response level. All of Espresso’s extensions relate to existing query or transform protocol commands. The specifics of each extension and the commands they relate to are described in the relevant extension sections that follow.

Espresso’s extensions have been made to query and transform commands and responses as categorized in RFC 5730. The set of query commands is: check, info, poll, and transfer. The set of transform commands is: create, delete, renew, transfer, and update. The specific commands from these sets that apply to each extension will be explicitly stated.

--REDEMPTION GRACE PERIOD (RGP)--
The redemption grace period extension is an extension of the EPP Domain mapping, and is a direct implementation of RFC 3915. Its purpose is to allow a grace period during which a registrar can reverse an action performed against a domain object and receive a refund for the original action. For instance, a registrar can renew a domain, then decide the renewal was a mistake and, by requesting that the domain be “restored” to its previous state, receive a refund. The refund and overall ability to restore a domain is contingent on the registrar exercising the restore request during the grace period. A domain’s state can be restored following any of the transform actions that typically incur a fee or result in a status change: registration, renewal, automated renewal, transfer, and delete. The redemption grace period extension is consistent with the registration life cycle as described in Question 27.

The RGP extension extends the domain info command’s response and the domain update command.

The domain info response extension simply tells the state that the domain is in with regard to the grace period by including the element rgpStatus. Please refer to “Extension Element from an Example Response for the info Commandʺ in attachment “Q 25 EPP Sample Schemas” for the extension element from an example response for the info command run on a domain that was recently registered.

The domain update command extension instructs the registry to restore a domain by including a restore element. The restore element can contain an optional report element. Until a report has been filed via EPP or the Registry’s web interface, the restore request will remain in a pending state and will not be completed.

An important requirement is that the update request must contain an empty domain:chg, domain:rem, or domain:add element within the standard domain:update element.

Please refer to “Domain Update Command (Report Not Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain but does not include a report.

Please refer to “Domain Update Command (Report Included)ʺ in attachment “Q 25 EPP Sample Schemas” for an example domain update command that requests a restore of the domain and includes the report.

Please refer to “Domain Name Extension Schema for Registry Grace Period Processingʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--INTELLECTUAL PROPERTY (IP) VERIFICATION--
The Espresso Registry adds an extension to support IP verification via the Trademark Clearing House (TMCH) verification.

Using TMCH verification, a client can receive automated, realtime pre-approval for a domain. This is especially helpful during the sunrise and landrush periods as the domain is registered immediately upon TMCH validation rather than going through the application process. When TMCH validation fails, the domain is given statuses pendingCreate and serverHold, thereby preventing the domain from being published to the zone files. The domain validation is then retried through the Registryʹs admin interface. A notification is sent to the administrator that a domain is pending approval. If an audit of the request proves legitimate, the domain is then published to the zone.

When a registrar includes a TMCH code in the registration request, TMCH validation is performed first against the domain, then against the registrant. If the Registry chooses to not use TMCH verification, registrars will receive an explanatory error in response to the domain:create command.

The IP verification extension extends only the domain:create command. The registrar adds the TMCH element to the extension section.

Please refer to “Example of the domain:create Extension Element with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with TMCH information.

Please refer to “Example of the domain:create Extension Element with Trademark Informationʺ in attachment “Q 25 EPP Sample Schemas” for an example of the domain:create extension element with trademark information.

Please refer to “Formal Syntax for the domain:create Extension with TMCH Informationʺ in attachment “Q 25 EPP Sample Schemas” for the formal syntax for the extension.

--WHOIS CONTACT PROXIES--
The proxy extension provides a framework for registrars to establish a full set of information to be provided in Whois responses while maintaining domain contacts’ privacy and still supplying the registry with the required contact related information. The registrar is able to create a contact proxy with similar data elements to those supplied when creating a typical contact. Once created, a proxy can be assigned to any contact controlled by the registrar. For contacts that have been assigned a proxy, Whois responses display the information from the proxy rather than the information for the actual contact.

The contact:create command and contact:create response were extended to facilitate contact proxies via EPP. A registrar may add an extension element that contains the structure to either create a new proxy or assign an existing proxy to the contact. The response to the contact:create command will contain the reference value for the proxy.

All proxies are identified by a reference. The reference can be provided during creation or is otherwise assigned by the Registry. When a proxy already exists, a registrar provides the existingProxy element which contains a reference element. The proxy identified by this reference will be assigned to the contact that is created as a result of the contact:create command.

Creating and updating a proxy is done by providing the newProxy element rather than the existingProxy element. The newProxy element contains a proxyDetails element as a container for the information necessary to create a proxy. The proxyDetails optionally contains a proxy:reference element. If the proxy:reference element matches an existing proxy, the existing proxy will be updated with the proxy details provided, otherwise a new proxy is created. When the proxy:reference element is not included, a reference value is assigned by the Registry.

The EPP aspect of the contact proxies is limited in scope. Only the contact:create command and contact:create command response were extended for contact proxies. The functional gaps in the EPP extension are adequately covered by Espresso’s GUI, described above. From the GUI a registrar can assign a proxy to an existing contact, unassign a proxy from a contact, create, update, and delete a proxy.

Please refer to “Example of the Extension Element Creating a New Contact Proxyʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when creating a new contact proxy.

Please refer to “Example of the Extension Element Assigning an Existing Contact Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension element when assigning an existing contact proxy to a contact.

Please refer to “Example of the Extension Section in a Response to a contact:create Command that Assigned a Proxy to a Contactʺ in attachment “Q 25 EPP Sample Schemas” for an example of the extension section in a response to a contact:create command that assigned a proxy to a contact.

Please refer to “Formal Syntax for the Contact Proxy Extensionʺ in attachment “Q 25 EPP Sample Schemas” for formal syntax for the contact proxy extension.

--EPP PERSONNEL RESOURCES--
The number and type of personnel from Minds + Machines, our registry service provider, allocated to the implementation and maintenance of the EPP interface will vary depending on the stage of registry operations. Since the core registry system is already built, operational, and interfaces daily with registrars, the initial number of personnel allocated to EPP development will be limited to the man-hours required to create and fulfill any outstanding requirements, such as connecting to the Trademark Clearinghouse. Most ICANN-accredited registrars have already passed the OTE and are actively interfacing with Espresso on a daily basis for a TLD that is currently in operation. The Espresso Application Developers will actively keep the EPP extensions and connections up to date with relevant RFCs. The number of developers will scale accordingly as new requirements or functions are introduced, and new registrars that require assistance contract with the registry and require assistance passing the OTE.

The developers will collaborate with the Database Developers and Database Administrators to keep the EPP schema and Espresso platform up to date and in compliance with the relevant RFCs (as detailed in the introduction to Question 25: EPP). The Registrar Technical Customer Service personnel will assist the Registrars during their implementation and operation of the Espresso EPP schema. The Information Security Officer will ensure that all security policies and procedures are followed during the development, implementation, and daily use of the Espresso EPP functionality.

The technical resources required to manage the EPP are adequate, on hand or committed, and⁄or readily available. We have contracted with Cybercoders of Los Angeles for staff resources. Their analysis of the industry indicates that resourcing for the technical functions of the registry will be fully possible in years 1, 2, or 3 of operations.

Our registry functions are outsourced to Minds + Machines. Their staff resource allocation follows. All costs associated with the technical functioning of the registry are covered by Minds + Machines as per our contract with them. Please see the attachment to “Q 24 Staff” for complete descriptions of each staff position.

Title Startup Yr1 Yr2 Yr3
----- ------- --- --- ---
CTO 5% 5% 5% 5%
Developer 1 30% 30% 30% 30%
Developer 2 -- -- 30% 30%
Developer 3 -- -- -- 30%
Database Dev 1 5% 5% 5% 5%
Database Dev 2 -- -- -- 5%
Database Admin 1 -- 5% 5% 5%
Database Admin 2 -- -- -- 5%
Cust Serv Tech 1 3% 3% 3% 3%
Cust Serv Tech 2 -- -- 3% 3%
ISO 1% 1% 1% 1%