| Internet Engineering Task Force | G. Lozano |
| Internet-Draft | ICANN |
| Intended status: Standards Track | July 07, 2016 |
| Expires: January 8, 2017 |
Transformation of Contact Information Extension Mapping for the Extensible Provisioning Protocol (EPP)
draft-lozano-regext-epp-transf-contact-inf-00
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of transformation (i.e. translation and transliteration) of contact information for objects stored in a shared central repository. Specified in XML, this mapping extends the EPP contact mapping.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 January 8, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in [RFC5730]. This mapping, an extension of the contact mapping described in [RFC5733], is specified using the Extensible Markup Language (XML) 1.0 [W3C.REC-xml] and XML Schema notation ([W3C.REC-xmlschema-1] [W3C.REC-xmlschema-2]).
The EPP core protocol specification [RFC5730] 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.
This document is written following the Guidelines for Extending the Extensible Provisioning Protocol as defined in [RFC3735].
Generic TLDs (gTLDs) Domain Name Registries and Registrars operating according to an agreement with the Internet Corporation for Assigned Names and Numbers (ICANN) are required to follow ICANN Consensus Policies.
On 28/September/2015, the ICANN Board adopted the GNSO Council Policy Recommendations concerning the translation and transliteration of contact information as presented in the "Final Report on the Translation and Transliteration of Contact Information Policy Development Process" (T&T Report, see [TTOCI]).
The T&T Report recommends:
This specification is intended to be used by gTLD Domain Name Registries and Registrars in order to support this recommendation.
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 [RFC2119].
In examples, "C:" represents lines sent by a protocol client, and "S:" represents lines returned by a protocol server. "////" is used to note element values that have been shortened to better fit page boundaries. Indentation and white space in examples is provided only to illustrate element relationships and is not a mandatory feature of this protocol.
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
ird-1.0 is used as an abbreviation for urn:ietf:params:xml:ns:ird-1.0. The XML namespace prefix "ird" 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.
This extension adds additional elements to the EPP contact mapping [RFC5733]. Only those new elements are described here.
Postal-address information in [RFC5733] can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. The use of this extension requires that:
The following common elements are used in this extension:
The following postal information objects are used in this extension:
The <ird:contactPostalInfo> is used to specify the Internationalized Registration Data (IRD) information of the <contact:postalInfo>. A required "type" attribute is used to specify the relation to a <contact:postalInfo> element. Possible values for the "type" attribute are: localized ("loc") or internationalized ("int"). A required "infSource" attribute is used to specify the source (i.e. "registry", "registrar", "reseller", or "registrant") of the <contact:postalInfo> information. A required "authOrTransMechanism" attribute is used to define which of the two types ("loc" or "int") of <contact:postalInfo> is the authoritative information from which the transformations are derived. Alternatively, if the <contact:postalInfo> is not authoritative, then it has been transformed (i.e. "translation" or "transliteration").
The <ird:contactPostalInfo> object contains the following child elements:
The <ird:additionalPostalInfo> is used to specify additional transformations of the authoritative <contact:postalInfo> element. A required "infSource" attribute is used to specify the source (i.e. "registry", "registrar", "reseller", or "registrant") of the additional transformation. An required "conversionMechanism" attribute is used to define the transformation mechanism (i.e. "transliteration" or "translation") of the authoritative <contact:postalInfo> information.
The <ird:additionalPostalInfo> object contains the following child elements:
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use in provisioning and managing of transformation of contact information via EPP.
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.
This extension does not add any elements to the EPP <check> command or <check> response described in the EPP contact mapping [RFC5733].
This extension does not add any elements to the EPP <info> command described in the EPP contact mapping [RFC5733]. However, additional elements are defined for the <info> response.
When an <info> command has been processed successfully the EPP <extension> element MUST contain a child <ird:infData> element. The <ird:infData> element contains the following child elements:
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: <contact:infData S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>sh8013</contact:id> S: <contact:roid>SH8013-REP</contact:roid> S: <contact:status s="linked"/> S: <contact:status s="clientDeleteProhibited"/> S: <contact:postalInfo type="loc"> S: <contact:name>Иван Петрович Сидоров</contact:name> S: <contact:addr> S: <contact:street>8343 Драгатуш</contact:street> S: <contact:city>Бобруйск</contact:city> S: <contact:pc>20166-6503</contact:pc> S: <contact:cc>RU</contact:cc> S: </contact:addr> S: </contact:postalInfo> S: <contact:postalInfo type="int"> S: <contact:name>Ivan Petrovich Sidorov</contact:name> S: <contact:addr> S: <contact:street>8343 Dragatush</contact:street> S: <contact:city>Babruysk</contact:city> S: <contact:pc>20166-6503</contact:pc> S: <contact:cc>RU</contact:cc> S: </contact:addr> S: </contact:postalInfo> S: <contact:voice x="1234">+1.7035555555</contact:voice> S: <contact:fax>+1.7035555556</contact:fax> S: <contact:email>ivan@example.com</contact:email> S: <contact:clID>ClientY</contact:clID> S: <contact:crID>ClientX</contact:crID> S: <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate> S: <contact:upID>ClientX</contact:upID> S: <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate> S: <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate> S: <contact:authInfo> S: <contact:pw>2fooBAR</contact:pw> S: </contact:authInfo> S: <contact:disclose flag="0"> S: <contact:voice/> S: <contact:email/> S: </contact:disclose> S: </contact:infData> S: </resData> S: <extension> S: <ird:infData S: xmlns:ird="urn:ietf:params:xml:ns:ird-1.0" S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <ird:contactPostalInfo infSource="registrant" S: type="loc" authOrTransMechanism="authoritative"> S: <ird:nameLang>ru</ird:nameLang> S: <ird:addrLang>ru</ird:addrLang> S: <ird:country lang="ru">Россия</ird:country> S: </ird:contactPostalInfo> S: <ird:contactPostalInfo infSource="registrar" S: type="int" authOrTransMechanism="translation"> S: <ird:nameLang>en</ird:nameLang> S: <ird:addrLang>en</ird:addrLang> S: <ird:country lang="en">Russia</ird:country> S: </ird:contactPostalInfo> S: <ird:additionalPostalInfo infSource="registrar" S: transMechanism="transliteration"> S: <ird:id>sh8013-3</ird:id> S: <ird:name lang="ru-Latn">Ivan Petrovič Sidorov</ird:name> S: <ird:addr lang="ru-Latn"> S: <ird:street>8343 Dragatuš</ird:street> S: <ird:city>Bobrujsk</ird:city> S: <ird:pc>20166-6503</ird:pc> S: <ird:cc>RU</ird:cc> S: </ird:addr> S: <ird:country lang="ru-Latn">Rossiâ</ird:country> S: <ird:transliterationStd>iso9</ird:transliterationStd> S: <ird:disclose flag="0"> S: <ird:name/> S: </ird:disclose> S: </ird:additionalPostalInfo> S: <ird:additionalPostalInfo infSource="registrar" S: transMechanism="translation"> S: <ird:id>sh8013-4</ird:id> S: <ird:name lang="es">Iván Petrovich Sidorov</ird:name> S: <ird:addr lang="es"> S: <ird:street>8343 Dragatush</ird:street> S: <ird:city>Babruysk</ird:city> S: <ird:pc>20166-6503</ird:pc> S: <ird:cc>RU</ird:cc> S: </ird:addr> S: <ird:country lang="es">Rusia</ird:country> S: <ird:disclose flag="0"> S: <ird:name/> S: </ird:disclose> S: </ird:additionalPostalInfo> S: </ird:infData> S: </extension> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
This extension does not add any elements to the EPP <transfer> command or <check> response described in the EPP contact mapping [RFC5733].
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.
This extension defines additional elements for the EPP <create> command described in the EPP contact mapping [RFC5733]. When a <create> command that includes this extension has been processed successfully, the response MUST include this EPP <extension> with a child <ird:infData> element.
The EPP <create> command provides a transform operation that allows a client to create a contact object. In addition to the EPP command elements described in the EPP contact mapping [RFC5733], the command MUST contain an <extension> element, and the <extension> element MUST contain a child <ird:infData> element that identifies the extension namespace if the client wants to associate data defined in this extension to the contact object. The <ird:infData> element contains the following child elements:
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: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>sh8013</contact:id> C: <contact:postalInfo type="loc"> C: <contact:name>Иван Петрович Сидоров</contact:name> C: <contact:addr> C: <contact:street>8343 Драгатуш</contact:street> C: <contact:city>Бобруйск</contact:city> C: <contact:pc>20166-6503</contact:pc> C: <contact:cc>RU</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:postalInfo type="int"> C: <contact:name>Ivan Petrovich Sidorov</contact:name> C: <contact:addr> C: <contact:street>8343 Dragatush</contact:street> C: <contact:city>Babruysk</contact:city> C: <contact:pc>20166-6503</contact:pc> C: <contact:cc>RU</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice x="1234">+1.7035555555</contact:voice> C: <contact:fax>+1.7035555556</contact:fax> C: <contact:email>ivan@example.com</contact:email> C: <contact:authInfo> C: <contact:pw>2fooBAR</contact:pw> C: </contact:authInfo> C: <contact:disclose flag="0"> C: <contact:voice/> C: <contact:email/> C: </contact:disclose> C: </contact:create> C: </create> C: <extension> C: <ird:infData C: xmlns:ird="urn:ietf:params:xml:ns:ird-1.0" > C: <ird:contactPostalInfo infSource="registrant" C: type="loc" authOrTransMechanism="authoritative"> C: <ird:nameLang>ru</ird:nameLang> C: <ird:addrLang>ru</ird:addrLang> C: <ird:country lang="ru">Россия</ird:country> C: </ird:contactPostalInfo> C: <ird:contactPostalInfo infSource="registrar" C: type="int" authOrTransMechanism="translation"> C: <ird:nameLang>en</ird:nameLang> C: <ird:addrLang>en</ird:addrLang> C: <ird:country lang="en">Russia</ird:country> C: </ird:contactPostalInfo> C: <ird:additionalPostalInfo infSource="registrar" C: transMechanism="transliteration"> C: <ird:id>sh8013-3</ird:id> C: <ird:name lang="ru-Latn">Ivan Petrovič Sidorov</ird:name> C: <ird:addr lang="ru-Latn"> C: <ird:street>8343 Dragatuš</ird:street> C: <ird:city>Bobrujsk</ird:city> C: <ird:pc>20166-6503</ird:pc> C: <ird:cc>RU</ird:cc> C: </ird:addr> C: <ird:country lang="ru-Latn">Rossiâ</ird:country> C: <ird:transliterationStd>iso9</ird:transliterationStd> C: <ird:disclose flag="0"> C: <ird:name/> C: </ird:disclose> C: </ird:additionalPostalInfo> C: <ird:additionalPostalInfo infSource="registrar" C: transMechanism="translation"> C: <ird:id>sh8013-4</ird:id> C: <ird:name lang="es">Iván Petrovich Sidorov</ird:name> C: <ird:addr lang="es"> C: <ird:street>8343 Dragatush</ird:street> C: <ird:city>Babruysk</ird:city> C: <ird:pc>20166-6503</ird:pc> C: <ird:cc>RU</ird:cc> C: </ird:addr> C: <ird:country lang="es">Rusia</ird:country> C: <ird:disclose flag="0"> C: <ird:name/> C: </ird:disclose> C: </ird:additionalPostalInfo> C: </ird:infData> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP contact mapping [RFC5733].
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP contact mapping [RFC5733].
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP contact mapping [RFC5733].
This extension defines additional elements for the EPP <update> command described in the EPP contact mapping [RFC5733]. When an <update> command that includes this extension has been processed successfully, the response MUST include this EPP <extension> with a child <ird:infData> element.
The EPP <update> command provides a transform operation that allows a client to modify the attributes of a contact object. In addition to the EPP command elements described in the EPP contact mapping, the command MUST contain an <extension> element, and the <extension> element MUST contain a child <ird:update> element that identifies the extension namespace if the client wants to update the contact object with data defined in this extension. The <ird:update> element contains a <ird:add> element to add ird information or, a <ird:rem> element to remove ird information.
The order of the <ird:rem> and <ird:add> elements is significant, where the server MUST first remove the existing elements prior to adding the new elements.
The <ird:update> element contains the following child elements:
Example of <update>:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>sh8013</contact:id> C: <contact:add> C: <contact:status s="clientDeleteProhibited"/> C: </contact:add> C: </contact:update> C: </update> C: <extension> C: <ird:update C: xmlns:ird="urn:ietf:params:xml:ns:ird-1.0" > C: <ird:rem> C: <ird:contactPostalInfoRem>int</ird:contactPostalInfoRem> C: <ird:id>sh8013-1</ird:id> C: <ird:id>sh8013-2</ird:id> C: </ird:rem> C: <ird:add> C: <ird:contactPostalInfo infSource="registrant" C: type="loc" authOrTransMechanism="authoritative"> C: <ird:nameLang>ru</ird:nameLang> C: <ird:addrLang>ru</ird:addrLang> C: <ird:country lang="ru">Россия</ird:country> C: </ird:contactPostalInfo> C: <ird:contactPostalInfo infSource="registrar" C: type="int" authOrTransMechanism="translation"> C: <ird:nameLang>en</ird:nameLang> C: <ird:addrLang>en</ird:addrLang> C: <ird:country lang="en">Russia</ird:country> C: </ird:contactPostalInfo> C: <ird:additionalPostalInfo infSource="registrar" C: transMechanism="transliteration"> C: <ird:id>sh8013-3</ird:id> C: <ird:name lang="ru-Latn">Ivan Petrovič Sidorov</ird:name> C: <ird:addr lang="ru-Latn"> C: <ird:street>8343 Dragatuš</ird:street> C: <ird:city>Bobrujsk</ird:city> C: <ird:pc>20166-6503</ird:pc> C: <ird:cc>RU</ird:cc> C: </ird:addr> C: <ird:country lang="ru-Latn">Rossiâ</ird:country> C: <ird:transliterationStd>iso9</ird:transliterationStd> C: <ird:disclose flag="0"> C: <ird:name/> C: </ird:disclose> C: </ird:additionalPostalInfo> C: <ird:additionalPostalInfo infSource="registrar" C: transMechanism="translation"> C: <ird:id>sh8013-4</ird:id> C: <ird:name lang="es">Iván Petrovich Sidorov</ird:name> C: <ird:addr lang="es"> C: <ird:street>8343 Dragatush</ird:street> C: <ird:city>Babruysk</ird:city> C: <ird:pc>20166-6503</ird:pc> C: <ird:cc>RU</ird:cc> C: </ird:addr> C: <ird:country lang="es">Rusia</ird:country> C: <ird:disclose flag="0"> C: <ird:name/> C: </ird:disclose> C: </ird:additionalPostalInfo> C: </ird:add> C: </ird:update> C: </extension> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
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.
Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:ird-1.0"
xmlns:ird="urn:ietf:params:xml:ns:ird-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="urn:ietf:params:xml:ns:contact-1.0"
schemaLocation="contact-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"
schemaLocation="epp-1.0.xsd"/>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0 contact extension
schema for provisioning and management the transformation
(i.e. transliteration or translation) of an entity
object.
</documentation>
</annotation>
<element name="infData" type="ird:infDataType"/>
<element name="update" type="ird:updateDataType"/>
<complexType name="updateDataType">
<sequence>
<element name="rem" type="ird:remType"
minOccurs="0"/>
<element name="add" type="ird:infDataType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="remType">
<sequence>
<element name="contactPostalInfoRem"
type="contact:postalInfoEnumType"
minOccurs="0" maxOccurs="2"/>
<element name="id" type="eppcom:clIDType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="infDataType">
<sequence>
<element name="contactPostalInfo"
type="ird:contactPostalInfoDataType"
minOccurs="1" maxOccurs="2"/>
<element name="additionalPostalInfo"
type="ird:additionalPostalInfoDataType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="contactPostalInfoDataType">
<sequence>
<element name="nameLang" type="language" />
<element name="orgLang" type="language" minOccurs="0"/>
<element name="addrLang" type="language" />
<element name="country" type="ird:countryType" />
<element name="transliterationStd" type="token"
minOccurs="0"/>
</sequence>
<attribute name="type" type="contact:postalInfoEnumType"
use="required"/>
<attribute name="infSource" type="ird:infSourceEnumType"
use="required"/>
<attribute name="authOrTransMechanism"
type="ird:authOrTransMechanismEnumType" />
</complexType>
<complexType name="additionalPostalInfoDataType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="name" type="ird:name" />
<element name="org" type="ird:org"
minOccurs="0"/>
<element name="addr" type="ird:addrType"/>
<element name="country" type="ird:countryType" />
<element name="transliterationStd" type="token"
minOccurs="0"/>
<element name="disclose" type="ird:discloseType"
minOccurs="0"/>
</sequence>
<attribute name="infSource" type="ird:infSourceEnumType"
use="required"/>
<attribute name="transMechanism"
type="ird:conversionMechanismEnumType" use="required"/>
</complexType>
<complexType name="name">
<simpleContent>
<extension base="contact:postalLineType">
<attribute name="lang" type="language" use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="org">
<simpleContent>
<extension base="contact:optPostalLineType">
<attribute name="lang" type="language" use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="addrType">
<sequence>
<element name="street" type="contact:optPostalLineType"
minOccurs="0" maxOccurs="3"/>
<element name="city" type="contact:postalLineType"/>
<element name="sp" type="contact:optPostalLineType"
minOccurs="0"/>
<element name="pc" type="contact:pcType"
minOccurs="0"/>
<element name="cc" type="contact:ccType"/>
</sequence>
<attribute name="lang" type="language" use="required" />
</complexType>
<complexType name="countryType">
<simpleContent>
<extension base="token">
<attribute name="lang" type="language" use="required" />
</extension>
</simpleContent>
</complexType>
<simpleType name="infSourceEnumType">
<restriction base="token">
<enumeration value="registry"/>
<enumeration value="registrar"/>
<enumeration value="reseller"/>
<enumeration value="registrant"/>
</restriction>
</simpleType>
<simpleType name="conversionMechanismEnumType">
<restriction base="token">
<enumeration value="translation"/>
<enumeration value="transliteration"/>
</restriction>
</simpleType>
<simpleType name="authOrTransMechanismEnumType">
<restriction base="token">
<enumeration value="authoritative"/>
<enumeration value="translation"/>
<enumeration value="transliteration"/>
</restriction>
</simpleType>
<complexType name="discloseType">
<sequence>
<element name="name" minOccurs="0"/>
<element name="org" minOccurs="0"/>
<element name="addr" minOccurs="0"/>
<element name="voice" minOccurs="0"/>
<element name="fax" minOccurs="0"/>
<element name="email" minOccurs="0"/>
</sequence>
<attribute name="flag" type="boolean" use="required"/>
</complexType>
</schema>
END
TBD.
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.
Registration request for the ird namespace:
Registration request for the ird schema:
The internationalization considerations of EPP described in [RFC5730] apply to this specification as well.
The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730], the EPP contact mapping [RFC5733], and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3688] | Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004. |
| [RFC3735] | Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, March 2004. |
| [RFC5646] | Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009. |
| [RFC5730] | Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009. |
| [RFC5733] | Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009. |
| [W3C.REC-xml] | W3C, "Extensible Markup Language (XML) 1.0 (Second Edition)", Oct 2000. |
| [W3C.REC-xmlschema-1] | W3C, "XML Schema Part 1: Structures Second Edition", Oct 2004. |
| [W3C.REC-xmlschema-2] | W3C, "XML Schema Part 2: Structures Second Edition", Oct 2004. |
| [TTOCI] | ICANN, "Final Report on the Translation and Transliteration of Contact Information Policy Development Process", June 2015. |