diff options
Diffstat (limited to 'doc/rfc/rfc5076.txt')
| -rw-r--r-- | doc/rfc/rfc5076.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc5076.txt b/doc/rfc/rfc5076.txt new file mode 100644 index 0000000..ff571f9 --- /dev/null +++ b/doc/rfc/rfc5076.txt @@ -0,0 +1,1347 @@ + + + + + + +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 + + +Table of Contents + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Requirements ....................................................4 + 4. Object Attributes ...............................................4 + 4.1. ENUM Domain Names ..........................................4 + 4.2. Validation Information Commands ............................4 + 4.3. Id .........................................................4 + 4.4. Validation Information .....................................5 + 4.5. Validation Elements in the Example .........................5 + 4.5.1. Method Identifier ...................................5 + 4.5.2. Validation Entity Identifier ........................5 + 4.5.3. Registrar Identifier ................................5 + 4.5.4. Execution Date ......................................6 + 4.5.5. Expiration Date .....................................6 + 5. EPP Command Mapping .............................................6 + 5.1. EPP Query Commands .........................................6 + 5.1.1. EPP <check> Command .................................6 + 5.1.2. EPP <info> Command ..................................6 + 5.1.3. EPP <transfer> Command ..............................8 + 5.2. EPP Transform Commands .....................................9 + 5.2.1. EPP <create> Command ................................9 + 5.2.2. EPP <delete> Command ...............................11 + 5.2.3. EPP <renew> Command ................................11 + 5.2.4. EPP <transfer> Command .............................13 + 5.2.5. EPP <update> Command ...............................15 + 6. Formal Syntax ..................................................16 + 7. IANA Considerations ............................................21 + 8. Security Considerations ........................................21 + 9. Acknowledgements ...............................................22 + 10. References ....................................................22 + 10.1. Normative References .....................................22 + 10.2. Informative References ...................................23 + +1. Introduction + + 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. + +2. 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 [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 + + +3. Requirements + + The following requirements are the basis for this work: + + 1. The design shall allow multiple policies and validation + procedures. + + 2. It shall be possible to transmit validation information with EPP + domain object requests and responses. + + 3. It shall be possible to add, modify, and remove validation + information. + + 4. It shall be possible to retrieve validation information stored in + the ENUM Registry. + +4. Object Attributes + + This extension adds additional elements to the EPP domain name + mapping [4]. Only new element descriptions are listed here. + +4.1. ENUM Domain Names + + 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]. + +4.2. Validation Information Commands + + The following commands are defined for handling validation + information at the registry: + + o add: to add new validation information + + o rem: to revoke validation information + + o chg: to change stored validation information + + o inf: to get information about stored validation information + +4.3. Id + + 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). + +4.4. Validation Information + + 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. + +4.5. Validation Elements in the Example + + 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. + +4.5.1. Method Identifier + + 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. + +4.5.2. Validation Entity Identifier + + 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. + +4.5.3. Registrar Identifier + + 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 + + +4.5.4. Execution Date + + The <executionDate> element, the execution date of the validation, is + represented in this mapping using the XML Schema 'date' data type. + +4.5.5. Expiration Date + + The <expirationDate> element, the expiration date of the validation, + is represented in this mapping using the XML Schema 'date' data type. + +5. EPP Command Mapping + + 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. + +5.1. EPP Query Commands + + 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. + +5.1.1. EPP <check> Command + + This extension does not add any elements to the EPP <check> command + or <check> response described in the EPP domain mapping [4]. + +5.1.2. EPP <info> Command + + 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. + + Example for <info> 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: <response> + S: <result code="1000"> + S: <msg>Command completed successfully</msg> + S: </result> + S: <resData> + S: <domain:infData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> + S: <domain:roid>EXAMPLE1-REP</domain:roid> + S: <domain:status s="ok"/> + S: <domain:registrant>jd1234</domain:registrant> + S: <domain:contact type="admin">sh8013</domain:contact> + S: <domain:contact type="tech">sh8013</domain:contact> + S: <domain:ns> + S: <domain:hostObj>ns1.example.com</domain:hostObj> + S: <domain:hostObj>ns2.example.com</domain:hostObj> + S: </domain:ns> + S: <domain:clID>ClientX</domain:clID> + S: <domain:crID>ClientY</domain:crID> + + + +Hoeneisen Standards Track [Page 7] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> + S: <domain:upID>ClientX</domain:upID> + S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> + S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> + S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> + S: <domain:authInfo> + S: <domain:pw>2fooBAR</domain:pw> + S: </domain:authInfo> + S: </domain:infData> + S: </resData> + S: <extension> + S: <e164val:infData + S: xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0"> + S: <e164val:inf id="EK77"> + S: <e164val:validationInfo> + S: <valex:simpleVal + S: xmlns:valex="urn:ietf:params:xml:ns:e164valex-1.1"> + S: <valex:methodID>Validation-X</valex:methodID> + S: <valex:validationEntityID>VE-NMQ</valex:validationEntityID> + S: <valex:registrarID>Client-X</valex:registrarID> + S: <valex:executionDate>2004-04-08</valex:executionDate> + S: <valex:expirationDate>2004-10-07</valex:expirationDate> + S: </valex:simpleVal> + S: </e164val:validationInfo> + S: </e164val:inf> + S: </e164val:infData> + S: </extension> + S: <trID> + S: <clTRID>ABC-23456</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S:</epp> + + Figure 1 + +5.1.3. EPP <transfer> Command + + This extension does not add any elements to the EPP <transfer> + command or <transfer> response described in the EPP domain mapping + [4]. + + + + + + + + + + +Hoeneisen Standards Track [Page 8] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2. EPP Transform Commands + + 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. + +5.2.1. EPP <create> Command + + 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 + + + Example for <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: <command> + C: <create> + C: <domain:create + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> + C: <domain:period unit="y">1</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.com</domain:hostObj> + C: <domain:hostObj>ns2.example.com</domain:hostObj> + C: </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: </create> + C: <extension> + C: <e164val:create + C: xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0"> + C: <e164val:add id="EK77"> + C: <e164val:validationInfo> + C: <valex:simpleVal + C: xmlns:valex="urn:ietf:params:xml:ns:e164valex-1.1"> + C: <valex:methodID>Validation-X</valex:methodID> + C: <valex:validationEntityID>VE-NMQ</valex:validationEntityID> + C: <valex:registrarID>Client-X</valex:registrarID> + C: <valex:executionDate>2004-04-08</valex:executionDate> + C: <valex:expirationDate>2004-10-07</valex:expirationDate> + C: </valex:simpleVal> + C: </e164val:validationInfo> + C: </e164val:add> + C: </e164val:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C:</epp> + + Figure 2 + + When an extended <create> command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + + + +Hoeneisen Standards Track [Page 10] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.2. EPP <delete> Command + + This extension does not add any elements to the EPP <delete> command + or <delete> response described in the EPP domain mapping [4]. + +5.2.3. EPP <renew> Command + + 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 + + + Example for <renew> 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: <command> + C: <renew> + C: <domain:renew + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> + C: <domain:curExpDate>2005-04-09</domain:curExpDate> + C: <domain:period unit="y">1</domain:period> + C: </domain:renew> + C: </renew> + C: <extension> + C: <e164val:renew + C: xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0"> + C: <e164val:add id="CAB176"> + C: <e164val:validationInfo> + C: <valex:simpleVal + C: xmlns:valex="urn:ietf:params:xml:ns:e164valex-1.1"> + C: <valex:methodID>Validation-X</valex:methodID> + C: <valex:validationEntityID>VE-NMQ</valex:validationEntityID> + C: <valex:registrarID>Client-X</valex:registrarID> + C: <valex:executionDate>2005-03-30</valex:executionDate> + C: <valex:expirationDate>2005-09-29</valex:expirationDate> + C: </valex:simpleVal> + C: </e164val:validationInfo> + C: </e164val:add> + C: </e164val:renew> + C: </extension> + C: <clTRID>ABC-45678</clTRID> + C: </command> + C:</epp> + + Figure 3 + + When an extended <renew> command has been processed successfully, the + EPP response is as described in the EPP domain mapping [4]. + + + + + + + + + + + + +Hoeneisen Standards Track [Page 12] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.4. EPP <transfer> Command + + 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 + + + Example for <transfer> 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: <command> + C: <transfer op="request"> + C: <domain:transfer + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> + C: <domain:authInfo> + C: <domain:pw roid="HB1973-ZUE">2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:transfer> + C: </transfer> + C: <extension> + C: <e164val:transfer + C: xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0"> + C: <e164val:add id="LJ1126"> + C: <e164val:validationInfo> + C: <valex:simpleVal + C: xmlns:valex="urn:ietf:params:xml:ns:e164valex-1.1"> + C: <valex:methodID>Validation-Y</valex:methodID> + C: <valex:validationEntityID>VE2-LMQ</valex:validationEntityID> + C: <valex:registrarID>Client-Y</valex:registrarID> + C: <valex:executionDate>2005-01-22</valex:executionDate> + C: <valex:expirationDate>2005-07-21</valex:expirationDate> + C: </valex:simpleVal> + C: </e164val:validationInfo> + C: </e164val:add> + C: </e164val:transfer> + C: </extension> + C: <clTRID>XYZ-54789</clTRID> + C: </command> + C:</epp> + + Figure 4 + + When an extended <transfer> command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + + + + + + + + + + + +Hoeneisen Standards Track [Page 14] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +5.2.5. EPP <update> Command + + 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 + + + Example for <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: <command> + C: <update> + C: <domain:update + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> + C: </domain:update> + C: </update> + C: <extension> + C: <e164val:update + C: xmlns:e164val="urn:ietf:params:xml:ns:e164val-1.0"> + C: <e164val:add id="EK2510"> + C: <e164val:validationInfo> + C: <valex:simpleVal + C: xmlns:valex="urn:ietf:params:xml:ns:e164valex-1.1"> + C: <valex:methodID>Validation-X</valex:methodID> + C: <valex:validationEntityID>VE-NMQ</valex:validationEntityID> + C: <valex:registrarID>Client-X</valex:registrarID> + C: <valex:executionDate>2004-10-02</valex:executionDate> + C: <valex:expirationDate>2005-04-01</valex:expirationDate> + C: </valex:simpleVal> + C: </e164val:validationInfo> + C: </e164val:add> + C: <e164val:rem id="EK77"/> + C: </e164val:update> + C: </extension> + C: <clTRID>ABC-34567</clTRID> + C: </command> + C:</epp> + + Figure 5 + + When an extended <update> command has been processed successfully, + the EPP response is as described in the EPP domain mapping [4]. + +6. 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 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 + + + minOccurs="0" + maxOccurs="unbounded"/> + <element name="rem" type="e164val:remType" + minOccurs="0" + maxOccurs="unbounded"/> + <element name="chg" type="e164val:chgType" + minOccurs="0" + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <!-- + 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> + + <complexType name="chgType"> + <sequence> + <element ref="e164val:validationInfo"/> + </sequence> + <attribute name="id" type="eppcom:minTokenType" + use="required"/> + </complexType> + + <complexType name="remType"> + <attribute name="id" type="eppcom:minTokenType" + use="required"/> + </complexType> + + + <!-- + Child elements found in EPP responses + --> + <element name="infData" type="e164val:infDataType"/> + + <!-- + child elements of the <info> response. + --> + <complexType name="infDataType"> + <sequence> + <element name="inf" type="e164val:infType" + minOccurs="0" + + + +Hoeneisen Standards Track [Page 18] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + maxOccurs="unbounded"/> + </sequence> + </complexType> + + <!-- + Data elements for inf + --> + <complexType name="infType"> + <sequence> + <element ref="e164val:validationInfo"/> + </sequence> + <attribute name="id" type="eppcom:minTokenType" + use="required"/> + </complexType> + + <!-- + Global elements. + --> + <element name="validationInfo" type="e164val:ValidationInfoType" /> + + <!-- + Extension framework types. + --> + <complexType name="ValidationInfoType"> + <sequence> + <any namespace="##other"/> + </sequence> + </complexType> + + + <!-- + End of schema. + --> + </schema> + END + + Figure 6 + + Formal syntax for a simple validation (example): + + BEGIN + <?xml version="1.0" encoding="UTF-8"?> + <schema targetNamespace="urn:ietf:params:xml:ns:e164valex-1.1" + xmlns:e164valex="urn:ietf:params:xml:ns:e164valex-1.1" + xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" + xmlns="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified"> + + + + +Hoeneisen Standards Track [Page 19] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + + <!-- + Import common element types. + --> + <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" + schemaLocation="eppcom-1.0.xsd"/> + + <annotation> + <documentation> + Example for E.164 number validation information. + </documentation> + </annotation> + + + <element name="simpleVal" type="e164valex:simpleValType"/> + + <complexType name="simpleValType"> + <sequence> + <element name="methodID" type="e164valex:methodIdType"/> + <element name="validationEntityID" type="eppcom:clIDType" + minOccurs="0"/> + <element name="registrarID" type="eppcom:clIDType" + minOccurs="0"/> + <element name="executionDate" type="date"/> + <element name="expirationDate" type="date" + minOccurs="0"/> + </sequence> + </complexType> + + <simpleType name="methodIdType"> + <restriction base="token"> + <minLength value="1"/> + <maxLength value="63"/> + </restriction> + </simpleType> + + <!-- + End of schema. + --> + </schema> + END + + Figure 7 + + + + + + + + + +Hoeneisen Standards Track [Page 20] + +RFC 5076 ENUM Validation Mapping for EPP December 2007 + + +7. IANA Considerations + + 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. + +8. Security Considerations + + 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 + + +9. Acknowledgements + + 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. + +10. References + +10.1. Normative References + + [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. + + [3] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC + 3730, March 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 + + +10.2. Informative References + + [9] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation + Architecture", RFC 4725, November 2006. + + [10] Lendl, O., "ENUM Validation Token Format Definition", Work in + Progress. + + [11] Hollenbeck, S., "E.164 Number Mapping for the Extensible + Provisioning Protocol (EPP)", RFC 4114, June 2005. + +Author's Address + + Bernie Hoeneisen + SWITCH + Werdstrasse 2 + CH-8004 Zuerich + Switzerland + + Phone: +41 44 268 1515 + EMail: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch + URI: http://www.switch.ch/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoeneisen Standards Track [Page 23] + +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. + + + + + + + + + + + + +Hoeneisen Standards Track [Page 24] + |