Domain Name Application Extension Mapping for the Extensible Provisioning Protocol (EPP)
draft-ar-application-epp-mapping-02

Abstract

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of applications for domain names, suitable for periods such as a sunrise or landrush during which servers do not offer first-come first-served registrations.

Status of this Memo

This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on June 4, 2013.

Table of Contents

1.  Introduction
    1.1.  Conventions Used in This Document
2.  Object Attributes
    2.1.  Application Identifier
    2.2.  Phase Identifier
    2.3.  Status
    2.4.  Domain Attributes
3.  EPP Command Mapping
    3.1.  EPP Query Commands
        3.1.1.  EPP <check> Command
        3.1.2.  EPP <info> Command
        3.1.3.  EPP <transfer> Command
    3.2.  EPP Transform Commands
        3.2.1.  EPP <create> Command
            3.2.1.1.  Domain Application Create
            3.2.1.2.  Domain Application Allocate
        3.2.2.  EPP <delete> Command
        3.2.3.  EPP <renew> Command
        3.2.4.  EPP <transfer> Command
        3.2.5.  EPP <update> Command
4.  Formal Syntax
5.  Security Considerations
6.  Normative References
Appendix A.  Example Application Lifecycle
    A.1.  Simple Lifecycle
    A.2.  Complex Lifecycle
§  Authors' Addresses

1.  Introduction

The EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731] describes mechanisms for the provisioning and management of domain names. This works well for domain name registries that use a first-come first-served allocation method, however registries may define periods during which multiple applications for a domain name are accepted.

This extension describes the commands and responses used for the manipulation of domain name application objects. The authors recognise that additional information is often required to support applications for domain names, including but not limited to trademark information or proof of eligibility. This extension does not provide mechanisms for the collection of this information, instead other documents should be published that describe the mechanisms for transport and validation of supporting information.

Extension to the domain name mapping was preferred over re-defining the domain object fields in a domain name application object mapping. Implementers should be aware that this document places restrictions on the use of certain domain object attributes for the period during which the application is relevant.

1.1.  Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

"application-1.0" is used as an abbreviation for "urn:ar:params:xml:ns:application-1.0". The XML namespace prefix "app" is used, 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

An application for a domain name results in an object that is similar to the domain object as described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. Those new elements, belonging exclusively to the application, are described here, as well as the restrictions placed on the information available in the domain object.

2.1.  Application Identifier

Servers may allow multiple applications of a given domain name during relevant registry-specific phases. On receiving a request to create a domain name, the server creates an application object corresponding to the request, and assigns a unique application identifier. In order to facilitate correlation, all subsequent operations on the application object MUST be qualified by the previously assigned application identifier.

Servers MAY use both the application identifier and domain name to uniquely identify an application. Clients MUST ensure that commands to query or transform an application, include the domain name and application identifier associated with the original <create> command and response.

Application identifiers SHOULD NOT be composed of characters that cannot be represented in US-ASCII, and SHOULD NOT exceed the length of a ROID. Servers SHOULD NOT allocate application identifiers that differ only in the casing of the letters.

Clients MUST NOT assume any particular identifier syntax, and should be able to handle identifiers consisting of numbers, letters and punctuation.

2.2.  Phase Identifier

The server may support multiple rounds of applications, either sequentially or simultaneously, each with their own participation requirements.

Clients are expected to know the relevant phase identifier in use for a particular server. Out of band mechanisms should be used to determine the available phases and the requirements for submission of an application during those phases.

This document reserves the following two names for their specific uses. Registries SHOULD accept these values during the relevant phase to promote interoperability.

• sunrise - the phase where sunrise codes authorized by the trademark clearinghouse are used to prove eligibility. This refers to the least restrictive phase should two or more phases use sunrise codes from the trademark clearinghouse.
• landrush - the phase immediately prior to first-come first-served having no restrictions in addition to normal registration policies.

Phase identifiers SHOULD NOT be composed of characters that cannot be represented in US-ASCII, and SHOULD NOT exceed the length of a ROID. Servers SHOULD NOT allocate phase identifiers that differ only in the casing of the letters.

Clients MUST NOT assume any particular identifier syntax, and should be able to handle identifiers consisting of numbers, letters and punctuation.

2.3.  Status

