Domain Block Mapping for the Extensible Provisioning Protocol (EPP)
draft-ar-block-domain-epp-mapping-01

Abstract

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of blocks.

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 September 2, 2015.

Table of Contents

1.  Introduction
    1.1.  Conventions Used in This Document
2.  Object Attributes
    2.1.  id
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.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
§  Authors' Addresses

1.  Introduction

Registry operators MAY offer clients the ability to request blocking of the registration of a domain name on behalf of a registrant whose intention is to not activate the domain name in DNS as a alternative to a defensive domain name registration. Although a block and defensive registration may be similar in some ways as they prevent the registration of a specific domain name, the concept of a block differs greatly as a block does not have an option to be activated in DNS, e.g. name servers cannot be assigned. Given this, a block MAY be priced lower than a domain name registration as there is no obligation from the registry operator to provide a resolution service for the domain name.

This extension provides a mechanism for clients to provision and manage blocks which includes the registration, renewal, deletion and info of a block. A registry operator SHOULD define the price of blocks and SHOULD provide an out of band mechanism to allocate a block resulting in a domain name registration if required.

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].

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

A block for domain name results in a object that is similar to a domain name as described in EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].. Those new elements, belonging exclusively to a block are described here.

2.1.  id

Servers may allow multiple blocks for the same domain names and in order for the server and client to uniquely identify and manage (renew, delete and info) a block, a client MUST provide a unique identifier (id) for block on registration. Clients MUST ensure that commands to query or transform a block includes the block identifier associated with the original <create> command.

Block identifiers SHOULD NOT be composed of characters that cannot be represented in US-ASCII. Servers SHOULD treat identifiers in case insensitive manner and disallow an identifier that only differs in casing compared to an existing identifier.

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),” August 2009.) [RFC5730]. The command mappings described here are specifically for use in provisioning blocks.

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 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].

To enable clients to view a block the <domain:info> is extended with a <block:info> element. If the querying client is not the sponsoring client the server SHOULD not provide the details of the block. The <block:info> element contains the following child element:

• A <id> that represents the block identifier assigned to the block by the creating client.

Example <info> request

<?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>block.tld</name>
      </info>
    </info>
    <extension>
      <info xmlns="urn:ar:params:xml:ns:block-1.0">
        <id>BLK-1</id>
      </info>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When a <domain:info> command containing the <block:info> element has been processed successfully, the server MUST respond with the <domain:infData> element described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. and also include a <block:infData> element that contains one <block:id> element.

Example <info> response:

<?xml version="1.0" encoding="UTF-8" ?>
<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>block.tld</name>
            <roid>B0000003-AR</roid>
            <registrant>R123</registrant>
            <clID>Registrar</clID>
            <crDate>2015-02-09T15:44:58.0Z</crDate>
            <exDate>2016-02-09T15:44:58.0Z</exDate>
         </infData>
      </resData>
      <extension>
         <infData xmlns="urn:ar:params:xml:ns:block-1.0">
            <id>BLK-1</id>
         </infData>
      </extension>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
      </trID>
   </response>
</epp>

An EPP error response MUST be returned if a <domain:info> command containing the <block:info> element cannot be processed for any reason.

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

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

To facilitate the registration of a block the <domain:create> command is extended with a <block:create> element, which signals a clients request to register a block. Because a block shares similarities with a domain name, the server SHOULD require the client to provide the identifier of a contact object to assign as the registrant of the block and the domain name that the client wishes to block from registration. The <block:create> element contains the following child elements:

• A <id> element that contains a unique client assigned identifier for the block.

Example <create> request:

<?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>block.tld</name>
        <period unit="y">2</period>
        <registrant>jd1234</registrant>
        <authInfo><pw></pw></authInfo>
      </create>
    </create>
    <extension>
      <create xmlns="urn:ar:params:xml:ns:block-1.0">
        <id>BLK-1</id>
      </create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When a <domain:create> command containing the <block:create> element has been processed successfully, the server MUST respond with the <domain:creData> element described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. and a <block:creData> element that contains one <block:id> element.

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>block.tld</name>
            <crDate>2015-01-01T22:00:00.0Z</crDate>
            <exDate>2017-01-01T22:00:00.0Z</exDate>
         <creData>
      </resData>
      <extension>
         <creData xmlns="urn:ar:params:xml:ns:block-1.0">
            <id>BLK-1</id>
         </creData>
      </extension>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
      </trID>
   </response>
