Transformation of Contact Information Extension Mapping for the Extensible Provisioning Protocol (EPP)

This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in . This mapping, an extension of the contact mapping described in , is specified using the Extensible Markup Language (XML) 1.0 and XML Schema notation ( ). The EPP core protocol specification 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 . 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 ). The T&T Report recommends: Whilst noting that a Whois replacement system should be capable of receiving input in the form of non-ASCII script contact information, the Working Group recommends its data fields be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder 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. 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 . Only those new elements are described here. Postal-address information in 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: If two <contact:postalInfo> elements are defined for a contact object, one <contact:postalInfo> is the authoritative information from which other transformations (i.e. translations or transliterations) are derived, and the other <contact:postalInfo> is a transformation. One and only one <contact:postalInfo> element MUST be defined as authoritative.

The following common elements are used in this extension: <ird:country>, contains the name of the country in the <addr> element. A "lang" attribute contains the language identifier. Language identifiers MUST be structured as documented in . <ird:transliterationStd>, contains the transliteration standard used for the transformation. This element MUST only be present if the transformation is a transliteration.

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: An <ird:nameLang> element contains the language identifier of a <contact:name> element. An <ird:addrLang> element contains the language identifier of a <contact:addr> element. An OPTIONAL <ird:orgLang> element contains the language identifier of a <contact:org> element. An <ird:country> element, see definition in (see ). An OPTIONAL <ird:transliterationStd> element, see definition in (see ).

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: An <ird:id> element that contains the server-unique identifier of the <ird:additionalPostalInfo>. When adding a new <ird:additionalPostalInfo>, the <ird:id> element contains the desired server-unique identifier. A <ird:name> element that contains the transformation of <contact:name>. A "lang" attribute contains the language identifier. An OPTIONAL <ird:org> element that contains the transformation of <contact:org>. A "lang" attribute contains the language identifier. An <ird:addr> element that contains the transformation of <contact:addr>. A "lang" attribute contains the language identifier. A <ird:addr> contains the following child elements: One, two, or three OPTIONAL <ird:street> elements that contain the transformation of <contact:street>. A <ird:city> element that contains the transformation of <contact:city>. An OPTIONAL <ird:sp> element that contains the transformation of <contact:sp> An <ird:country> element, see definition in (see ). An OPTIONAL <ird:transliterationStd> element, see definition in (see ). An OPTIONAL <ird:disclose> is used by the client to identify elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. The <ird:disclose> element MUST contain a "flag" attribute. The "flag" attribute contains an XML Schema boolean value. A value of "true" or "1" (one) notes a client preference to allow disclosure of the specified elements as an exception to the stated data-collection policy. A value of "false" or "0" (zero) notes a client preference to not allow disclosure of the specified elements as an exception to the stated data-collection policy. The <ird:disclose> element MUST contain at least one of the following child elements: <ird:name /> <ird:org /> <ird:addr />

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification . 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 .

This extension does not add any elements to the EPP <info> command described in the EPP contact mapping . 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: One or two <ird:contactPostalInfo> elements. Zero or more OPTIONAL <ird:additionalPostalInfo> elements. Example <info> response:

S: S: S: S: Command completed successfully S: S: S: S: sh8013 S: SH8013-REP S: S: S: S: Иван Петрович Сидоров S: S: 8343 Драгатуш S: Бобруйск S: 20166-6503 S: RU S: S: S: S: Ivan Petrovich Sidorov S: S: 8343 Dragatush S: Babruysk S: 20166-6503 S: RU S: S: S: +1.7035555555 S: +1.7035555556 S: ivan@example.com S: ClientY S: ClientX S: 1999-04-03T22:00:00.0Z S: ClientX S: 1999-12-03T09:00:00.0Z S: 2000-04-08T09:00:00.0Z S: S: 2fooBAR S: S: S: S: S: S: S: S: S: S: S: ru S: ru S: Россия S: S: S: en S: en S: Russia S: S: S: sh8013-3 S: Ivan Petrovič Sidorov S: S: 8343 Dragatuš S: Bobrujsk S: 20166-6503 S: RU S: S: Rossiâ S: iso9 S: S: S: S: S: S: sh8013-4 S: Iván Petrovich Sidorov S: S: 8343 Dragatush S: Babruysk S: 20166-6503 S: RU S: S: Rusia S: S: S: S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: ]]>

This extension does not add any elements to the EPP <transfer> command or <check> response described in the EPP contact mapping .

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 . 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 , 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: One or two <ird:contactPostalInfo> elements. Zero or more OPTIONAL <ird:additionalPostalInfo> elements. Example <create> command:

C: C: C: C: C: sh8013 C: C: Иван Петрович Сидоров C: C: 8343 Драгатуш C: Бобруйск C: 20166-6503 C: RU C: C: C: C: Ivan Petrovich Sidorov C: C: 8343 Dragatush C: Babruysk C: 20166-6503 C: RU C: C: C: +1.7035555555 C: +1.7035555556 C: ivan@example.com C: C: 2fooBAR C: C: C: C: C: C: C: C: C: C: C: ru C: ru C: Россия C: C: C: en C: en C: Russia C: C: C: sh8013-3 C: Ivan Petrovič Sidorov C: C: 8343 Dragatuš C: Bobrujsk C: 20166-6503 C: RU C: C: Rossiâ C: iso9 C: C: C: C: C: C: sh8013-4 C: Iván Petrovich Sidorov C: C: 8343 Dragatush C: Babruysk C: 20166-6503 C: RU C: C: Rusia C: C: C: C: C: C: C: ABC-12345 C: C: ]]>

This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP contact mapping .

This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP contact mapping .

This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP contact mapping .

This extension defines additional elements for the EPP <update> command described in the EPP contact mapping . 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: An OPTIONAL <ird:add> element that is used to add IRD information to a contact object. The <ird:add> element MUST contain the following child elements: One or two <ird:contactPostalInfo> elements. Zero or more OPTIONAL <ird:additionalPostalInfo> elements. An OPTIONAL <ird:rem> element that is used to remove IRD information of a contact object. The <ird:rem> element MUST contain at least one of the following child elements: Zero or two OPTIONAL <ird:contactPostalInfoRem> elements the contains the type ("loc" or "int) of <ird:contactPostalInfo> to be removed. Zero or more OPTIONAL <ird:id> elements. Example of <update>:

C: C: C: C: C: sh8013 C: C: C: C: C: C: C: C: C: int C: sh8013-1 C: sh8013-2 C: C: C: C: ru C: ru C: Россия C: C: C: en C: en C: Russia C: C: C: sh8013-3 C: Ivan Petrovič Sidorov C: C: 8343 Dragatuš C: Bobrujsk C: 20166-6503 C: RU C: C: Rossiâ C: iso9 C: C: C: C: C: C: sh8013-4 C: Iván Petrovich Sidorov C: C: 8343 Dragatush C: Babruysk C: 20166-6503 C: RU C: C: Rusia C: C: C: C: C: C: C: C: ABC-12345 C: C: ]]>

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

Extensible Provisioning Protocol v1.0 contact extension schema for provisioning and management the transformation (i.e. transliteration or translation) of an entity object. END]]>

TBD.

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . Two URI assignments have been registered by the IANA. Registration request for the ird namespace: URI: urn:ietf:params:xml:ns:ird-1.0" Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the ird schema: URI: urn:ietf:params:xml:schema:ird-1.0" Registrant Contact: IESG XML: See the "Formal Syntax" section of this document.

The internationalization considerations of EPP described in apply to this specification as well.

The mapping extensions described in this document do not provide any security services beyond those described by EPP , the EPP contact mapping , and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.