All applications follow a predefined lifecycle as defined by the server. This extension does not attempt to define or restrict the application lifecycle, however servers are expected to use the status values described below when appropriate. In addition to application status descriptors, servers should use the server prohibition statuses in the domain object mapping to describe operations unavailable to the client, for example combining "serverUpdateProhibited" with "valid" to indicate that updates to the application will be rejected. Example server lifecycles are defined in Appendix A (Example Application Lifecycle), however these are provided for illustration only.

• applied - The default initial state of the application.
• pending - The phase in which the application was submitted is closed. The application might be awaiting non-mechanical validation or any other further action to move the application to the next state. Requests to update or delete the application should be rejected.
• contestedPendingResolution - The application is pending contention resolution. Requests to update or delete the application should be rejected.
• pendingAllocation - The application has been awarded to an applicant as is now pending allocation of the corresponding domain object. Requests to update or delete the application should be rejected.
• valid - The application meets validation requirements for the relevant phase. Updates to the application may be allowed by the server, however may attract further validation.
• invalid - The application does not met validation requirements for the relevant phase. Updates to the application may be allowed to provide clients the opportunity to correct invalid information.
• allocated - A terminal state indicating allocation of the application to the applicant.
• contestUnsuccessful - A terminal state indicating that the application did not pass contention resolution mechanism.
• unallocatedReleased - A terminal state indicating that the Registry Operator has decided to terminate the application and release the domain name to be available for registration and requested in applications.

2.4.  Domain Attributes

This document describes an extension to the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731], however overloads the domain attributes in commands and responses to represent information applicable to application objects. The list of attributes available in the core domain mapping is described below, with descriptions relevant to their role in applications.

• The <domain:name> element contains the fully qualified name of the domain applied for by this application object.
• The <domain:roid> element contains the Repository Object IDentifier assigned to the application object when the object was created.
• The <domain:status> element contains the current status descriptors associated with the application, to be used in conjunction with the <app:status> elements defined in this extension. Servers MAY additionally limit the statuses that can be set by the client, for example to prevent updates that would add the clientHold or clientTransferProhibited statuses.
• The <domain:registrant> element and <domain:contact> elements contain identifiers for the human or organizational social information objects associated with the application object.
• The <domain:ns> element contains the fully qualified names of the delegated host objects or host attributes (name servers) that should be associated with the domain object allocated from this application.
• The <domain:host> does not map to application objects and SHOULD NOT be used. Servers SHOULD deny the creation of host objects whose names are subordinate to application objects.
• The <domain:clID> element contains the identifier of the sponsoring client for the application.
• The <domain:crID> element contains the identifier of the client that created the application object.
• The <domain:crDate> element contains the date and time of application object creation.
• The <domain:exDate> element does not map to application objects and SHOULD NOT be used.
• The <domain:upID> element contains the identifier of the client that last updated the application object.
• The <domain:upDate> element contains the date and time of the most recent application-object modification.
• The <domain:trDate> element does not map to application objects and SHOULD NOT be used.

Servers may place restrictions on the domain attributes that can be used with applications. Clients should consult the server operator regarding the list of domain attributes available on the server.

3.  EPP Command Mapping

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. The command mappings described here are specifically for use in the Domain Name Application Extension.

3.1.  EPP Query Commands

EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.

3.1.1.  EPP <check> Command

This extension does not define any extension to the EPP <check> command or response described in the EPP EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

3.1.2.  EPP <info> Command

This extension defines additional elements to extend the EPP <info> command and response to be used in conjunction with the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

The EPP <info> command is used to retrieve information on an application for a domain name. The application identifier returned in the create response (EPP <create> Command) is used for retrieving information for a launch application. In addition to the elements expressed in the <domain:info>, the command is extended with an <app:info> element that contains the following child elements:

• id - the identifier of the application

Example <info> command for an application object Application

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <info>
      <info xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
      </info>
    </info>
    <extension>
      <info xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
      </info>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When an <info> command has been successfully processed, the <resData> element contains a <domain:infData> element, however with attribute values described in the Domain Attributes (Domain Attributes) section. In addition, the response is extended with an <app:infData> element containing the following child elements:

• One <id> element containing the application identifier.
• One <phase> element containing the phase in which the application is submitted.
• One or more <status> elements describing the status of the application.

