ENUM Validation Information Mapping for the Extensible Provisioning Protocol
Extracted elements (25)
An example validation schema (`e164valex-1.1`) is included as an optional, non-normative part of the specification to demonstrate one possible lightweight validation process; a fully compliant RFC 5076 implementation does not need to implement this example, and it was originally used in the Swiss ENUM trial.
The design allows multiple validation policies and procedures simultaneously, and permits adding, modifying, removing, and retrieving validation information independently, reflecting that ENUM registries may use different validation methods and that validation data has its own lifecycle separate from the domain object.
The `<validationInfo>` element uses the XML Schema `<any>` wildcard rather than a fixed content model so that the content of validation information can be specified according to local requirements, accommodating varying local legislation and validation procedures without modifying this specification.
The `<check>` command, `<delete>` command, and `<transfer>` query command are explicitly not extended by this specification; no additional elements are defined for those commands or their responses.
Whether or not the e164val extension is included in an EPP request or response depends on local registry policy. A registry may require it for `<create>`, `<update>`, and `<info>` commands but not support it for `<transfer>` and `<renew>` commands; this policy determination is outside the scope of this document.
For a transfer request, the EPP `<transfer>` command MUST contain an `<extension>` element with an `<e164val:transfer>` element holding one or more `<e164val:add>` elements, each identified by an `id` attribute.
It is RECOMMENDED that the `id` attribute be unique per ENUM Registry to ensure uniqueness even after a transfer of an ENUM Domain Name to a different registrar.
The EPP `<create>` command MUST contain an `<extension>` element, and that `<extension>` element MUST contain an `<e164val:create>` element identifying the extension namespace, with one or more `<e164val:add>` child elements each bearing an `id` attribute.
The EPP `<renew>` command MUST contain an `<extension>` element with an `<e164val:renew>` element that in turn holds one or more `<e164val:add>` elements, each with an `id` attribute and a `<validationInfo>` child.
The EPP `<update>` command MUST contain an `<extension>` element with an `<e164val:update>` element holding one or more `<e164val:add>`, `<e164val:rem>`, or `<e164val:chg>` elements each identified by an `id` attribute; `<rem>` elements carry no child elements.
The `id` attribute MUST be unique at least within the same ENUM Domain Name to avoid identifier collisions among validation records for that domain.
When an `<info>` command has been processed successfully, the EPP `<resData>` element MUST contain child elements as described in the EPP domain mapping, and the EPP `<extension>` element MUST contain an `<e164val:infData>` element identifying the extension namespace.
XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation, because XML is case sensitive.
Four validation information commands are defined: `add` (add new validation information), `rem` (revoke validation information), `chg` (change stored validation information), and `inf` (retrieve stored validation information).
The e164val EPP extension framework provides a mechanism for mapping ENUM validation information within EPP domain object operations. It extends the EPP domain name mapping (RFC 3731) to carry proof that the holder of an ENUM domain name coincides with the Assignee of the corresponding E.164 number or number range.
The `id` attribute identifies each validation record within a domain object and is represented as a character string. It is required for revoking or changing stored validation information and appears in the Validation Information Command elements (add, rem, chg).
The `<validationInfo>` element is the extensible container for validation data, defined using the XML Schema `<any>` element to permit any well-documented child namespace. The number of `<validationInfo>` elements permitted per domain object is subject to local policy.
This document registers four URIs in the IETF XML Registry (RFC 3688): the framework extension namespace `urn:ietf:params:xml:ns:e164val-1.0`, the framework XML schema `urn:ietf:params:xml:schema:e164val-1.0`, the example namespace `urn:ietf:params:xml:ns:e164valex-1.1`, and the example XML schema `urn:ietf:params:xml:schema:e164valex-1.1`.
This extension does not provide any security services beyond those of EPP (RFC 3730), the EPP domain name mapping (RFC 3731), and their underlying protocol layers. Security considerations from those specifications and from the ENUM specification (RFC 3761) apply equally here.
Validation information often contains sensitive personal information. It is RECOMMENDED that validation information in the `<info>` response be provided only to the sponsoring client, to limit exposure of personal data.
The example validation schema (namespace `urn:ietf:params:xml:ns:e164valex-1.1`) defines `<simpleVal>` of type `simpleValType` containing in order: required `<methodID>`, optional `<validationEntityID>`, optional `<registrarID>`, required `<executionDate>`, optional `<expirationDate>`.
The `<executionDate>` and `<expirationDate>` fields are encoded using the XML Schema `date` data type. `<expirationDate>` is optional (`minOccurs="0"`) while `<executionDate>` is required in the example schema.
The framework XML schema (namespace `urn:ietf:params:xml:ns:e164val-1.0`) defines `insertType` for create/renew/transfer (one or more `<add>` elements), `updateType` for update (zero or more `<add>`, `<rem>`, `<chg>` elements), and `infDataType` for info responses (zero or more `<inf>` elements). The `<validationInfo>` element uses `ValidationInfoType` with an `<any namespace="##other"/>` wildcard.
The `<methodID>` field is a token string with a minimum length of 1 and maximum length of 63 characters, encoding an identifier for the validation method used. It is defined as `e164valex:methodIdType` in the example schema.
The `<validationEntityID>` and `<registrarID>` fields are each encoded as `eppcom:clIDType` character strings with lengths of 3 to 16 characters, carrying identifiers for the ENUM Validation Entity and ENUM Registrar respectively.