Network Working Group B. Hoeneisen Request for Comments: 5076 SWITCH Category: Standards Track December 2007
ENUM Validation Information Mapping for the Extensible Provisioning Protocol
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names.
Hoeneisen Standards Track [Page 1]
RFC 5076 ENUM Validation Mapping for EPP December 2007
This document describes a framework for an ENUM [2] validation information mapping for version 1.0 of EPP [3]. This mapping, an extension of the EPP domain name mapping described in [4], is specified using XML 1.0, as described in [5], and XML Schema notation, as described in [6] and [7].
The EPP core protocol specification [3] 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.
Hoeneisen Standards Track [Page 2]
RFC 5076 ENUM Validation Mapping for EPP December 2007
ENUM [2] describes how the Domain Name System (DNS) can be used to identify services associated with an E.164 number.
As described in RFC 4725 [9], usually only the Assignee of the E.164 number (or number range) has the right to register the corresponding ENUM domain name. Therefore, an ENUM validation process has to be applied before the ENUM domain name can be inserted into the DNS. The validation process shall ensure that the holder of the ENUM domain name coincides with the Assignee of the corresponding E.164 number (or number range). However, the details of the ENUM validation methods are beyond the scope of this document.
The EPP extension described in this document specifies a framework for the mapping of information about the ENUM validation process. As the local legislation or the validation procedures may vary, the content of the validation information itself is not part of this specification.
However, this document contains a working example (including XML schema) to show how the validation information could look. This example could even be used for a lightweight validation process. In fact, it has been an integral part of the Swiss ENUM trial.
Using this extension framework, the content of the validation information can be specified according to the local requirements. Such an extension is specified in [10].
More background information concerning the validation can be found in RFC 4725 [9], which also describes a typical basic role model for the ENUM registration process.
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 [1].
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 are provided only to illustrate element relationships and are not REQUIRED features of this specification.
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.
Hoeneisen Standards Track [Page 3]
RFC 5076 ENUM Validation Mapping for EPP December 2007
An ENUM Domain Name is a representation of an E.164 number that has been translated to conform to domain name syntax as described in the ENUM specification [2].
The "id" attribute, used to identify the validation, is represented in this mapping using a character string. It MUST be unique at least within the same ENUM Domain Name. To ensure uniqueness even after a transfer of an ENUM Domain Name, it is RECOMMENDED that the "id" attribute be unique per ENUM Registry.
Hoeneisen Standards Track [Page 4]
RFC 5076 ENUM Validation Mapping for EPP December 2007
The "id" attribute, usually assigned by the ENUM Registrar, is required for revoking or changing stored validation information and appears in the Validation Information Command elements (see Section 4.2).
The <validationInfo> element can contain any element containing validation information that is documented adequately. It is represented in this mapping using the XML schema <any> element and therefore, is extensible.
The number of <validationInfo> elements permitted per domain object is subject to local policy.
As described above, this document includes an example for a possible content of validation information that is used in the EPP examples throughout this document.
This example is an optional part of this specification, i.e., a fully compliant RFC 5076 implementation does not need to implement this example.
The <methodID> element is represented in this mapping using a character string with a maximum length of 63 characters. It contains an identifier for the method used for the validation. As stated in Section 1, the details of the ENUM validation methods are beyond the scope of this document.
The <validationEntityID> element is represented in this mapping using a character string with a length of 3 to 16 characters. It contains an identifier assigned to the ENUM Validation Entity, e.g., by the ENUM Registry.
The <registrarID> element is represented in this mapping using a character string with a length of 3 to 16 characters. It contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
Hoeneisen Standards Track [Page 5]
RFC 5076 ENUM Validation Mapping for EPP December 2007
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [3], and the EPP domain name mapping is described in [4]. The command mappings described here are specifically for use in implementing ENUM validation information provisioning processes via EPP.
Note: Whether or not this extension is included into an EPP request or response depends on local policy. For example, a local Registry policy might require the use of this extension for EPP <create>, <update>, and <info> commands, but not support it for EPP <transfer> and <renew> commands. Therefore, this is beyond the scope of this document.
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 <info> command described in the EPP domain mapping [4]. Additional elements are defined for the <info> response.
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [4]. In addition, the EPP <extension> element MUST contain an <e164val:infData> element that identifies the extension namespace. The <e164val:infData> element contains one or more
Hoeneisen Standards Track [Page 6]
RFC 5076 ENUM Validation Mapping for EPP December 2007
<e164val:inf> elements, each with an "id" attribute identifying the validation. Each <e164val:inf> element contains an <e164val: validationInfo> element, which contains the validation information as child element.
In the example below, the validation information consists of a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> element contains the following child elements:
o An <e164val:methodID> element that contains an identifier of the validation method.
o An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
o An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
o An <e164val:executionDate> element that contains the date that the validation was performed.
o An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.
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 domain mapping [4]. No additional elements are defined for the EPP <create> response.
The EPP <create> command provides a transform operation that allows a client to create a domain object. In addition to the EPP command elements described in the EPP domain mapping [4], the command MUST contain an <extension> element. The <extension> element MUST contain an <e164val:create> element that identifies the extension namespace. The <e164val:create> element contains one or more <e164val:add> elements, each with an "id" attribute identifying the validation. Each <e164val:add> element contains an <e164val:validationInfo> element, which contains the validation information as child element.
In the example below, the validation information consists of a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> element contains the following child elements:
o An <e164val:methodID> element that contains an identifier of the validation method.
o An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
o An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
o An <e164val:executionDate> element that contains the date that the validation was performed.
o An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.
Hoeneisen Standards Track [Page 9]
RFC 5076 ENUM Validation Mapping for EPP December 2007
This extension defines additional elements for the EPP <renew> command described in the EPP domain mapping [4]. No additional elements are defined for the EPP <renew> response.
The EPP <renew> command provides a transform operation that allows a client to extend the validity period of a domain object. In addition to the EPP command elements described in the EPP domain mapping [4], the <renew> command MUST contain an <extension> element. The <extension> element MUST contain an <e164val:renew> element that identifies the extension namespace. The <e164val:renew> element contains one or more <e164val:add> elements, each with an "id" attribute identifying the validation. Each <e164val:add> element contains an <e164val:validationInfo> element, which contains the validation information as child element.
In the example below, the validation information consists of a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains the following child elements:
o An <e164val:methodID> element that contains an identifier of the validation method.
o An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
o An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
o An <e164val:executionDate> element that contains the date that the validation was performed.
o An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.
Hoeneisen Standards Track [Page 11]
RFC 5076 ENUM Validation Mapping for EPP December 2007
This extension defines additional elements for the EPP <transfer> command described in the EPP domain mapping [4]. No additional elements are defined for the EPP <transfer> response.
The EPP <transfer> command provides a transform operation that allows a client to manage requests to transfer the sponsorship of a domain object. Clients can initiate, cancel, approve, and reject a transfer request.
In case of a transfer request, in addition to the EPP command elements described in the EPP domain mapping [4], the command MUST contain an <extension> element. The <extension> element MUST contain an <e164val:transfer> element that identifies the extension namespace. The <e164val:transfer> element contains one or more <e164val:add> elements, each with an "id" attribute identifying the validation. Each <e164val:add> element contains an <e164val: validationInfo> element, which contains the validation information as child element.
In the example below, the validation information consists of a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains the following child elements:
o An <e164val:methodID> element that contains an identifier of the validation method.
o An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
o An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
o An <e164val:executionDate> element that contains the date that the validation was performed.
o An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.
Hoeneisen Standards Track [Page 13]
RFC 5076 ENUM Validation Mapping for EPP December 2007
This extension defines additional elements for the EPP <update> command described in the EPP domain mapping [4]. No additional elements are defined for the EPP <update> response. The EPP <update> command provides a transform operation that allows a client to change the state of a domain object. In addition to the EPP command elements described in the EPP domain mapping [4], the <update> command MUST contain an <extension> element. The <extension> element MUST contain an <e164val:update> element that identifies the extension namespace. The <e164val:update> element contains one or more <e164val:add>, <e164val:rem>, or <e164val:chg> elements, each with an "id" attribute identifying the validation. Each <e164val:add> and <e164val:chg> element contains an <e164val: validationInfo> element, which contains the validation information as child element. <e164val:rem> elements do not have child elements.
In the example below, the validation information consists of a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains the following child elements:
o An <e164val:methodID> element that contains an identifier of the validation method.
o An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
o An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
o An <e164val:executionDate> element that contains the date that the validation was performed.
o An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.
Hoeneisen Standards Track [Page 15]
RFC 5076 ENUM Validation Mapping for EPP December 2007
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 schemas; they are used to note the beginning and ending of the schema for URI registration purposes.
Hoeneisen Standards Track [Page 16]
RFC 5076 ENUM Validation Mapping for EPP December 2007
Formal syntax for Framework:
BEGIN <?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:ietf:params:xml:ns:e164val-1.0" xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<!-- Import common element types. --> <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" schemaLocation="eppcom-1.0.xsd"/>
<annotation> <documentation> Extensible Provisioning Protocol v1.0 domain name extension schema for framework for provisioning of E.164 number validation information. </documentation> </annotation>
<!-- Child elements found in EPP commands. --> <element name="create" type="e164val:insertType"/> <element name="update" type="e164val:updateType"/> <element name="renew" type="e164val:insertType"/> <element name="transfer" type="e164val:insertType"/>
<!-- Child elements of the <create>, <renew>, and <update> commands. --> <complexType name="insertType"> <sequence> <element name="add" type="e164val:addType" maxOccurs="unbounded" /> </sequence> </complexType>
<!-- Child elements of the <update> command. --> <complexType name="updateType"> <sequence> <element name="add" type="e164val:addType"
Hoeneisen Standards Track [Page 17]
RFC 5076 ENUM Validation Mapping for EPP December 2007
<!-- Data elements for add, chg and rem. --> <complexType name="addType"> <sequence> <element ref="e164val:validationInfo"/> </sequence> <attribute name="id" type="eppcom:minTokenType" use="required"/> </complexType>
This document uses Uniform Resource Names (URNs) to describe XML namespaces and XML schemas conforming to the registry mechanism described in RFC 3688 [8]. Four URI assignments have been made:
1. Registration for the extension namespace: * URI: urn:ietf:params:xml:ns:e164val-1.0 * Registrant Contact: See the "Author's Address" section of this document. * XML: None. Namespace URIs do not represent an XML specification.
2. Registration for the extension XML schema: * URI: urn:ietf:params:xml:schema:e164val-1.0 * Registrant Contact: See the "Author's Address" section of this document. * XML: See Section 6, "Formal Syntax", of this document.
3. Registration for the extension namespace: * URI: urn:ietf:params:xml:ns:e164valex-1.1 * Registrant Contact: See the "Author's Address" section of this document. * XML: None. Namespace URIs do not represent an XML specification.
4. Registration for the extension XML schema: * URI: urn:ietf:params:xml:schema:e164valex-1.1 * Registrant Contact: See the "Author's Address" section of this document. * XML: See Section 6, "Formal Syntax", of this document.
The mapping extensions described in this document do not provide any security services beyond those described by EPP [3], the EPP domain name mapping [4], and protocol layers used by EPP. Security considerations related to ENUM are described in the "Security Considerations" section of the ENUM specification [2]. The security considerations described in these other specifications apply to this specification as well.
Validation information often contains sensitive personal information. It is RECOMMENDED that validation information in the <info> response is only provided to the sponsoring client.
Hoeneisen Standards Track [Page 21]
RFC 5076 ENUM Validation Mapping for EPP December 2007
The author would like to thank the following people who have provided feedback or significant contributions to the development of this document: Alfred Hoenes, Helena Malmborg, Alexander Mayrhofer, Andrew Newton, Marcel Parodi, Patrik Schaefer, and Patrick Zenklusen.
RFC 4114 [11] has been used as a template for this document. The structure and those paragraphs that apply to both documents have been taken over from [11]. The author would like to thank Scott Hollenbeck for this great spadework.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[4] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[5] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[6] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[7] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC- xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
Hoeneisen Standards Track [Page 22]
RFC 5076 ENUM Validation Mapping for EPP December 2007
RFC 5076 ENUM Validation Mapping for EPP December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.