EPP-Internationalized Domain Name Mapping Extension


This document describes an Extensible Configuration Protocol (EPP) extension mapping for the configuration of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional functions required for domain name registration in character sets other than ASCII.

1 Introduction

The EPP protocol provides a complete description of the EPP command and response structure. A thorough understanding of the basic protocol specification is necessary to understand the mapping described in this document.

This document is based on the guidelines for extending the extensible supply agreement defined in [RFC3735].

In order to comply with the guidelines for implementing internationalized domain names [1], each label to be registered needs to be associated with a single script, which is defined by the code division of the Unicode code diagram. This requirement poses challenges to registries that use the EPP protocol, because currently there is no such field in the domain name mapping to allow the exchange of this information.

In addition, registries that intend to comply with the recommendations of Section 4.1 of the IDNA2008 protocol [RFC5891] will be able to use this extension to verify names in ASCII-compatible encoding and Unicode format.

This extension adds two additional data elements to the EPP domain name mapping to allow associating domain names with IDN table identifiers and associating domain names with C (NFC[2]) in Unicode canonical form.

2. Conventions used in this document

"Idn-1.0" is the abbreviation of "urn:ietf:params:xml:ns:idn-1.0". Use the XML namespace prefix "idn", but the implementation must not rely on it, but use appropriate namespace-supported XML parsers and serializers to interpret and output XML documents.

3. EPP command mapping

A detailed description of EPP syntax and semantics can be found in [RFC5730].

3.1. EPP query command

This extension does not add any elements to the EPP<check>, <poll>, or <transfer> command or response.

3.1.1 EPP <info> command

When the extension is selected in the <login> command, the extension does not add any elements to the EPP <info> command, but contains elements in the response.

EPP <info> command example:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <info>
   C:      <domain:info
   C:          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>xn--espaol-zwa.example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw>2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:info>
   C:    </info>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When the info command is successfully processed and the domain name is IDN, the server must include an <IDN:data> element in the EPP response part, which contains the following elements:

  • <idn:table>: contains IDN table identification
  • <idn:uname>: contains the domain name in Unicode NFC format

Example of response from authorized client <info>:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      <domain:infData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>xn--espaol-zwa.example.com</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="ok"/>
   S:        <domain:registrant>jd1234</domain:registrant>
   S:        <domain:contact type="admin">sh8013</domain:contact>
   S:        <domain:contact type="tech">sh8013</domain:contact>
   S:        <domain:ns>
   S:          <domain:hostObj>ns1.example.com</domain:hostObj>
   S:          <domain:hostObj>ns1.example.net</domain:hostObj>
   S:        </domain:ns>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:crID>ClientY</domain:crID>
   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:upID>ClientX</domain:upID>
   S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
   S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
   S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
   S:        <domain:authInfo>
   S:          <domain:pw>2fooBAR</domain:pw>
   S:        </domain:authInfo>
   S:      </domain:infData>
   S:    </resData>
   S:    <extension>
   S:      <idn:data xmlns:idn="urn:ietf:params:xml:ns:idn-1.0">
   S:        <idn:table>es</idn:table>
   S:        <idn:uname>espa&#xF1;ol.example.com</idn:uname>
   S:      </idn:data>
   S:    </extension>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

3.2. EPP transfer command

This extension does not add any elements to the EPP<delete>, <renew>, or <transfer> command or response.

3.2.1. EPP<create> command

This extension defines additional element commands for EPP.

If the domain name is an IDN, the EPP command must include an <extension> element, which must include the sub-element <IDN:data>, which must include the following sub-elements:

  • <idn:table>: contains the IDN table identifier provided by the server
  • <idn:uname>: contains the domain name registered in Unicode NFC format (this item is optional)

Examples of <create> commands:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C: <command>
   C:   <create>
   C:     <domain:create
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:     <domain:name>xn--espaol-zwa.example.com</domain:name>
   C:     <domain:period unit="y">2</domain:period>
   C:     <domain:ns>
   C:       <domain:hostObj>ns1.example.net</domain:hostObj>
   C:       <domain:hostObj>ns2.example.net</domain:hostObj>
   C:     </domain:ns>
   C:     <domain:registrant>jd1234</domain:registrant>
   C:     <domain:contact type="admin">sh8013</domain:contact>
   C:     <domain:contact type="tech">sh8013</domain:contact>
   C:     <domain:authInfo>
   C:       <domain:pw>2fooBAR</domain:pw>
   C:     </domain:authInfo>
   C:     </domain:create>
   C:   </create>
   C:   <extension>
   C:   <idn:data xmlns:idn="urn:ietf:params:xml:ns:idn-1.0">
   C:     <idn:table>es</idn:table>
   C:     <idn:uname>espa&#xF1;ol.example.com</idn:uname>
   C:   </idn:data>
   C:   </extension>
   C:   <clTRID>123456</clTRID>
   C: </command>
   C:</epp>

The server must use the process described in [RFC5891] section 4.2 to verify the name.

If the IDN name verification fails because it contains a code point that is not available in the specified IDN table, the server must return an EPP error 2306.

The <domain:name> provided by Cleavage does not map to the provided <idn:uname>. The server must respond with an EPP error 2005.

3.3. Formal Grammar

The EPP object mapping is specified in the XML schema notation. The formal grammar provided here is a complete schema representation of object mapping, suitable for automatic verification of EPP XML instances.

   <?xml version="1.0" encoding="UTF-8"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
           xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
           xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
           targetNamespace="urn:ietf:params:xml:ns:idn-1.0"
           elementFormDefault="qualified">
     <annotation>
       <documentation>
         Extensible Provisioning Protocol v1.0 domain name extension
         schema for IDN Table selection.
       </documentation>
     </annotation>
     <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
             schemaLocation="eppcom-1.0.xsd"/>
     <!-- Child elements found in IDN -->
       <element name="data" type="idn:idnDataType"/>
         <complexType name="idnDataType">
           <sequence>
             <element name="table" type="eppcom:minTokenType"/>
             <element name="uname" type="eppcom:labelType"
                 minOccurs="0"/>
           </sequence>
         </complexType>
     <!-- End of schema. -->
   </schema>

Guess you like

Origin blog.csdn.net/u013617791/article/details/104533351