Internet DRAFT - draft-chung-idnop-epp-idn
draft-chung-idnop-epp-idn
Edmon Chung
Internet Draft
<draft-chung-idnop-epp-idn-02.txt>
October 2004
EPP Internationalized Domain Name (IDN) Object Mapping
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. 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."
The reader is cautioned not to depend on the values that appear in
examples to be current or complete, since their purpose is primarily
educational. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Intellectual Property Rights Statement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internationalized
Internet domain names (IDN) stored in a shared central repository.
Specified in XML, the mapping defines EPP command syntax and
semantics as applied to domain names.
More specifically, EPP-IDN intends to provide a mechanism for
explicitly managing and provisioning IDN Variants created for a
Primary Domain Name.
For registries implementing IDN registrations that do not introduce
IDN variants and its corresponding management and provisioning needs,
a more simple approach utilizing a IDN Extensions based on EPP Domain
Mapping [EPP-D] may be used.
Chung [Page 1]
EPP-IDN October 2004
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 [RFC2119].
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
white space in examples is provided only to illustrate element
relationships and is not a REQUIRED feature of this protocol.
Table of Contents
1. Introduction....................................................2
1.1 Relationship of IDN Objects and Domain Objects.................3
2. Object Attributes...............................................3
2.1 Domain, Host and Name Server Names.............................3
2.2 Status Values..................................................4
3. EPP Command Mapping.............................................4
3.1 EPP Query Commands.............................................4
3.1.1 EPP <check> Command..........................................5
3.1.2 EPP <info> Command..........................................10
3.1.3 EPP <transfer> Query Command................................14
3.2 EPP Transform Commands........................................14
3.2.1 EPP <create> Command........................................14
3.2.2 EPP <delete> Command........................................17
3.2.3 EPP <renew> Command.........................................17
3.2.4 EPP <transfer> Command......................................17
3.2.5 EPP <update> Command........................................17
3.2.6 Offline Review of Requested Actions.........................20
4. Formal Syntax..................................................22
5. Internationalization Considerations............................23
6. IANA Considerations............................................23
7. Security Considerations........................................23
8. Copyright Statement............................................23
1. Introduction
This document describes an Internationalized Internet domain name
(IDN) mapping for version 1.0 of the Extensible Provisioning Protocol
(EPP). This mapping is specified using the Extensible Markup
Language (XML) 1.0 as described in [XML] and XML Schema notation as
described in [XMLS-1] and [XMLS-2].
[EPP] provides a complete description of EPP command and response
structures. A thorough understanding of the base protocol
specification is necessary to understand the mapping described in
this document.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation.
Chung [Page 2]
EPP-IDN October 2004
1.1 Relationship of IDN Objects and Domain Objects
This document assumes that IDN objects have a subordinate
relationship to a superordinate domain name object. An IDN object
contains a set of IDN variants, this entire set being a subordinate
object for the superordinate domain name object, known as the Primary
Domain for the IDN object.
For example, a primary domain "example.tld" has a superoordinate
relationship to the IDN Object (which is a set of domain names ¡ IDN
Variants):{"variant1.tld";"variant2.tld";..."variantX.tld"}. EPP
actions (such as object transfers) that do not preserve this
relationship MUST be explicitly disallowed. The set of potential IDN
variants however MAY overlap between two IDN objects. More
specifically, two superordinate domain names (primary domain) may
share common potential IDN variants. Overlapping variants however
MUST NOT be registered (activated) or reserved by multiple
superordinate domains.
An IDN object MUST NOT be created in a repository for which no
superordinate domain name (primary domain) object exists. Also, the
creation of an IDN object cannot be initiated by the client, but
rather MUST be generated upon creation of a superordinate domain
object by the server based on the IDN Character-Equivalence
Preparation (Charprep) policies at the server. An IDN object MAY be
updated by a client afterwards.
The <create> command in this specification is intended to be used to
create the primary domain of the IDN object instead of an IDN object
itself. A primary domain MAY also be created using other provisional
mechanism such as using IDN Extensions, depending on server support.
An IDN variant, MAY be expressly created and/or modified by the
client using an <update> command. The server MAY also dictate the
creation of "recommended / preferred variants" upon the creation of
the primary domain.
The rationale and relevant arguments for IDN Charprep policies are
not discussed in this document.
2. Object Attributes
An EPP IDN object has attributes and associated values that can be
viewed and modified by the sponsoring client or the server. This
section describes each attribute type in detail. The formal syntax
for the attribute values described here can be found in the "Formal
Syntax" section of this document and in the appropriate normative
references.
2.1 Domain, Host and Name Server Names
Chung [Page 3]
EPP-IDN October 2004
Internationalized domain, host and name server names, as specified in
[RFC3490], described in this document MUST inherit the
internationalization conventions expressed in [EPP]: "EPP is
represented in XML, which provides native support for encoding
information using the Unicode character set and its more compact
representations including UTF-8 [RFC2279]. Conformant XML processors
recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes
provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support
incompatibility exists."
Additionally, all internationalized domain, host and name server
names must be a fully qualified IDN as determined by [RFC3490] and
[RFC3491]. Note also that the transport format of an IDN MUST be in
the Punycode format [RFC3492] OR in UTF-8 following the conventions
expressed in [EPP]. If the client is submitting the IDN in UTF-8, it
SHOULD submit a "sanitized" (i.e. after Nameprep [RFC3491]) string
encapsulated in the appropriate domain field. A server MAY reject a
request if the received UTF-8 string is not conformant to Nameprep.
The syntax for non-internationalized domain, host and name server
names described in this document MUST conform to [RFC952] as updated
by [RFC1123].
A server MAY restrict allowable domain names to a particular top-
level domain, second level domain, or other domain for which the
server is authoritative. The trailing dot required when these names
are stored in a DNS zone is implicit and MUST NOT be provided when
exchanging domain, host and name server names.
2.2 Status Values
An IDN object contains a set of domain names, described as IDN
Variants, which in turn MAY have name server attributes as well as
subordinated host objects. Statuses for these attributes will be
further discussed in Section 3. IDN objects DO NOT have their own
independent domain status, and will inherit the statuses determined
by its superordinate domain object, i.e. its primary domain.
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in [EPP]. The command mappings described here are specifically for
use in provisioning and managing IDN Objects, which contain a set of
IDN Variants (Internationalized domain names), as a subordinate of a
primary domain (domain object) via EPP.
3.1 EPP Query Commands
EPP provides three commands to retrieve domain information: <check>
to determine if a domain object can be provisioned within a
repository, <info> to retrieve detailed information associated with a
Chung [Page 4]
EPP-IDN October 2004
domain object, and <transfer> to retrieve domain object transfer
status information.
3.1.1 EPP <check> Command
The EPP <check> command is used to determine if an object can be
provisioned within a repository. In the case of an IDN object, a
<check> command returns the manageability (in other words,
specifically what elements within the IDN object can be provisioned)
of each IDN variant that is contained in the IDN object. It may also
be used as a generic <check> command to discover whether the primary
domain can be provisioned, together with the availability and
manageability of its set of IDN variants.
In addition to the standard EPP command elements, the <check> command
must contain an <idn:check> element that identifies the IDN namespace
and the location of the IDN schema. The <idn:check> element contains
one or more <idn:domain> elements that contain the following child
elements:
- An <idn:primary> element that contains a fully qualified name of
the domain objects to be queried.
There are two types of <idn:check> requests:
1. To determine the availability and corresponding Recommended
Variants for a Primary Domain queried
2. To determine the availability of IDN variants based on a Primary
Domain (also, the Primary Domain SHOULD already exist at the time
of the check request)
For Scenario 1, the following additional child elements are included:
- One or more OPTIONAL <idn:lang> elements that contain an attribute
"l" identifying the language of the queried primary domain. If the
"l" attribute is not set, AND the domain in question does NOT exist,
then the default value will be l="undefined". The value of the "l"
attribute SHOULD be a language code defined in the ISO639-2 standard
presented as specified by [RFC3066] or "undefined" indicating that
the language is undefined. Independent registries MAY choose to use
different language code standards.
For Scenario 2, the <idn:primary> element MUST still contain the
Primary Domain, with the following additional child elements:
- One or more <idn:var> elements that contain the IDN variant domain
to be queried. <idn:lang> elements MUST NOT be included.
An <idn:check> command with neither <idn:lang> or <idn:var> will be
interpreted as an error. Also, an <idn:domain> element MUST NOT
contain both <idn:lang> and <idn:var> child elements. An <idn:check>
command however MAY contain <idn:domain> elements that specify
Scenario 1 requests and other <idn:domain> elements that specify
Scenario 2 requests within one command.
Chung [Page 5]
EPP-IDN October 2004
Example <check> command (Scenario 1: Availability of Primary Domain):
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <check>
C: <idn:check
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:domain>
C: <idn:primary>probest’ck.org</idn:primary>
C: <idn:lang l="de"/>
C: </idn:domain>
C: <idn:domain>
C: <idn:primary>probest’ck.net</idn:primary>
C: <idn:lang l="de"/>
C: </idn:domain>
C: </domain:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <check> command (Scenario 2: Availability of IDN Variant):
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <check>
C: <idn:check
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:domain>
C: <idn:primary>probest’ck.org</idn:primary>
C: <idn:var>probestueck.org</idn:var>
C: </idn:domain>
C: </domain:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Chung [Page 6]
EPP-IDN October 2004
Example <check> command (Scenario 1 & 2 in different <idn:primary>):
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <check>
C: <idn:check
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:domain>
C: <idn:primary>probest’ck.info</idn:primary>
C: <idn:lang l="de"/>
C: </idn:domain>
C: <idn:domain>
C: <idn:primary>probest’ck.org</idn:primary>
C: <idn:var>probestueck.org</idn:var>
C: </idn:domain>
C: </domain:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Note that potential subsequent actions for Scenario 1 and Scenario 2
are quite different. For a positive response on Scenario 1 requests
(i.e. the Primary Domain is available) the client may likely choose
to proceed with an EPP <create> command to create the domain object
(Section 3.2.1), while in the case of a positive response on Scenario
2 requests (i.e. the IDN variant is available) the client may proceed
with an EPP <update> to add the IDN variant. Note also that a server
SHOULD respond with an error if the client submits a Scenario 2
request with an <idn:var> that does not correspond to the Primary
Domain <idn:primary> based on the server IDN policies.
When a <check> command has been processed successfully, the EPP
<resData> element MUST contain a child <idn:chkData> element that
identifies the IDN namespace and the location of the IDN schema. The
<idn:chkData> element contains one or more <idn:cd> elements that
contain the following child elements:
- An <idn:primary> element that contains the fully qualified name of
the queried domain object (primary domain). This element MUST
contain an "avail" attribute whose value indicates object
availability (does the primary domain exist or not) at the moment the
<check> command was completed. A value of "1" or "true" means that
the object does NOT exist. A value of "0" or "false" means that the
object is not available for creation.
Chung [Page 7]
EPP-IDN October 2004
- An OPTIONAL <idn:reason> element MAY be provided when an object can
not be provisioned. If present, this element contains server-
specific text to help explain why the object cannot be provisioned.
This text MUST be represented in the response language previously
negotiated with the client; an OPTIONAL "lang" attribute MAY be
present to identify the language if the negotiated value is something
other than the default value of "en" (English). This "lang" value
does NOT carry the same meaning as that determined for the Primary
Domain.
Depending on whether it is part of a response for Scenario 1 or 2
requests, further elements to be included is different.
For responses to Scenario 1 requests, the following additional
elements are included:
- One or more OPTIONAL <idn:rvar> elements that contain the IDN
variants that correspond to the queried primary domain and determined
to be Recommended Variants based on the server IDN policy. These
elements MAY contain an availability "avail" attribute whose value
indicates object availability (does the Recommended Variant exist or
not, whether as a Primary Domain or a reserved / activated variant)
at the moment the <check> command was completed. A value of "1" or
"true" means that the object does NOT exist. A value of "0" or
"false" means that the object already exists.
Depending on the server IDN policies, the Primary Domain may or may
not be provisioned if a Recommended Variant is not available. If a
server policy is that when a Recommended Variant is not available,
the Primary Domain cannot be provisioned, then in these specific
cases, the <idn:rvar> and other corresponding elements are not
required. The reason can simply be presented in the <idn:reason>
element.
- One or more OPTIONAL <idn:char> elements that contain the
character(s) within the submitted domain that created variants based
on the server IDN policies. Each <idn:char> element in turn includes
the following child elements:
- One <idn:origChar> element that contains the original character
within the Primary Domain, which is subject to variant provisioning.
- One or more <idn:varChar> element containing the potential variants
of the original character.
Note that from these values, the client will be able to generate the
entire set of IDN variants for a given Primary Domain.
For responses to Scenario 2 requests, the following additional
elements are included:
- One or more OPTIONAL <idn:var> elements that contain IDN variants
corresponding to the request. This element contains an availability
Chung [Page 8]
EPP-IDN October 2004
"avail" attribute whose value indicates object availability (does the
IDN variant exist or not) at the moment the <check> command was
completed. A value of "1" or "true" means that the object does NOT
exist. A value of "0" or "false" means that the object already
exists.
- An OPTIONAL <idn:varReason> element that MAY be provided when an
IDN variant can not be provisioned. If present, this element
contains server-specific text to help explain why the IDN variant
cannot be provisioned. This text MUST be represented in the response
language previously negotiated with the client; an OPTIONAL "lang"
attribute MAY be present to identify the language if the negotiated
value is something other than the default value of "en" (English).
This "lang" value does NOT the carry the same meaning as that
determined for the Primary Domain.
Example <check> response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <idn:chkData
S: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
S: idn-1.0.xsd">
S: <idn:cd>
S: <idn:primary avail="1">probest’ck.info</idn:primary>
S: <idn:rvar avail="1">probestueck.info</idn:rvar>
S: <idn:char>
S: <idn:origChar>’</idn:origChar>
S: <idn:varChar>ue</idn:varChar>
S: </idn:char>
S: </idn:cd>
S: <idn:cd>
S: <idn:primary avail="1">probest’ck.net</idn:primary>
S: <idn:reason>Recommended Variant unavailable.</idn:reason>
S: </idn:cd>
S: <idn:primary avail="0">probest’ck.org</idn:primary>
S: <idn:rvar avail="1">probestueck.org</idn:rvar>
S: <idn:cd>
S: </idn:cd>
S: </idn:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
Chung [Page 9]
EPP-IDN October 2004
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <check> command cannot be
processed for any reason.
3.1.2 EPP <info> Command
The EPP <info> command is used to retrieve information associated
with an IDN object. To retrieve information about an IDN object,
i.e. the existing set of IDN variants within the set as well as their
respective statuses, OR the specific information such as sub-
delegation name servers and hosts for a particular IDN variant, the
<idn:info> command is used.
Note that the EPP <info> command described here for IDN objects do
NOT return social information pertaining the domain object as a
Primary Domain. To query the social information of a domain object,
the client may use the EPP <info> command as specified in the EPP
Domain Mapping document [EPP-D].
In addition to the standard EPP command elements, the <info> command
MUST contain an <idn:info> element that identifies the IDN namespace
and the location of the IDN schema. The <idn:info> element contains
the following child elements:
- An OPTIONAL <idn:domain> element that contains the fully qualified
name of the domain object that identifies the IDN object (which in
essense is the name of the superordinate domain object, or primary
domain) to be queried. An OPTIONAL attribute "var" is available to
control return of information describing elements related to the IDN
object.
A value of "all" (the default, which MAY be absent) returns
information describing all the provisioned IDN variants subordinated
to the Primary domain as well as information on characters that are
subjected to variant generation and their corresponding variants. A
value of "active" returns information describing only the activated
IDN variants (those that are included and published into the zone
file). A value of "reserved" returns information describing only IDN
variants that are reserved. A value of "charprep" returns the
characters subjected to variant generation and their corresponding
variants.
- An OPTIONAL <idn:name> element that contains the fully qualified
name that identifies the IDN Variant (or Primary Domain) to be
queried (this allows the query for host information of the Primary
Domain as well as IDN variants within the IDN object. To query
specifically for host information pertaining the Primary Domain
however, the client MAY choose to use the Domain Mapping protocol
specified in EPP-D). An OPTIONAL "hosts" attribute (similar to that
Chung [Page 10]
EPP-IDN October 2004
described in EPP-D) is available to control return of information
describing hosts related to the IDN Variant. A value of "all" (the
default, which MAY be absent) returns information describing both
subordinate and delegated hosts. A value of "del" returns
information describing only delegate hosts. A value of "sub" returns
information describing only subordinate hosts. A value of "none"
returns no information describing delegated or subordinate hosts.
At least one, and only one <idn:domain> or <idn:name> element MUST be
provided.
Example <info> command with an <idn:domain> child element:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <info>
C: <idn:info
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:primary var="all">probest’ck.info</idn:primary>
C: </idn:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <info> command with an <idn:name> child element:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <info>
C: <idn:info
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:name hosts="all">probestueck.info</idn:name>
C: </idn:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Chung [Page 11]
EPP-IDN October 2004
When an <info> command has been processed successfully, the EPP
<resData> element MUST contain a child <idn:infData> element that
identifies the IDN namespace and the location of the IDN schema.
If the <info> command included an <idn:primary> child element, it
means that information about the IDN object is desired. The
<idn:infData> element therefore MUST contain the following child
elements:
- An <idn:primary> element that contains the fully qualified name of
the domain object that identifies the IDN object (which in essence is
the name of the superordinate domain object, or primary domain)
- One or more <idn:lang> elements that contain an attribute "l"
identifying the language of the queried primary domain. The value of
the "l" attribute SHOULD be a language code defined in the ISO639-2
standard presented as specified by [RFC3066] or "undefined"
indicating that the language is undefined. Independent registries
MAY choose to use different language code standards.
- Zero or more OPTIONAL <idn:var> elements that contains the fully
qualified name of the IDN Variant identified. An <idn:var> element
further contains a "status" attribute. A value of "active" denotes
that the particular reserved IDN variant has been activated. A value
of "reserved" denotes that the particular IDN variant is reserved
(and will not be published into DNS zone files).
- Zero or more OPTIONAL <idn:char> elements that contain the child
elements: <idn:origChar> and <idn:varChar>. These will allow the
client to calculate by permutation all the "suggested variants" that
were neither "active" or "reserved" (i.e. not yet provisioned).
Example <info> response to an <info> command with an <idn:domain>
child element:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <idn:infData
S: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
S: idn-1.0.xsd">
S: <idn:primary>probest’ck.info</idn:primary>
S: <idn:lang l="de"/>
S: <idn:var status="reserved">probestrueck.info</idn:var>
S: <idn:char>
Chung [Page 12]
EPP-IDN October 2004
S: <idn:origChar>’</idn:origChar>
S: <idn:varChar>ue</idn:varChar>
S: </idn:char>
S: </idn:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
If the <info> command included an <idn:name> child element, it means
that host information about a particular IDN variant is desired. The
<idn:infData> element MUST therefore contain the following child
elements:
- An <idn:name> element that contains the fully qualified name that
identifies the IDN Variant (or Primary Domain) that was queried. An
<idn:name> element further contains the "status" attribute. A value
of "primary" denotes that the particular name queried is the Primary
Domain of the IDN object. A value of "active" denotes that the
particular IDN variant has been activated. A value of "reserved"
denotes that the particular IDN variant is reserved (and will not be
published into DNS zone files).
- Zero or more OPTIONAL <idn:ns> elements that contain the fully
qualified names of the delegated host objects (name servers)
associated with this IDN variant.
- Zero or more OPTIONAL <idn:host> elements that contain the fully
qualified names of the subordinate host objects that exist under
this superordinate IDN variant.
Example <info> response to an <info> command with an <idn:name> child
element:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <idn:infData
S: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
S: idn-1.0.xsd">
S: <idn:name status="active">probestueck.info</idn:name>
S: <idn:ns>ns1.example.org</idn:ns>
Chung [Page 13]
EPP-IDN October 2004
S: <idn:host>ns1.probestueck.info</idn:host>
S: </idn:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <info> command cannot be
processed for any reason.
3.1.3 EPP <transfer> Query Command
Transfer semantics do not directly apply to IDN objects, so there is
no mapping defined for the EPP <transfer> query command.
3.2 EPP Transform Commands
EPP provides five commands to transform domain objects: <create> to
create an instance of a domain object, <delete> to delete an instance
of a domain object, <renew> to extend the validity period of a domain
object, <transfer> to manage domain object sponsorship changes, and
<update> to change information associated with a domain object.
Transform commands are typically processed and completed in real
time. Server operators MAY receive and process transform commands,
but defer completing the requested action if human or third-party
review is required before the requested action can be completed. In
such situations the server MUST return a 1001 response-code to the
client to note that the command has been received and processed, but
the requested action is pending. The server MUST also manage the
status of the object that is the subject of the command to reflect
the initiation and completion of the requested action. Once the
action has been completed, all clients involved in the transaction
MUST be notified using a service message that the action has been
completed and that the status of the object has changed.
3.2.1 EPP <create> Command
The EPP <create> command for this IDN mapping actually provides a
transform operation that allows a client to create a domain object
that will be the primary domain for a corresponding subordinate IDN
object. In effect, it replaces, or rather, augments the <create>
command specified for [EPP-D]. To add an IDN Variant into an IDN
object, please refer to Section 3.2.5 based on the <update> command.
In addition to the standard EPP command elements, the <create>
command MUST contain an <idn:create> element that identifies the IDN
namespace and the location of the IDN schema. The <idn:create>
element contains the following child elements:
Chung [Page 14]
EPP-IDN October 2004
- A <domain:create> element that identifies the domain namespace and
the location of the domain schema. The <domain:create> element
contains child elements as defined in [EPP-D].
- One or more <idn:lang> element that identifies the language of the
domain name determined by an "l" attribute. The "l" attribute SHOULD
contain a value based on the language code in the ISO639-2 standard
further defined in [RFC3066] or a value of "undefined". The value of
"undefined" will be allocated by default if the attribute is not
defined. Independent registries MAY choose to use different language
code standards.
- One or more OPTIONAL <idn:var> elements that identifies the IDN
variants that the client wishes to explicitly add to the IDN.
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <create>
C: <idn:create
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>probest’ck.info</domain:name>
C: <domain:period unit="y">2</domain:period>
C: <domain:ns>ns1.example.org</domain:ns>
C: <domain:ns>ns1.example.net</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: <idn:lang l="de"/>
C: <idn:var>probestueck.info</idn:var>
C: </idn:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <create> command has been processed successfully, the EPP
<resData> element MUST contain a child <idn:creData> element that
Chung [Page 15]
EPP-IDN October 2004
identifies the IDN namespace and the location of the IDN schema. The
<idn:creData> element contains the following child elements:
- A <domain:creData> element that identifies the domain namespace and
the location of the domain schema. The <domain:creData> element
contains child elements as defined in [EPP-D].
- One or more OPTIONAL <idn:rcmd> elements that contain the IDN
variants that correspond to the queried primary domain and determined
to be Recommended Variants based on the server IDN policy.
- One or more OPTIONAL <idn:var> elements that contain the IDN
variants that was explicitly identified by the client at creation.
If an explicitly provisioned IDN variant happens to be a Recommended
Variant, it will be listed as an <idn:rcmd> element.
- One or more OPTIONAL <idn:char> elements that contain the
character(s) within the created primary domain that is subject to
variant generation based on the server IDN policies. Each <idn:char>
element in turn includes the following child elements:
- One <idn:origChar> element that contains the original character
within the Primary Domain, which is subject to variant provisioning.
- One or more <idn:varChar> element containing the potential variants
of the original character.
Note that from these values, the client will be able to generate the
entire set of IDN variants for a given Primary Domain.
Example <create> response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <idn:creData
S: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
S: idn-1.0.xsd">
S: <domain:creData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>probest’ck.info</domain:name>
S: <domain:crDate>2004-01-01T22:00:00.0Z</domain:crDate>
S: <domain:exDate>2005-12-31T22:00:00.0Z</domain:exDate>
Chung [Page 16]
EPP-IDN October 2004
S: </domain:creData>
S: <idn:rvar>probestueck.info</idn:rvar>
S: <idn:char>
S: <idn:origChar>’</idn:origChar>
S: <idn:varChar>ue</idn:varChar>
S: </idn:char>
S: </idn:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <create> command cannot
be processed for any reason.
3.2.2 EPP <delete> Command
Delete semantics do not directly apply to IDN objects, so there is no
mapping defined for the EPP <delete> query command. To delete an IDN
variant from an IDN object, please refer to the <update> command
described in Section 3.2.5.
IDN objects are meant to be subordinate objects of a primary domain,
in other words, a domain object. To delete a primary domain, the
<domain:delete> command provided in the EPP domain mapping [EPP-D]
will be used.
Upon the deletion of a primary domain, its subordinated IDN object
MUST also be deleted. This is consistent with the package concept of
IDN variants and primary domains.
3.2.3 EPP <renew> Command
Renew semantics do not directly apply to IDN objects, so there is no
mapping defined for the EPP <renew> query command.
It is however noted that IDN variants, potentially treated as a
domain object, which is a superordinate for host object, SHOULD have
its expiry date and time synchronized with its own superordinate
domain object, more specifically the primary domain of the IDN object
containing the particular IDN variant. Renewal of the primary domain
MUST effect a renewal for all of the relevant IDN variants within the
subordinate IDN object.
3.2.4 EPP <transfer> Command
Transfer semantics do not directly apply to IDN objects, so there is
no mappings defined for the EPP <transfer> transform command.
3.2.5 EPP <update> Command
Chung [Page 17]
EPP-IDN October 2004
The EPP <update> command provides a transform operation that allows a
client to modify the attributes of a domain object. For the IDN
mapping specifications, the EPP <update> command will serve to
provide functionalities to add or remove IDN variants and their
corresponding delegation name servers for an IDN object, as well as
to activate, deactivate (reserve) or promote (to a Primary Domain) an
IDN variant.
In addition to the standard EPP command elements, the <update>
command MUST contain an <idn:update> element that identifies the IDN
namespace and the location of the IDN schema. The <idn:update>
element contains the following child elements:
- An <idn:primary> element that contains the fully qualified name of
the domain object that identifies the IDN object (which in essence is
the name of the superordinate domain object, or primary domain) to be
updated.
- An OPTIONAL <idn:add> element that contains attribute values to be
added to the object.
- An OPTIONAL <idn:rem> element that contains attribute values to be
removed from the object.
- An OPTIONAL <idn:chg> element that contains object attribute values
to be changed.
At least one <idn:add>, <idn:rem>, or <idn:chg> element MUST be
provided. The <idn:add> and <idn:rem> elements contain one or more
<idn:var> child elements, which contains the following child
elements:
- An <idn:name> element that contains the fully qualified name of the
IDN variant (or Primary Domain - to update attributes for the Primary
Domain, EPP-D can also be used) to be added to or removed from the
IDN object.
- Zero or more <idn:ns> elements that contain the fully qualified
name of a known name server host object. A host object MUST be known
to the server before a name server attribute can be added or removed
from a domain object. The EPP mapping for host objects is described
in [EPP-H].
Note that to remove the entire IDN variant from the IDN object, there
MUST NOT be any other child elements except for the <idn:name>
element within the particular <idn:var> element. Note also that you
can use the <update> command to create a new IDN variant to be
included into the IDN object (if the policies from the server
allows).
An <idn:chg> element contains the following child elements:
Chung [Page 18]
EPP-IDN October 2004
- An <idn:name> element that contains the fully qualified name of the
IDN variant (or Primary Domain - to update attributes for the Primary
Domain, EPP-D can also be used) to be updated.
- An <idn:status> element that contain status values "s" to be
applied to the IDN variant. Three statuses are defined: "active"
indicates that that the IDN variant is to be activated (i.e. included
into the DNS zone files); "reserve" indicates that the IDN variant is
not to be included into the DNS zone files of the registry; and
"promote" indicates that the IDN variant is to be promoted to become
a Primary Domain object inheriting all the social information of the
current Primary Domain.
Example <update> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <update>
C: <idn:update
C: xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0
C: idn-1.0.xsd">
C: <idn:add>
C: <idn:var>
C: <idn:name>probest’ck.info</idn:name>
C: <idn:ns>ns2.example.org</idn:ns>
C: <idn:ns>ns3.example.org</idn:ns>
C: </idn:var>
C: </idn:add>
C: <idn:rem>
C: <idn:var>
C: <idn:name>probest’ck.info</idn:name>
C: <idn:ns>ns1.example.net</idn:ns>
C: </idn:var>
C: </idn:rem>
C: <idn:chg>
C: <idn:var>
C: <idn:name>probestueck.info</idn:name>
C: <idn:status s="promote"/>
C: </idn:var>
C: </idn:chg>
C: </idn:update>
C: </update>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <update> command has been processed successfully, a server
MUST respond with an EPP response with no <resData> element.
Chung [Page 19]
EPP-IDN October 2004
Example <update> response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <update> command cannot
be processed for any reason.
3.2.6 Offline Review of Requested Actions
Commands are processed by a server in the order they are received
from a client. Though an immediate response confirming receipt and
processing of the command is produced by the server, a server
operator MAY perform an offline review of requested transform
commands before completing the requested action. In such situations
the response from the server MUST clearly note that the transform
command has been received and processed, but the requested action is
pending. The status of the corresponding object MUST clearly reflect
processing of the pending action. The server MUST notify the client
when offline processing of the action has been completed.
An example describing a <create> response that required offline
review is included here. Note the result code and message returned
in response to the <create> command.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg>
S: </result>
S: <resData>
S: <idn:creData>
S: <domain:creData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
Chung [Page 20]
EPP-IDN October 2004
S: domain-1.0.xsd">
S: <domain:name>probest’ck.info</domain:name>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
S: </domain:creData>
S: <idn:rvar>probestueck.info</idn:rvar>
S: <idn:char>
S: <idn:origChar>’</idn:origChar>
S: <idn:varChar>ue</idn:varChar>
S: </idn:char>
S: </idn:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
The status of the domain object after returning this response MUST
include "pendingCreate". The server operator reviews the request
offline, and informs the client of the outcome of the review by
queuing a service message for retrieval via the <poll> command.
The service message will pertain the domain object identified by the
primary domain and therefore will be exactly the same as defined in
[EPP-D].
Chung [Page 21]
EPP-IDN October 2004
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.
The BEGIN and END tags are not part of the schema; they are used to
note the beginning and ending of the schema for URI registration
purposes.
BEGIN
[To be included]
END
Chung [Page 22]
EPP-IDN October 2004
5. Internationalization Considerations
This document describes the management and provisioning of
Internationalized domain names with considerations to IDN variants
created by character equivalence preparations issues. For more
information on the subject matter please refer to [Charprep] and
[Zoneprep].
EPP is represented in XML, which provides native support for encoding
information using the Unicode character set and its more compact
representations including UTF-8 [RFC2279]. Conformant XML processors
recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes
provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support
incompatibility exists.
More importantly, the domain names provisioned (unless otherwise
specified to use Punycode) MUST be encoded in UTF-8 or UTF-16
determined by the XML declaration. The use of UTF-8 is RECOMMENDED.
The transported IDNs MUST be properly normalized based on [Nameprep],
unless otherwise specified.
6. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [IETF-XML]. Since
this is intended to be an informational document for the management
and provisioning of Internationalized domain names, two URI
assignments for the relevant elements may be requested.
7. Security Considerations
The mapping extensions described in this document do not provide any
security services beyond those described by EPP [EPP], the EPP domain
name mapping [EPP-D], and protocol layers used by EPP.
8. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Chung [Page 23]
EPP-IDN October 2004
Acknowledgements
The author acknowledges that portions of this document has been
adopted from the Extensible Provisioning Protocol Domain Name Mapping
draft <draft-ietf-provreg-epp-domain-06.txt> and the Extensible
Provisioning Protocol Host Mapping draft <draft-ietf-provreg-epp-
host-06.txt>, both of which written by Scott Hollenbeck.
Additionally, we would like to thank the following persons for their
comments and contributions that were instrumental to the completion
of this document:
Erin Chen
Vincent Chen
Hsu Nai Wen
Scott Hollenbeck
Janusz Sienkiewicz
Henry Tong
Eric Wang
Helena Zhou
References
[EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in
progress.
[EPP-D] S. Hollenbeck: "Extensible Provisioning Protocol Domain Name
Mapping", work in progress.
[EPP-H] S. Hollenbeck: "Extensible Provisioning Protocol Host
Mapping", work in progress.
[EPP-C] S. Hollenbeck: "Extensible Provisioning Protocol Contact
Mapping", work in progress.
[EPP-IDNEXT] E. Chung: "EPP Internationalized Domain Name Extension",
work in progress.
IETF-XML] M. Mealling: "The IETF XML Registry", work in progress.
[RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3403] M. Mealling: "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[XML] Editors T. Bray et al.: "Extensible Markup Language (XML) 1.0
(Second Edition)", W3C Recommendation 6 October 2000.
[XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures",
W3C Recommendation 2 May 2001.
Chung [Page 24]
EPP-IDN October 2004
[XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2:
Datatypes", W3C Recommendation 2 May 2001.
Informative references:
[RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2781] P. Hoffman, F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[EPP-E.164] S. Hollenbeck: "Extensible Provisioning Protocol E.164
Number Mapping", work in progress.
Changes from ¡00 to -01
In Section 3.1.2, instead of suggesting 2 different <info> commands,
the difference is handled by optional child elements <idn:primary>
and <idn:name>.
Attribute name for availability of variant changed to "avail".
Attribute name for Reserved Variant Type changed to "RVtype".
Attribute name for Zone Variant Type changed to "ZVtype".
Section 3.2.2: additional clarification on the deletion of a primary
domain is provided.
Changes from ¡01 to -02
Removed all reference to Variant Types.
Simplified to NOT have server announce detailed IDN policies via
protocol.
Changed "example" domain to a German name to better illustrate
concept.
Clarified the 2 scenarios for <check> commands: 1. Check availability
of Primary Domain; 2. Check availability of particular IDN variants
of a given Primary Domain.
Clarified the 2 types of <info> commands: 1. Information (list of IDN
variants) within a given IDN object (Primary Domain); 2. Host
information for a particular IDN variant (or Primary Domain).
Added new status type, s="promote" within <idn:chg> element of the
<update> command to allow for promoting an IDN variant to a Primary
Domain. Potentially caused by result of a dispute resolution.
Authors' Address:
Chung [Page 25]
EPP-IDN October 2004
Edmon Chung
Afilias
Suite 204, 4141 Yonge Street,
Toronto, Ontario,
Canada M2P 2A8
edmon@afilias.info
Chung [Page 26]
