Internationalized Domain Name Extension Mapping for the Extensible Provisioning Protocol (EPP)
draft-ar-idn-epp-mapping-01

Abstract

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

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.  Language Tag
    2.2.  Domain and Host Names
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.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

1.  Introduction

Internationalized Domain Names in Applications provides a mechanism to convert a domain name expressed in Unicode to an ASCII-compatible encoding (ACE) form, to be compatible with existing applications and infrastructure.

Described in Guidelines for Implementation of IDNs (Internet Corporation for Assigned Names and Numbers, “Guidelines for the Implementation of Internationalized Domain Names,” 09 2011.) [IDN‑GUIDELINES], servers are encouraged to restrict registrations of Internationalized Domain Names to those from a single script or language. Lists of code points available for registration are published as an IDN table, each identified by a Language Tag. Servers using this extension collect the Language Tag from clients at the time of domain name registration, matching the domain name to the relevant IDN Table and rules for registration.

Readers are expected to be familiar with the IDNA protocol series as described in RFC5890 (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” August 2010.) [RFC5890]. Implementers should be familiar with RFCs: RFC5890 (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” August 2010.) [RFC5890], RFC5891 (Klensin, J., “Internationalized Domain Names in Applications (IDNA): Protocol,” August 2010.) [RFC5891], RFC5892 (Faltstrom, P., “The Unicode Code Points and Internationalized Domain Names for Applications (IDNA),” August 2010.) [RFC5892], RFC5893 (Alvestrand, H. and C. Karp, “Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA),” August 2010.) [RFC5893], and RFC5894 (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale,” August 2010.) [RFC5894].

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

"idn-1.0" is used as an abbreviation for "urn:ar:params:xml:ns:idn-1.0". The XML namespace prefix "idn" is used, but implementations MUST NOT depend on it and instead must employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.

2.  Object Attributes

This extension adds additional elements to the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. Those new elements are described here, as well as restrictions placed on domain and host names used in EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731] and EPP Host Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host Mapping,” August 2009.) [RFC5732].

2.1.  Language Tag

The Language Tag is a identifier linking a domain object to a specific IDN table. Servers should allocate Language Tags that conform to the syntax expressed in Tags for Identifying Languages (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.) [RFC5646]. .

2.2.  Domain and Host Names

To promote interoperability, domain and host names exchanged between client and server MUST be expressed using A-labels and non-internationalized labels, unless negotiated using a mechanism outside the scope of this document. This restriction applies to all commands described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731] and EPP Host Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Host Mapping,” August 2009.) [RFC5732] and not only those commands extended by this document.

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 provisioning internationalized domain names.

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 does not add any elements to the EPP <info> command described in the EPP Domain Name Mapping (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” August 2009.) [RFC5731]. However, additional elements are defined for the <info> response.

To enable clients to determine the IDN table identifier associated with a doamin name, the <domain:infData> response is extended with an <idn:infData> element that contains the following child elements:

• A <languageTag> element containing the IDN table identifier for this domain name.

Example <info> response for an internationalized domain name.

<?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>xn--ls8h.example</name>
        <roid>EXAMPLE1-REP</roid>
        <status s="ok" />
        <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>
        <host>ns1.example.com</host>
        <host>ns2.example.com</host>
        <clID>ClientX</clID>
        <crID>ClientY</crID>
        <crDate>1999-04-03T22:00:00.0Z</crDate>
        <upID>ClientX</upID>
        <upDate>1999-12-03T09:00:00.0Z</upDate>
        <exDate>2005-04-03T22:00:00.0Z</exDate>
        <trDate>2000-04-08T09:00:00.0Z</trDate>
        <authInfo>
          <pw>2fooBAR</pw>
        </authInfo>
      </infData>
    </resData>
    <extension>
      <infData xmlns="urn:ar:params:xml:ns:idn-1.0">
        <languageTag>und-Zyyy</languageTag>
      </infData>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Servers, whose business rules are not altered by the use of particular IDN tables, MAY not support this extension to the <info> response. Additionally, servers MAY restrict the information returned to clients that have not provided correct authorization information.

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 for the EPP <create> 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 <create> response.

To enable clients to create internationalized domain names, the <domain:create> command is extended with an <idn:create> element that contains the following child elements:

• A <languageTag> element containing the IDN table identifier relevant for the registration of the domain name.

Example <create> Command for an Internationalized 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>xn--ls8h.example</name>
        <period unit="y">2</period>
        <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:idn-1.0">
        <languageTag>und-Zyyy</languageTag>
      </create>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

3.2.2.  EPP <delete> Command

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

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 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" standalone="no" ?>
<schema targetNamespace="urn:ar:params:xml:ns:idn-1.0"
  xmlns:idn="urn:ar:params:xml:ns:idn-1.0"
  xmlns="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">

  <annotation>
    <documentation>
      Internationalized Domain Name Extensions to the
      Extensible Provisioning Protocol.
    </documentation>
  </annotation>

  <element name="create" type="idn:languageTagType" />

  <complexType name="languageTagType">
    <sequence>
      <element name="languageTag" type="language" />
    </sequence>
  </complexType>

  <element name="infData" type="idn:languageTagType" />

</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.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses