Skip to main content
  • Registry

CIRA IDN-1.0 EPP Extension

CIRA IDN Mapping Extension (idn-1.0) — EPP

Namespace: urn:ietf:params:xml:ns:idn-1.0

1. Introduction

This document describes the Canadian Internet Registration Authority (CIRA)’s implementation of an Extensible Provisioning Protocol (EPP) extension for provisioning Internationalized Domain Names (IDNs). The implementation follows the now-expired Internet-Draft “Internationalized Domain Name Mapping Extension for EPP” (draft-ietf-eppext-idnmap-02), widely adopted by registries for IDN support. The extension uses the XML namespace urn:ietf:params:xml:ns:idn-1.0 and extends the EPP domain mapping to support registering domain names in character sets other than ASCII.

2. Conventions Used in This Document

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in RFC 2119. XML is case-sensitive. Unless stated otherwise, element and attribute names and examples MUST be interpreted exactly as shown.

“idn-1.0” refers to the namespace urn:ietf:params:xml:ns:idn-1.0. The prefix idn is used in examples, but implementations MUST NOT depend on any specific prefix; use a namespace-aware XML parser/serializer.

3. EPP Command Mapping

A detailed description of EPP syntax and semantics is provided in the base protocol and the domain name mapping.

3.1. EPP Query Commands

This extension does not add elements to EPP <check>, <poll>, or <transfer> commands or their responses.

3.1.1. EPP <info> Command

The extension does not add elements to the <info> command itself, but when selected during <login> and the queried name is an IDN, the server includes an <extension> element containing <idn:data> with:

  • <idn:table> — IDN table identifier.
  • OPTIONAL <idn:uname> — the domain name in Unicode Normalization Form C (NFC).

Example <info> command:

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 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>xn--r-wfan6a.fury</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>

Example <info> response:

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 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>xn--r-wfan6a.fury</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>tf1234</domain:registrant>
S:        <domain:contact type="admin">cf8013</domain:contact>
S:        <domain:contact type="tech">pp8013</domain:contact>
S:        <domain:ns>
S:          <domain:hostObj>ns1.example.ca</domain:hostObj>
S:          <domain:hostObj>ns1.example.nl</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: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>fr</idn:table>
S:        <idn:uname>çïrâ.fury</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 Transform Commands

This extension does not add elements to EPP <delete>, <renew>, or <transfer> commands or their responses.

3.2.1. EPP <create> Command

If the domain name is an IDN, the client MUST include an <extension> element with <idn:data> containing:

  • <idn:table> — IDN table identifier (as provided by the server).
  • OPTIONAL <idn:uname> — the domain’s Unicode (NFC) form.

Example <create> command:

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 xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>xn--r-wfan6a.fury</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:ns>
C:          <domain:hostObj>ns1.example.ca</domain:hostObj>
C:          <domain:hostObj>ns2.example.nl</domain:hostObj>
C:        </domain:ns>
C:        <domain:registrant>ds832</domain:registrant>
C:        <domain:contact type="admin">tf8013</domain:contact>
C:        <domain:contact type="tech">df8013</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>fr</idn:table>
C:        <idn:uname>çïrâ.fury</idn:uname>
C:      </idn:data>
C:    </extension>
C:    <clTRID>123456</clTRID>
C:  </command>
C:</epp>

The server MUST validate the name as described in IDNA2008 (e.g., RFC 5891 §4.2). If validation fails because of a disallowed code point for the specified table, the server MUST return an appropriate EPP error. If <domain:name> does not map to the provided <idn:uname>, the server MUST return an appropriate EPP error.

4. Formal Syntax (XML Schema)

The following XML Schema defines the IDN Mapping extension formally.

<?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>
</schema>

5. Security Considerations

This extension provides no additional security services beyond those described by EPP and related mappings. The security considerations in those specifications apply here as well.

6. References

6.1. Normative References

  • RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels.
  • RFC 5730 — Extensible Provisioning Protocol (EPP).
  • RFC 5891 — Internationalized Domain Names in Applications (IDNA): Protocol.

6.2. Informational References

  • RFC 3735 — Guidelines for Extending the Extensible Provisioning Protocol (EPP).
  • RFC 5731 — EPP Domain Name Mapping.

7. Acknowledgments

CIRA acknowledges that this specification derives from the IETF Internet-Draft “Internationalized Domain Name Mapping Extension for EPP” by Francisco Obispo and Luis Enrique Munoz (draft-ietf-eppext-idnmap-02).

 

Related documents

CIRA Fury-rgp-1.0 EPP Extension

CIRA Fury-rgp-1.0 EPP Extension

Read
Policy document
CIRA Fury-2.1 EPP Extension

CIRA Fury-2.1 EPP Extension

Read
Policy document
CIRA’s DNSSEC Practice Statement for gTLDs

CIRA’s DNSSEC Practice Statement for gTLDs

Read
Policy document
{( translate(state.status) )}