Example <info> Response for an Application.

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <infData xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
        <roid>EXAMPLE1-REP</roid>
        <registrant>jd1234</registrant>
        <contact type="admin">sh8013</contact>
        <contact type="tech">sh8013</contact>
        <ns>
          <hostObj>ns1.example.com</hostObj>
          <hostObj>ns1.example.net</hostObj>
        </ns>
        <clID>ClientX</clID>
        <authInfo>
          <pw>2fooBAR</pw>
        </authInfo>
      </infData>
    </resData>
    <extension>
      <infData xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
        <phase>landrush</phase>
        <status s="pendingAllocation" />
      </infData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Servers MAY include the <app:infData> in response to a standard <domain:info> command on a domain object allocated from an application.

3.1.3.  EPP <transfer> Command

This extension does not define any extension to the EPP <transfer> command or response described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

3.2.  EPP Transform Commands

EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.

3.2.1.  EPP <create> Command

There are two forms of the extension to the EPP <create> command that are used to either create a domain application or allocate an application. Both forms are described below.

3.2.1.1.  Domain Application Create

The Domain Application Create is used to provision an application object within a repository. A domain name application may be provisioned by specifying the phase in which the application is to be processed.

In addition to the elements expressed in the <domain:create>, the command is extended with an <app:create> element containing the following child elements:

• phase: the identifier of the phase to which the domain name application is being submitted.

Example <create> command for an application for a domain name

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <create xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
        <ns>
          <hostObj>ns1.example.net</hostObj>
          <hostObj>ns2.example.net</hostObj>
        </ns>
        <registrant>jd1234</registrant>
        <contact type="admin">sh8013</contact>
        <contact type="tech">sh8013</contact>
        <authInfo>
          <pw>2fooBAR</pw>
        </authInfo>
      </create>
    </create>
    <extension>
      <create xmlns="urn:ar:params:xml:ns:application-1.0">
        <phase>landrush</phase>
      </create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When an application create command has been processed successfully, the response is extended with an <app:creData> element in addition to the <domain:creData> response described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. The <app:creData> element contains the following child elements:

• An <id> element that contains the server-assigned identifier for this application.
• A <phase> element that contains the phase in which the application was submitted.

Example <create> response

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <creData xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
        <crDate>1999-04-03T22:00:00.0Z</crDate>
      </creData>
    </resData>
    <extension>
      <creData xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
        <phase>landrush</phase>
      </creData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

3.2.1.2.  Domain Application Allocate

The Domain Application Allocate is used to register the domain object resulting from a successful domain application.

In addition to domain name and authInfo expressed in the <domain:create>, the command is extended with an <app:create> element containing the following child element:

• An <id> element that contains the identifier of the application to allocate.

Example <create> command for allocation of an application

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <create xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
        <authInfo>
          <pw>2fooBAR</pw>
        </authInfo>
      </create>
    </create>
    <extension>
      <create xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
      </create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When an application allocate command has been processed successfully, a domain create response will be returned.

3.2.2.  EPP <delete> Command

This extension defines additional elements for the EPP <delete> command described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. No additional elements are defined for the EPP <delete> response.

The delete command is extended to allow for the deletion of an application. In addition to the elements expressed in the <domain:delete>, the command is extended with a <app:delete> element that contains the following child elements:

• id: the identifier of application to be deleted.

Example <delete> command to delete an application

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <delete>
      <delete xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
      </delete>
    </delete>
    <extension>
      <delete xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
      </delete>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

3.2.3.  EPP <renew> Command

This extension does not define any extension to the EPP <renew> command or response described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

3.2.4.  EPP <transfer> Command

This extension does not define any extension to the EPP <transfer> command or response described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

3.2.5.  EPP <update> Command

This extension defines additional elements for the EPP <update> command described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. No additional elements are defined for the EPP <update> response.

The update command is extended to allow for the modification of an application. In addition to the elements expressed in the <domain:update>, the command is extended with an <app:update> element that contains the following child elements:

• id: the identifier of application to be updated.

Example <update> command to change the registrant of the applied for domain object

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <update xmlns="urn:ietf:params:xml:ns:domain-1.0">
        <name>example.tld</name>
        <chg>
          <registrant>jd1234</registrant>
        </chg>
      </update>
    </update>
    <extension>
      <update xmlns="urn:ar:params:xml:ns:application-1.0">
        <id>3F2504E0-4F89-11D3-9A0C-0305E82C3301</id>
      </update>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

