IANA Registration of Enumservices: Guide, Template, and IANA Considerations
obsoletes
- rfc-3761 — The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
Extracted elements (28)
Namespace management is necessary despite the large Enumservice namespace (up to 32 alphanumeric characters) to prevent hoarding/hijacking of meaningful Type strings, ensure interoperability by avoiding competing services for the same purpose, and bound DNS operational complexity.
The new registration process has been specifically designed to be decoupled from the existence of the ENUM Working Group, replacing RFC 3761's requirement for Standards Track or Experimental RFCs with 'Specification Required', which only requires a Designated Expert.
When Subtypes are defined, the minimum number SHOULD be two. A single Subtype adds no selection information and can be omitted entirely, though anticipated future expansion may justify defining one Subtype now to reserve the structural pattern.
The legacy IANA Enumservice registry contains Type and Subtype strings with uppercase letters. Implementors who refuse to handle uppercase Type or Subtype strings could negatively affect interoperability with existing deployments; Types and Subtypes are case insensitive.
A complete Enumservice Specification MUST document the semantics of the Type and Subtype values to be registered, and MUST contain all sections listed in Section 5 of this document. Registration requires expert approval under 'Specification Required' per RFC 5226.
A '-' (dash) MUST NOT be used as the first, second, or last character of a Type or Subtype. Type and Subtype MUST NOT start with the string 'e2u' to avoid confusion with deprecated syntax.
A registered Enumservice MUST specify the URI Scheme(s) that may be used for the Enumservice, and MUST define how to use the NAPTR RR and the URI(s) it resolves to, enabling it to function as a selection mechanism for NAPTR records.
An analysis of security issues is REQUIRED for all registered Enumservices. All known security risks MUST be identified; a statement of 'no security issues' must not be confused with 'issues have not been assessed'.
An Enumservice Specification MUST include these sections in order: Introduction, IANA Registration, Examples, DNS Considerations, Security Considerations, and IANA Considerations. Implementation Recommendations and Other Sections are optional.
Change control of Enumservice registrations is done by 'Specification Required' with a Designated Expert per RFC 5226. Authorized Change Controllers are the experts and the IESG. Updates are handled the same way as initial registrations.
Enumservice registrations MUST NOT be deleted. A deprecated Enumservice is handled by publishing a new Enumservice Specification that changes the <usage> element to 'DEPRECATED'; applications SHOULD expect to encounter legacy instances of deprecated Enumservices.
Enumservice Specifications MUST be published according to 'Specification Required' as defined in RFC 5226. It is strongly RECOMMENDED to publish Enumservice Specifications as RFCs. Non-RFC publications must provide sufficient information for unique identification.
Expert review must verify conformance with RFC 6116, completeness of Sections 3 and 5 requirements, absence of confusion with existing Enumservices, correct classification, absence of negative DNS side effects, and adequate handling of potential query loops.
IANA MUST only add Enumservices to the registry if experts have (conditionally) approved the corresponding specification. Substantial changes between the approved and published version may cause IANA to reject the request after consulting experts.
IANA MUST reject registration requests where Type or Subtype uses '-' as first, second, or last character, or starts with 'E2U'. IANA must also not register Type or Subtype set to 'foo', 'bar', or 'sbar' (reserved for examples) without explicit expert confirmation.
The DNS Considerations section MUST describe any new DNS issues introduced by the Enumservice, including DNS wildcard compatibility, NAPTR RR placement, potential for additional nameserver load, and DNS loop risks for services returning 'tel' URIs.
The Enumservice Type MUST be unique; the Subtype MUST be unique within a given Type. Types and Subtypes MUST conform to the ABNF in Section 3.4.3 of RFC 6116 and SHOULD be specified in lowercase letters.
The Examples section MUST show at least one example with specific NAPTR record formatting per RFC 3403 and RFC 6116, plus a textual description. Examples SHOULD follow RFC 2606 guidelines for domain names and phone numbers.
The name of a URI Scheme MUST NOT be used as a Type string for an Enumservice that is not specifically about the respective protocol or URI Scheme, to avoid confusion (e.g., 'imap' for Internet mapping services would be invalid).
The Security Considerations section MUST include information about access to Personally Identifiable Information (PII). It SHOULD NOT repeat general security considerations already in RFC 6116 or the referenced URI scheme specifications, but MUST cover ENUM-specific new issues.
Enumservices are classified into four classes: Protocol-Based (named protocol defines interaction), Application-Based (Common, Subset, or Ancillary), Data Type-Based (specific data type or format), and Other. The classification MUST appear in the Registration Document's <class> element.
The <class> element MUST be one of: 'Protocol-Based', 'Application-Based, Common', 'Application-Based, Subset', 'Application-Based, Ancillary', 'Data Type-Based', or 'Other'. If 'Other', the specification MUST include a section explaining why.
The IANA Registration Template is an XML chunk containing elements: <class>, <type>, <subtype>, <urischeme> (one per URI scheme), <functionalspec>, <security>, <usage>, <registrationdocs>, <requesters>, and optionally <additionalinfo>. A separate template is required per Subtype.
The <usage> (Intended Usage) element MUST be one of: 'COMMON' (widespread public Internet use), 'LIMITED USE' (restricted scope), or 'DEPRECATED' (no longer appropriate for new deployments; legacy instances may still be encountered).
This document updates the IANA 'Enumservice Registrations' registry, replacing the mechanism defined in RFC 3761. The registry is sorted alphabetically by Type then Subtype and is located at http://www.iana.org/assignments/enum-services.
Complex Enumservices may create infinite loops if their resolved URI triggers additional ENUM lookups for the same E.164 number. The DNS Considerations section MUST address loop mitigation, particularly for Enumservices using the 'tel' URI Scheme or other URI Schemes using E.164 numbers.
Enumservice Specifications MUST pay particular attention to indirect risks including discovery or disclosure of Personally Identifiable Information (PII), as ENUM maps public E.164 numbers to URIs that may expose contact endpoints or service details.
Enumservice registration follows a 7-step process: (1) read this document, (2) write and submit registration document, (3) solicit IETF community feedback via [email protected], (4) submit to IANA, (5) Expert Review (approve/revise/reject), (6) publication per 'Specification Required', (7) IANA adds to registry.