Skip to main content

Proprietary EPP Extensions

New gTLD Advisory
Advisory number: R1-A01-0025
Publication date: 21 December 2012

About this advisory: Based on evaluations performed to date, there are some areas that are generating a large number of clarifying questions. The intent of this advisory is to provide applicants with information to prepare in advance of receiving clarifying questions. We recommend that applicants take pro-active steps to address any relevant issues prior to receiving clarifying questions.

Disclaimer: ICANN issues this document to provide information that is intended to assist applicants with preparing in advance of receiving clarifying questions. It illustrates areas generating a large number of clarifying questions based on applications evaluated to date. It, in no way, represents a complete list of issues under which a clarifying question may be issued. This material is for information only and does not represent all requirements and criteria that the applicant must satisfy. ICANN is not providing legal, financial, business, or any other kind of advice. This material does not represent a modification to the Applicant Guidebook, or the terms and conditions of the new gTLD program. This material also does not represent a waiver of any ICANN policy, procedure or agreement.

Have questions regarding this material? Please contact New gTLD Customer Service at https://gtldapp.icann.org/vpn/index.html.

Relevant Applicant Guidebook reference

Question 25, second paragraph of the question text.

Clarification on the proprietary EPP extension requirement

If the use of proprietary EPP extensions is proposed, applicants must provide documentation for each proposed extension. RFC 3735 provides guidelines for the use of EPP's extension mechanisms to define new features and object management capabilities. It suggests the documentation format from Appendix A of RFC 5730 (originally RFC 3730, now obsolete), the base EPP RFC. The Appendix recommends the documentation include the following components:

  1. Introduction
  2. Object Attributes
  3. Sample commands and responses for the following categories of commands:
    1. Query commands
      1. Check
      2. Info
      3. Poll
      4. Transfer
    2. Transform commands
      1. Create
      2. Delete
      3. Renew
      4. Transfer
      5. Update
  4. Formal syntax

Applicants should particularly note the RFC guidance for formal syntax: the syntax must be defined by an XML schema that applicants must provide (the Appendix notes that an XML DTD does not provide sufficient support for XML namespaces and strong data typing.).

Applicants should be aware that schemas and examples of commands are, in fact, different things. An example of a schema, taken from an Internet Draft of an IDN language tag extension, is as follows:

<?xml version="1.0" encoding="UTF-8"?>
  <schema targetNamespace="urn:ietf:params:xml:ns:domain-1.0"
          xmlns:idn="urn:ietf:params:xml:ns:domain-1.0"
          xmlns="http://www.w3.org/2001/XMLSchema"
          elementFormDefault="qualified">
    <annotation>
      <documentation>
        Extensible Provisioning Protocol v1.0 domain name extension
        schema for IDN Language Tag.
      </documentation>
    </annotation>
    <!-- Child elements found in EPP commands.-->
    <element name="language" type="language"/>
    <!-- End of schema. -->
  </schema>

Please note the schema tag – this denotes a schema, as opposed to an example of an EPP command that would begin with an epp tag.

Again, documentation, including command examples and schemas, must be provided for each proposed proprietary EPP extension where they differ from, expand upon the data fields collected, or expand functionality from what is documented in the RFCs.