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 Abstract 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. Status of This Memo 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 Notice 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 Lozano Expires January 8, 2017 [Page 1] Internet-Draft EPP Transformation of Contact Information July 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Object Elements . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 4 2.2. Postal Information Objects . . . . . . . . . . . . . . . 4 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 3.1. EPP Query commands . . . . . . . . . . . . . . . . . . . 6 3.2. EPP Transform commands . . . . . . . . . . . . . . . . . 9 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. ird Schema . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Internationalization Considerations . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction 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 Lozano Expires January 8, 2017 [Page 2] Internet-Draft EPP Transformation of Contact Information July 2016 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: o 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. 1.1. Terminology 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. 2. Object Elements 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: Lozano Expires January 8, 2017 [Page 3] Internet-Draft EPP Transformation of Contact Information July 2016 o If two elements are defined for a contact object, one is the authoritative information from which other transformations (i.e. translations or transliterations) are derived, and the other is a transformation. o One and only one element MUST be defined as authoritative. 2.1. Common Elements The following common elements are used in this extension: o , contains the name of the country in the element. A "lang" attribute contains the language identifier. Language identifiers MUST be structured as documented in [RFC5646]. o , contains the transliteration standard used for the transformation. This element MUST only be present if the transformation is a transliteration. 2.2. Postal Information Objects The following postal information objects are used in this extension: 2.2.1. Contact Postal Information The is used to specify the Internationalized Registration Data (IRD) information of the . A required "type" attribute is used to specify the relation to a 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 information. A required "authOrTransMechanism" attribute is used to define which of the two types ("loc" or "int") of is the authoritative information from which the transformations are derived. Alternatively, if the is not authoritative, then it has been transformed (i.e. "translation" or "transliteration"). The object contains the following child elements: o An element contains the language identifier of a element. Lozano Expires January 8, 2017 [Page 4] Internet-Draft EPP Transformation of Contact Information July 2016 o An element contains the language identifier of a element. o An OPTIONAL element contains the language identifier of a element. o An element, see definition in (see Section 2.1). o An OPTIONAL element, see definition in (see Section 2.1). 2.2.2. Additional Postal Information The is used to specify additional transformations of the authoritative 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 information. The object contains the following child elements: o An element that contains the server-unique identifier of the . When adding a new , the element contains the desired server-unique identifier. o A element that contains the transformation of . A "lang" attribute contains the language identifier. o An OPTIONAL element that contains the transformation of . A "lang" attribute contains the language identifier. o An element that contains the transformation of . A "lang" attribute contains the language identifier. A contains the following child elements: * One, two, or three OPTIONAL elements that contain the transformation of . * A element that contains the transformation of . Lozano Expires January 8, 2017 [Page 5] Internet-Draft EPP Transformation of Contact Information July 2016 * An OPTIONAL element that contains the transformation of o An element, see definition in (see Section 2.1). o An OPTIONAL element, see definition in (see Section 2.1). o An OPTIONAL is used by the client to identify elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. The 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 element MUST contain at least one of the following child elements: 3. EPP Command Mapping 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. 3.1. EPP Query commands EPP provides three commands to retrieve object information: to determine if an object is known to the server, to retrieve detailed information associated with an object, and to retrieve object transfer status information. 3.1.1. EPP command This extension does not add any elements to the EPP command or response described in the EPP contact mapping [RFC5733]. Lozano Expires January 8, 2017 [Page 6] Internet-Draft EPP Transformation of Contact Information July 2016 3.1.2. EPP command This extension does not add any elements to the EPP command described in the EPP contact mapping [RFC5733]. However, additional elements are defined for the response. When an command has been processed successfully the EPP element MUST contain a child element. The element contains the following child elements: One or two elements. Zero or more OPTIONAL elements. Example response: S: 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 Lozano Expires January 8, 2017 [Page 7] Internet-Draft EPP Transformation of Contact Information July 2016 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 Dragatus S: Bobrujsk S: 20166-6503 S: RU S: S: Rossia S: iso9 S: S: S: Lozano Expires January 8, 2017 [Page 8] Internet-Draft EPP Transformation of Contact Information July 2016 S: S: S: sh8013-4 S: Ivan 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: 3.1.3. EPP command This extension does not add any elements to the EPP command or response described in the EPP contact mapping [RFC5733]. 3.2. EPP Transform commands EPP provides five commands to transform objects: to create an instance of an object, to delete an instance of an object, to extend the validity period of an object, to manage object sponsorship changes, and to change information associated with an object. 3.2.1. EPP command This extension defines additional elements for the EPP command described in the EPP contact mapping [RFC5733]. When a command that includes this extension has been processed successfully, the response MUST include this EPP with a child element. Lozano Expires January 8, 2017 [Page 9] Internet-Draft EPP Transformation of Contact Information July 2016 The EPP 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 element, and the element MUST contain a child element that identifies the extension namespace if the client wants to associate data defined in this extension to the contact object. The element contains the following child elements: One or two elements. Zero or more OPTIONAL elements. Example command: C: 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: Lozano Expires January 8, 2017 [Page 10] Internet-Draft EPP Transformation of Contact Information July 2016 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 Dragatus C: Bobrujsk C: 20166-6503 C: RU C: C: Rossia C: iso9 C: C: C: C: C: C: sh8013-4 C: Ivan Petrovich Sidorov C: C: 8343 Dragatush C: Babruysk C: 20166-6503 C: RU C: C: Rusia C: C: Lozano Expires January 8, 2017 [Page 11] Internet-Draft EPP Transformation of Contact Information July 2016 C: C: C: C: C: ABC-12345 C: C: 3.2.2. EPP command This extension does not add any elements to the EPP command or response described in the EPP contact mapping [RFC5733]. 3.2.3. EPP command This extension does not add any elements to the EPP command or response described in the EPP contact mapping [RFC5733]. 3.2.4. EPP command This extension does not add any elements to the EPP command or response described in the EPP contact mapping [RFC5733]. 3.2.5. EPP command This extension defines additional elements for the EPP command described in the EPP contact mapping [RFC5733]. When an command that includes this extension has been processed successfully, the response MUST include this EPP with a child element. The EPP 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 element, and the element MUST contain a child element that identifies the extension namespace if the client wants to update the contact object with data defined in this extension. The element contains a element to add ird information or, a element to remove ird information. The order of the and elements is significant, where the server MUST first remove the existing elements prior to adding the new elements. The element contains the following child elements: Lozano Expires January 8, 2017 [Page 12] Internet-Draft EPP Transformation of Contact Information July 2016 An OPTIONAL element that is used to add IRD information to a contact object. The element MUST contain the following child elements: One or two elements. Zero or more OPTIONAL elements. An OPTIONAL element that is used to remove IRD information of a contact object. The element MUST contain at least one of the following child elements: Zero or two OPTIONAL elements the contains the type ("loc" or "int) of to be removed. Zero or more OPTIONAL elements. Example of : C: 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 Dragatus C: Bobrujsk C: 20166-6503 C: RU C: C: Rossia C: iso9 C: C: C: C: C: C: sh8013-4 C: Ivan 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: 4. Formal Syntax An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of Lozano Expires January 8, 2017 [Page 14] Internet-Draft EPP Transformation of Contact Information July 2016 the object mapping suitable for automated validation of EPP XML instances. 4.1. ird Schema 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 Extensible Provisioning Protocol v1.0 contact extension schema for provisioning and management the transformation (i.e. transliteration or translation) of an entity object. Lozano Expires January 8, 2017 [Page 17] Internet-Draft EPP Transformation of Contact Information July 2016 END 5. Acknowledgements TBD. Lozano Expires January 8, 2017 [Page 18] Internet-Draft EPP Transformation of Contact Information July 2016 6. IANA Considerations 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: 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. 7. Internationalization Considerations The internationalization considerations of EPP described in [RFC5730] apply to this specification as well. 8. Security Considerations 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. 9. References 9.1. Normative References [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, . Lozano Expires January 8, 2017 [Page 19] Internet-Draft EPP Transformation of Contact Information July 2016 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, March 2004, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "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, . 9.2. Informative References [TTOCI] ICANN, "Final Report on the Translation and Transliteration of Contact Information Policy Development Process", June 2015, . Author's Address Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles 90292 US Phone: +1.3103015800 Email: gustavo.lozano@icann.org Lozano Expires January 8, 2017 [Page 20]