</epp>

An EPP error response MUST be returned if a <domain:create> command containing the <block:create> element cannot be processed for any reason.

3.2.2.  EPP <delete> Command

This extension defines additional elements to extend the EPP <delete> 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].

To facilitate the deletion of a block the <domain:delete> command is extended with a <block:delete> element, which signals a clients request to delete a sponsored block. The server SHOULD require the client to provide the domain name and its block id. The <block:delete> element contains the following child elements:

• A <id> element that contains the client assigned identifier for the block for the corresponding domain name.

Example <delete> request:

<?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>block.tld</name>
        </delete>
    </delete>
    <extension>
      <delete xmlns="urn:ar:params:xml:ns:block-1.0">
        <id>BLK-1</id>
      </delete>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When a <domain:delete> command containing the <block:delete> element has been processed successfully, the server MUST respond with an EPP response with no <resData> element. An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.

3.2.3.  EPP <renew> Command

This extension defines additional elements to extend the EPP <renew> 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].

To facilitate the renewal of a block the <domain:renew> command is extended with a <block:renew> element, which signals a clients request to renew a sponsored block. The server SHOULD require the client to provide the domain name and its block id. The <block:renew> element contains the following child elements:

• A <id> element that contains a the client assigned identifier for the block for the corresponding domain name.

Example <renew> request:

<?xml version="1.0" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <renew>
        <renew xmlns="urn:ietf:params:xml:ns:domain-1.0">
            <name>block.tld</name>
            <curExpDate>2015-01-01</curExpDate>
            <period unit="y">5</period>
        </renew>
    </renew>
    <extension>
      <renew xmlns="urn:ar:params:xml:ns:block-1.0">
        <id>BLK-1</id>
      </renew>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

When a <domain:renew> command containing the <block:renew> element has been processed successfully, the server MUST respond with the <domain:renData> element described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. and a <block:renData> element that contains one <block:id> element.

Example <renew> 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>
         <renData xmlns="urn:ietf:params:xml:ns:domain-1.0">
            <name>block.tld</name>
            <exDate>2020-01-01T22:00:00.0Z</exDate>
         <renData>
      </resData>
      <extension>
         <renData xmlns="urn:ar:params:xml:ns:block-1.0">
            <id>BLK-1</id>
         </renData>
      </extension>
      <trID>
         <clTRID>ABC-12345</clTRID>
         <svTRID>54322-XYZ</svTRID>
      </trID>
   </response>
</epp>

An EPP error response MUST be returned if a <domain:renew> command containing the <block:renew> element cannot be processed for any reason.

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 does not define any extension to the EPP <update> command or response described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731].

4.  Formal Syntax

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ar:params:xml:ns:block-1.0"
      xmlns:block="urn:ar:params:xml:ns:block-1.0"
      xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
      xmlns="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified">

    <!--
        Import common element types.
    -->
    <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
    <import namespace="urn:ietf:params:xml:ns:domain-1.0" />

    <element name="create" type="block:createType"/>
    <element name="info" type="block:infoType"/>
    <element name="renew" type="block:renewType"/>
    <element name="delete" type="block:deleteType"/>

    <!--
        Type definitions.
    -->
    <complexType name="createType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <complexType name="infoType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <complexType name="deleteType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <!--
    Child elements of the <renew> command.
    -->
    <complexType name="renewType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <!--
     Child response elements.
     -->
    <element name="creData" type="block:creDataType"/>
    <element name="infData" type="block:infDataType"/>
    <element name="renData" type="block:renDataType"/>

    <!--
     <create> response elements.
     -->
    <complexType name="creDataType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <!--
     <info> response elements.
     -->
    <complexType name="infDataType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <!--
        <renew> response elements.
    -->
    <complexType name="renDataType">
        <sequence>
            <element name="id" type="eppcom:clIDType"/>
        </sequence>
    </complexType>

    <!--
        End of schema.
    -->
</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 apply to this specification as well.

6. Normative References

Authors' Addresses