4.  Formal Syntax

An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping, suitable for automated validation of EPP XML instances.

<?xml version="1.0" standalone="no"?>
<schema targetNamespace="urn:ar:params:xml:ns:application-1.0"
  xmlns:app="urn:ar:params:xml:ns:application-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">

  <!-- Child elements found in EPP commands. -->
    <element name="create" type="app:phaseOrIdType" />
    <element name="delete" type="app:idType" />
    <element name="info" type="app:idType" />
    <element name="update" type="app:idType" />

  <complexType name="phaseOrIdType">
    <choice>
      <element name="phase" type="app:phaseValueType" />
      <element name="id" type="app:idValueType" />
    </choice>
  </complexType>

  <simpleType name="phaseValueType">
    <restriction base="token">
      <minLength value="1" />
    </restriction>
  </simpleType>

  <complexType name="idType">
    <sequence>
      <element name="id" type="app:idValueType" />
    </sequence>
  </complexType>

  <simpleType name="idValueType">
    <restriction base="token">
      <minLength value="1" />
    </restriction>
  </simpleType>

  <!-- Child elements found in EPP responses. -->
  <element name="creData" type="app:creDataType" />
  <element name="infData" type="app:infDataType" />

  <complexType name="creDataType">
    <sequence>
      <element name="id" type="app:idValueType" />
      <element name="phase" type="app:phaseValueType" />
    </sequence>
  </complexType>

  <complexType name="infDataType">
    <sequence>
      <element name="id" type="app:idValueType" />
      <element name="phase" type="app:phaseValueType" />
      <element name="status" type="app:statusType"
           maxOccurs="unbounded" />
    </sequence>
  </complexType>

  <complexType name="statusType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="s" type="token" use="required" />
      </extension>
    </simpleContent>
  </complexType>

</schema>

5.  Security Considerations

The mapping extensions described in this document do not provide any security services beyond those described by EPP (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” August 2009.) [RFC5730], the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731], and protocol layers used by EPP. The security considerations described in these other specifications also apply to this specification.

Updates to and deletion of an application object, must be restricted to clients authorized to perform the said operation on the object.

Because 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 2303 (object does not exist) or an appropriate authorization error. Server policy may allow <info> operation with filtered output by clients other than the sponsoring client, in which case the <domain:infData> and <application:infData> response SHOULD be filtered to include only fields that are publicly accessible.

6. Normative References

Appendix A.  Example Application Lifecycle

Two example application lifecycles are illustrated below. Servers are free to determine the lifecycle that best suits their requirements, however may derive inspiration from the following examples.

A.1.  Simple Lifecycle

The following diagram illustrates a simple application phase where multiple applications are accepted and allocation is performed by the server.

                +---------+
                | applied |
                +---------+
                     |
      +--------------+---------------+
      |                              |
      |                              V
      |                +----------------------------+
      +----------------| contestedPendingResolution |
      |                +----------------------------+
      |                              |
      V                              V
+-----------+              +---------------------+
| allocated |              | contestUnsuccessful |
+-----------+              +---------------------+

A.2.  Complex Lifecycle

The following diagram illustrates most status elements defined in this document. In this example, the server periodically validates all applications during the application phase, allowing modification of invalid applications to enable clients to correct mistakes. At the end of the phase the server resolves contention for domain names with more than one valid application. Applications that are successful in contention resolution are ready for allocation, as well as those applications for which there was only one valid application.

                              +---------+
                +------------>| applied |
                |             +---------+
                |                  |
                |                  V
                |        +-------------------+
                |        |      pending      |
                |        +-------------------+
                |                  |
                |        +---------+---------+
                |        |                   |
                |        V                   V
                |   +---------+          +-------+
                +---| invalid |          | valid |
                    +---------+          +-------+
                         |                   |
           +-------------)-------------------+
           |             |                   |
           V             |                   V
+-------------------+    |    +----------------------------+
| pendingAllocation |<---)----| contestedPendingResolution |---+
+-------------------+    |    +----------------------------+   |
           |             |                                     |
           |             |                                     |
           |             |                                     |
           V             |                                     |
     +-----------+       |        +---------------------+      |
     | allocated |       +------->| contestUnsuccessful |<-----+
     +-----------+                +---------------------+

Authors' Addresses