RFC 5076

ENUM Validation Information Mapping for the Extensible Provisioning Protocol

📅 published December 2007, from ietf
part 1 of 4 💅 more parts coming, keep scrolling

RFC 5076: ENUM Validation Information Mapping for the Extensible Provisioning Protocol 🎀

Okay bestie, so this is RFC 5076 💖 It's from the Network Working Group, written by B. Hoeneisen of SWITCH, filed as Standards Track, and dated December 2007 🗓️

The title block here doesn't include an Obsoletes or Updates line, so there's nothing to list for either one 🙈

Status of This Memo 📜

So this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🥺 For the current standardization state and status, go check STD 1, the "Internet Official Protocol Standards" 📖 Distribution of this memo is unlimited, so share it with your friends ✨

Abstract 🦋

This RFC is an Extensible Provisioning Protocol (EPP) extension framework for mapping info about the validation process used on the E.164 number (or number range) that an E.164 Number Mapping (ENUM) domain name is based on 🔍 It's written in the Extensible Markup Language (XML), and it extends the EPP domain name mapping to add a feature needed for provisioning ENUM Domain Names 💅

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 🌸

So this doc describes a framework for an ENUM [2] validation information mapping for version 1.0 of EPP [3] 🧚 It's an extension of the EPP domain name mapping described in [4], written in XML 1.0 as described in [5], with XML Schema notation as described in [6] and [7] 🎀

The EPP core protocol spec [3] has the full tea on EPP command and response structures 🫖 You genuinely need a thorough understanding of the base protocol spec to get the mapping in this doc, so go read that first 🧠

ENUM [2] is all about how the Domain Name System (DNS) can identify services tied to an E.164 number 📞

As RFC 4725 [9] explains, usually only the Assignee of the E.164 number (or number range) gets to register the matching ENUM domain name 👑 So an ENUM validation process has to happen before that name goes 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) ✅ The nitty gritty of ENUM validation methods is beyond the scope of this document 🙃

This EPP extension is a framework for mapping info about the ENUM validation process 🗂️ Since local legislation or validation procedures may vary, the content of the validation information itself is not part of this specification 🤷‍♀️

BUT this doc has a working example (XML schema included) showing how the validation info could look 👀 The example could even be used for a lightweight validation process, and fr, it's been an integral part of the Swiss ENUM trial 🇨🇭

With this extension framework, the content of the validation information can be specified according to local requirements 💜 That kind of extension is specified in [10] ✨

If you want more background on validation, RFC 4725 [9] has it, and it 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 only there to illustrate element relationships, and they 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 💅

3. Requirements 📋

Here's the vibe checklist 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 extra elements to the EPP domain name mapping [4] 🎀 Only the new element descriptions are listed here, so no drama 💖

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 registry handles these four commands for validation info:

  • add: to add new validation information
  • rem: to revoke validation information
  • chg: to change stored validation information
  • inf: to get information about stored validation information

4.3. Id 🪪

The "id" attribute, used to identify the validation, is represented in this mapping as a character string 💜 It MUST be unique at least within the same ENUM Domain Name 🔐 To keep it unique even after an ENUM Domain Name gets transferred, it is RECOMMENDED that the "id" attribute be unique per ENUM Registry 🌸

The "id" attribute is usually assigned by the ENUM Registrar 🏷️ It is required for revoking or changing stored validation information, and it shows up in the Validation Information Command elements (see Section 4.2) 🫶

4.4. Validation Information 📦

The <validationInfo> element can contain any element that holds validation information and is documented adequately 🍓 It's represented in this mapping using the XML schema <any> element, so it's 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 of possible content for validation information, and it's 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 as 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 as 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 as a character string with a length of 3 to 16 characters 🔢 It contains an identifier assigned to the ENUM Registrar by the ENUM Registry 🎟️

4.5.4. Execution Date 📅

The <executionDate> element, which is 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, which is the expiration date of the validation, is represented in this mapping using the XML Schema 'date' data type 🥀

5. EPP Command Mapping 🎀

The detailed description of EPP syntax and semantics lives in the EPP core protocol specification [3], and the EPP domain name mapping is described in [4] 📚 The command mappings here are specifically for implementing ENUM validation information provisioning processes via EPP 💻

Note: Whether or not this extension is included in 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] 🫶 Nothing new to see here, so it's giving simple 💖

5.1.2. EPP <info> Command ✨

Okay bestie, this extension doesn't add anything to the <info> command itself 💅 The command is still described in the EPP domain mapping [4]. But it DOES add stuff to the <info> response, so let's get into it 🦋

When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP domain mapping [4]. On top of that, the EPP <extension> element MUST contain an <e164val:infData> element that identifies the extension namespace. The <e164val:infData> element holds one or more <e164val:inf> elements, each with an "id" attribute identifying the validation. Each <e164val:inf> element contains an <e164val:validationInfo> element, which holds the validation information as its child element 🎀

In the example below, the validation information is a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> element contains these child elements:

  • An <e164val:methodID> element that contains an identifier of the validation method.
  • An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
  • An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
  • An <e164val:executionDate> element that contains the date that the validation was performed.
  • An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.

Here's the <info> response example, and it's giving full EPP realness 🧚

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>
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 doesn't add any elements to the EPP <transfer> command or the <transfer> response. Both are described in the EPP domain mapping [4], and that's the whole story here 💖

5.2. EPP Transform Commands 🔥

EPP gives us 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. So many options, so little time 🌈

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 is a transform operation that lets a client 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 holds the validation information as its child element 💅

In the example below, the validation information is a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> element contains these child elements:

  • An <e164val:methodID> element that contains an identifier of the validation method.
  • An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
  • An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
  • An <e164val:executionDate> element that contains the date that the validation was performed.
  • An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.

Here's the <create> command example 🎀

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] ✨

5.2.2. EPP <delete> Command 🙈

This extension doesn't add any elements to the EPP <delete> command or the <delete> response. Both are 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 is a transform operation that lets a client 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 holds the validation information as its child element 🌸

In the example below, the validation information is a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains these child elements:

  • An <e164val:methodID> element that contains an identifier of the validation method.
  • An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
  • An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
  • An <e164val:executionDate> element that contains the date that the validation was performed.
  • An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.

Here's the <renew> command example, and it's so clean 🍓

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] 🦋

5.2.4. EPP <transfer> Command ✨

okay so this extension adds some extra bits to the EPP <transfer> command from the EPP domain mapping [4] 💅. The <transfer> response doesn't get any new elements, so that one stays exactly the same 🌸.

The <transfer> command is a transform operation that lets a client manage requests to transfer the sponsorship of a domain object. Clients can initiate, cancel, approve, and reject a transfer request 🦋.

For a transfer request, the command MUST contain an <extension> element on top of the usual EPP command elements from the EPP domain mapping [4] 🎀. The <extension> element MUST contain an <e164val:transfer> element that identifies the extension namespace. That <e164val:transfer> element holds one or more <e164val:add> elements, and each of those has an "id" attribute that identifies the validation. Every <e164val:add> element contains an <e164val:validationInfo> element, and that holds the validation information as its child element 🧚.

In the example below, the validation information is a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains these child elements:

  • An <e164val:methodID> element that contains an identifier of the validation method.
  • An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
  • An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
  • An <e164val:executionDate> element that contains the date that the validation was performed.
  • An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.

Here's the example for the <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 the one described in the EPP domain mapping [4] ✨.

5.2.5. EPP <update> Command 🎀

This extension adds some extra bits to the EPP <update> command from the EPP domain mapping [4], and the <update> response stays as it is 🌈. The <update> command is a transform operation that lets a client change the state of a domain object. On top of the EPP command elements from 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. That <e164val:update> element holds one or more <e164val:add>, <e164val:rem>, or <e164val:chg> elements, and each one has an "id" attribute that identifies the validation. Each <e164val:add> and <e164val:chg> element contains an <e164val:validationInfo> element, which holds the validation information as its child element. <e164val:rem> elements don't have any child elements 🙈.

In the example below, the validation information is a <valex:simpleVal> element that identifies the extension namespace. The <valex:simpleVal> contains these child elements:

  • An <e164val:methodID> element that contains an identifier of the validation method.
  • An OPTIONAL <e164val:validationEntityID> element that contains an identifier assigned to the ENUM Validation Entity.
  • An OPTIONAL <e164val:registrarID> element that contains an identifier assigned to the ENUM Registrar by the ENUM Registry.
  • An <e164val:executionDate> element that contains the date that the validation was performed.
  • An OPTIONAL <e164val:expirationDate> element that contains the date that the validation expires.

Here's the example for the <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 the one described in the EPP domain mapping [4] 💖.

6. Formal Syntax 👑

An EPP object mapping is specified in XML Schema notation. The schema below is a complete representation of the object mapping, made for automated validation of EPP XML instances 🤓. The BEGIN and END tags aren't part of the schemas. They just mark where the schema starts and ends, for URI registration purposes 🔥.

Here's the 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"

       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"
       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

And here's the 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">

<!--
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

7. IANA Considerations ✨

okay so this doc uses Uniform Resource Names (URNs) to describe XML namespaces and XML schemas, following the registry mechanism in RFC 3688 [8]. there are four URI assignments, and they're lowkey iconic 💅

  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 🙈

bestie, this one is serious, so read it carefully 🔥

The mapping extensions in this document don't add any security services beyond what EPP [3] and the EPP domain name mapping [4] already give you, plus whatever protocol layers EPP sits on. Security considerations for ENUM live in the "Security Considerations" section of the ENUM specification [2]. Everything those other specifications say applies here too, no exceptions ✨

Validation information often contains sensitive personal information 😭 It is RECOMMENDED that validation information in the <info> response is only provided to the sponsoring client.

9. Acknowledgements 🫶

the author wants to give a huge shoutout to the people who gave feedback or made significant contributions to this doc: Alfred Hoenes, Helena Malmborg, Alexander Mayrhofer, Andrew Newton, Marcel Parodi, Patrik Schaefer, and Patrick Zenklusen 🌸

RFC 4114 [11] was used as a template for this document. The structure, and the paragraphs that apply to both documents, were taken over from [11]. The author also thanks Scott Hollenbeck for doing the 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.

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/

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 on 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 on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt 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. 💜

📦 where this page comes from