RFC 6117
IANA Registration of Enumservices: Guide, Template, and IANA Considerations
RFC 6117: IANA Registration of Enumservices: Guide, Template, and IANA Considerations 🎀
Okay bestie, the title block is giving official paperwork, so here's the tea. This is RFC 6117 from the IETF (Request for Comments: 6117). The authors are B. Hoeneisen from Ucom.ch, A. Mayrhofer from enum.at, and J. Livingood from Comcast. It's a Standards Track document, the ISSN is 2070-1721, and it came out in March 2011. It obsoletes RFC 3761 🦋
Abstract 🌸
This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. ✨
Status of This Memo 💜
This is an Internet Standards Track document. 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 🌈
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6117. ✨
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🧚
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🙈
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Requirements . . . . . . . . . . . . . . . . . . 5
3.1. Functionality Requirements . . . . . . . . . . . . . . . . 5
3.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 5
3.3. Security Requirements . . . . . . . . . . . . . . . . . . 6
3.4. Publication Requirements . . . . . . . . . . . . . . . . . 7
4. Enumservice Creation Cookbook . . . . . . . . . . . . . . . . 7
4.1. General Enumservice Considerations . . . . . . . . . . . . 7
4.2. Classification, Type and Subtype . . . . . . . . . . . . . 9
4.2.1. General Type/Subtype Considerations . . . . . . . . . 9
4.2.2. Protocol-Based Enumservices Class . . . . . . . . . . 10
4.2.3. Application-Based Enumservice Classes . . . . . . . . 10
4.2.4. Data Type-Based Enumservice Class . . . . . . . . . . 12
4.2.5. Other Enumservice . . . . . . . . . . . . . . . . . . 13
5. Required Sections and Information . . . . . . . . . . . . . . 13
5.1. Introduction (REQUIRED) . . . . . . . . . . . . . . . . . 13
5.2. IANA Registration (REQUIRED) . . . . . . . . . . . . . . . 13
5.2.1. Enumservice Class (<class>) . . . . . . . . . . . . . 13
5.2.2. Enumservice Type (<type>) . . . . . . . . . . . . . . 14
5.2.3. Enumservice Subtype (<subtype>) . . . . . . . . . . . 14
5.2.4. URI Scheme(s) (<urischeme>) . . . . . . . . . . . . . 15
5.2.5. Functional Specification (<functionalspec>) . . . . . 15
5.2.6. Security Considerations (<security>) . . . . . . . . . 15
5.2.7. Intended Usage (<usage>) . . . . . . . . . . . . . . . 16
5.2.8. Enumservice Specification (<registrationdocs>) . . . . 16
5.2.9. Requesters (<requesters>) . . . . . . . . . . . . . . 17
5.2.10. Further Information (<additionalinfo>) . . . . . . . . 17
5.3. Examples (REQUIRED) . . . . . . . . . . . . . . . . . . . 18
5.4. Implementation Recommendations / Notes (OPTIONAL) . . . . 18
5.5. DNS Considerations (REQUIRED) . . . . . . . . . . . . . . 18
5.6. Security Considerations (REQUIRED) . . . . . . . . . . . . 19
5.7. IANA Considerations (REQUIRED) . . . . . . . . . . . . . . 20
5.8. Other Sections (OPTIONAL) . . . . . . . . . . . . . . . . 20
6. The Process of Registering New Enumservices . . . . . . . . . 21
6.1. Step 1: Read This Document in Detail . . . . . . . . . . . 22
6.2. Step 2: Write and Submit Registration Document . . . . . . 22
6.3. Step 3: Request Comments From the IETF Community . . . . . 23
6.3.1. Outcome 1: No Changes Needed . . . . . . . . . . . . . 23
6.3.2. Outcome 2: Changes, But No Further Comments
Requested . . . . . . . . . . . . . . . . . . . . . . 23
6.3.3. Outcome 3: Changes and Further Comments Requested . . 23
6.4. Step 4: Submit Registration Document to IANA . . . . . . . 24
6.5. Step 5: Expert Review . . . . . . . . . . . . . . . . . . 24
6.5.1. Outcome 1: Experts Approve the Registration
Document . . . . . . . . . . . . . . . . . . . . . . . 25
6.5.2. Outcome 2: Changes Required . . . . . . . . . . . . . 25
6.5.3. Outcome 3: Experts Reject the Registration Document . 25
6.6. Step 6: Publication of the Registration Document . . . . . 25
6.7. Step 7: Adding Enumservice to the IANA Registry . . . . . 25
7. Expert Review . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Expert Selection Process . . . . . . . . . . . . . . . . . 26
7.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 26
7.3. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Revision of Existing Enumservice Specifications . . . . . . . 27
9. Extension of Existing Enumservice Specifications . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Considerations Regarding This Document . . . . . . . . . . 28
10.2. Enumservice Security Considerations Guideline . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. Registry Update . . . . . . . . . . . . . . . . . . . . . 28
11.2. Registration Template (XML chunk) . . . . . . . . . . . . 28
11.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 30
11.5. Expert Review Procedure . . . . . . . . . . . . . . . . . 30
11.6. Registration Procedure . . . . . . . . . . . . . . . . . . 30
11.6.1. Published as an RFC . . . . . . . . . . . . . . . . . 31
11.6.2. Published as a Non-RFC . . . . . . . . . . . . . . . . 31
11.7. Change Control . . . . . . . . . . . . . . . . . . . . . . 32
11.8. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IANA Registration Template Examples . . . . . . . . . 36
Appendix B. Changes from RFC 3761 . . . . . . . . . . . . . . . . 391. Introduction 🦋
Okay so ENUM, which is E.164 Number Mapping [RFC6116], gives us an identifier mapping mechanism. It maps E.164 numbers [ITU.E164.2005] to Uniform Resource Identifiers (URIs) [RFC3986] using the Domain Name System (DNS) [RFC1035]. One of the big concepts in ENUM is "Enumservices," and they let you hand out different URIs for different applications of that same mapping mechanism. Main character energy, literally 👑
This document specifies a revision of the IANA registry for Enumservices, which was originally described in [RFC3761]. This document obsoletes Section 3 of RFC 3761, while RFC 6116 obsoletes RFC 3761. 💅
The new registration processes, which are detailed in Section 6, have been specifically designed to be decoupled from the existence of the ENUM working group. Compared to RFC 3761, the main changes are as follows:
- For an Enumservice to be inserted to the IANA registry, "Specification Required", which implies the use of a Designated Expert, according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], are now sufficient. 🔥
- The IANA Registration Template has been supplemented with elements for "Enumservice Class" and "Enumservice Specification". ✨
The IETF's ENUM Working Group ran into an unnecessary amount of variation in the format of Enumservice Specifications. The ENUM Working Group's view of what particular information is required and/or recommended has also evolved, and capturing these best current practices is helpful in both the creation of new Enumservice Specifications, as well as the revision or refinement of existing Enumservice Specifications. It's giving organisation, honestly 🧚
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 [RFC2119]. 🌸
For the purpose of this document:
- "Registration Document" refers to a draft specification that defines an Enumservice and proposes its registration following the procedures outlined herein. 🎀
- "Enumservice Specification" refers to a Registration Document that has been approved by the experts and published according to "Specification Required" as defined in [RFC5226]. 🌈
3. Registration Requirements 🍓
Bestie, listen, this section is the vibe check. As specified in the Augmented Backus-Naur Form (ABNF, [RFC5234]) found in Section 3.4.3 of [RFC6116], an Enumservice is made up of Types and Subtypes. For any given Type, the allowable Subtypes (if any) must be defined in the Enumservice Specification. There is currently no concept of a registered Subtype outside the scope of a given Type. 💖
While the combination of each Type and all of its Subtypes constitutes the allowed values for the "Enumservice" field, it is not sufficient to just list their allowed values. To allow for interoperability, 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. 🔥
Furthermore, in order for an Enumservice to be registered, the entire Registration Document requires approval by the experts according to "Specification Required", which implies the use of a Designated Expert, as set out in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] and Section 7.2 of this document. 🦋
All Enumservice Specifications are expected to conform also to various requirements laid out in the following sections. ✨
✨ Part 1 of 7 done, bestie. Part 2 is coming up next 🫶
3.1. Functionality Requirements 🎀
okay so a registered Enumservice must be able to work as a selection mechanism for picking one Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR) out of a whole set of them 🧚. That means the Enumservice Specification MUST define how to use the NAPTR RR and the URI(s) the NAPTR RR resolves to 💅.
And it gets more specific: a registered Enumservice MUST specify the URI Scheme(s) that may be used for the Enumservice, plus, when needed, any other info that has to be carried into the URI resolution process itself 🦋.
3.2. Naming Requirements 💖
the name of an Enumservice MUST be unique, because otherwise it's useless as a selection criteria 😭:
- The Type MUST be unique.
- The Subtype (which depends on the Type) MUST be unique within a given Type.
Types and Subtypes MUST conform to the ABNF specified in Section 3.4.3 of [RFC6116] 📝.
The ABNF in Section 3.4.3 of [RFC6116] lets you use the "-" (dash) character for Types and Subtypes, but babe, be careful 🙈. To avoid confusion with possible future prefixes, a "-" MUST NOT be used as the first nor as the second character of a Type or a Subtype. A "-" MUST NOT be used as the last character of a Type or a Subtype either. Also, Types and Subtypes are case insensitive and SHOULD be written in lowercase letters 🌸.
Note: the legacy IANA registry of Enumservices has Type and Subtype strings with uppercase letters 👀. Implementors could be tempted to refuse handling uppercase Type or Subtype strings, and that could seriously hurt interoperability 💀.
To avoid mixing things up with Enumservice fields that use the deprecated (obsolete) syntax, Type and Subtype MUST NOT start with the string e2u 🚫.
The Subtype for one Type MAY have the same identifier as a Subtype for another Type, but just pointing at another Type's Subtype isn't enough ✨. The functionality of each Subtype MUST be fully specified in the context of the Type being registered 🫶.
Section 4 has further naming requirements too, so keep scrolling 🧚.
3.3. Security Requirements 🔐
An analysis of security issues is REQUIRED for all registered Enumservices. (This follows the basic requirements for all IETF protocols, so no skipping it, bestie 💅.)
All descriptions of security issues MUST be as accurate and extensive as feasible. And this is the big one: saying "no security issues associated with this Enumservice" must not be confused with "the security issues associated with this Enumservice have not been assessed" 😱. Those are two VERY different vibes 💀.
There's no requirement that an Enumservice be totally free of security risks 🌈. Still, all known security risks MUST be identified in an Enumservice Specification 🔥.
Here are some of the things to look at in a security analysis of an Enumservice 👑:
- Complex Enumservices might include provisions for directives that take actions on a user's resources. A lot of the time those provisions can be made to specify arbitrary actions with no restrictions, and that can get DEVASTATING 💀 (especially if there's a risk of a new ENUM look-up, which could then cause an infinite loop in the overall resolution process of the E.164 number 🌀).
- Complex Enumservices might include provisions for directives that take actions which, while not directly harmful, could leak information. That leak could make a later attack easier or violate users' privacy somehow 🙈.
- An Enumservice might get targeted for applications that need some kind of security assurance but don't provide the necessary security mechanisms themselves 🥺. For example, an Enumservice could be defined to store confidential security services information, like alarm systems or message service passcodes, which then needs an external confidentiality service to be safe 🔒.
3.4. Publication Requirements 📢
Enumservice Specifications MUST be published according to the requirements for "Specification Required" set out in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs fulfill these requirements already 🎀. So it's strongly RECOMMENDED to publish Enumservice Specifications as RFCs, periodt 💜.
If the Enumservice Specification isn't published as an RFC, sufficient information MUST be provided that allows unique identification of the Enumservice Specification 🦋.
4. Enumservice Creation Cookbook ✨
4.1. General Enumservice Considerations 🍓
ENUM is an extremely flexible identifier mapping mechanism 🌈. It takes E.164 (phone) numbers as input identifiers and returns URIs as output identifiers 📞. Because it's so flexible, almost every ENUM use case could be implemented in several different ways 🤯.
Section 2 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] explains why managing a namespace might be necessary 📚. Even though the namespace for Enumservices is pretty big (up to 32 alphanumeric characters), there are still reasons to manage it according to Section 2 of [RFC5226] 💅. Here's the list of motivations that apply to Enumservices:
- Prevent hoarding or wasting of values: Enumservice Types aren't opaque identifiers meant just to avoid collisions in the namespace. Instead, they identify the use of a certain technology in the context of ENUM 🧠. Service Types might also be shown to end users in implementations, so meaningful Type strings with a clear relation to the protocols and applications used are strongly RECOMMENDED 💖. That's why preventing hoarding, wasting, or "hijacking" of Enumservice Type strings matters so much 🙅♀️.
- Sanity check to ensure sensible or necessary requests: this one applies to Enumservices because having various Enumservices for the same purpose would lower the chance of successful interoperability and make things way more confusing for implementers 😵💫.
- Delegation of namespace portions: in theory, the Type and/or Subtype structure of Enumservices would allow delegating Type values, and self-supporting management of Subtype values by a delegate within the Type value 🌸. Those delegates could be other standardization bodies, for example 🏛️. However, that would need clear policies about publishing and using such Subtypes 📋. So delegation of Enumservice namespace portions is therefore currently not supported 🚫.
- Interoperability: the benefit of an Enumservice grows with the number of clients that support it, so registering and using several services for a similar or identical purpose clearly hurts interoperability 💔. Operationally, it's smart to keep the space taken up by all services published in the NAPTR RRSet at any owner in the e164.arpa domain bounded 🧹. Registering nearly identical services that then compete or run in parallel could easily make DNS operations way more complicated 🌀.
Generally, before starting work on a new Enumservice registration, you should consider the following 🔍:
- Is there an existing Enumservice that could cover the desired functionality without overloading it? Check the IANA Enumservice Registry at
http://www.iana.org/assignments/enum-services📖. - Is there work in progress, or previous work, on a similar Enumservice? Check the
enum@ietf.orgmailing list archives athttp://www.ietf.org/mail-archive/web/enum/index.html, and search the Internet-Drafts Archive athttp://tools.ietf.org/🕵️♀️. Some Internet-Drafts may have expired and aren't in the Internet-Drafts Archive anymore, or some Enumservice work may have happened outside the IETF, so we also recommend a web search 🌐. - Section 4.2 provides three general categories for Enumservice classification 🏷️. Sometimes there are several options for designing an Enumservice. For example, a mapping service using HTTP could be considered a "protocol Type" Enumservice (using HTTP as the protocol), but it could also be viewed as an "application Type" Enumservice, with the application providing access to mapping services 🗺️. When several options are available like that, it can help to define use cases before starting the Enumservice itself, so you can decide which aspect matters more 🤔.
4.2. Classification, Type and Subtype 🦋
Enumservices are flexible, so they can be and are used in a lot of different ways 🌈. This section classifies Enumservices and gives guidance on choosing suitable Type and Subtype strings for each Enumservice Class 💅.
The Classification of each Enumservice MUST be listed in the Registration Document (see Section 5.2) 📝. If the Enumservice can't be assigned to one of the classes below, the Registration Document MUST contain a section on the difficulties encountered while trying to classify the service, so the experts have the info they need to decide 🧐.
4.2.1. General Type/Subtype Considerations 💜
To avoid confusion, the name of a URI Scheme MUST NOT be used as a Type string for an Enumservice that isn't specifically about that protocol or URI Scheme 🙅♀️. For example, the Type string "imap" would be inadequate for an Enumservice about "Internet mapping" services, because it already corresponds to an existing URI Scheme / protocol for something totally different 💀.
If Subtypes are defined, the minimum number SHOULD be two (including the empty Subtype, if one is defined) ✌️. Choosing just one possible Subtype for a given Type doesn't add any information when selecting an ENUM record, so it can be left out completely 🫧. However, potential future expansion of a Type into several Subtypes may justify using Subtypes even if only one is currently defined, as noted in Section 9 🔮.
It's perfectly legal under a certain Type to mix an Enumservice without a Subtype (empty Subtype) with Enumservices that have a Subtype 🌸. In that case, though, the Enumservice with an empty Subtype SHOULD be specified to reflect the base service, while the other Enumservices SHOULD be specified to reflect variants 🎀.
4.2.2. Protocol-Based Enumservices Class 🧚
This kind of Enumservice means that an interaction using the named protocol will result in use of this NAPTR 📡. The expected behavior of a system using this Enumservice MUST be clear from the protocol ✨.
A good sign that an Enumservice belongs in this Class is that a client doesn't need to understand the actual application to make use of an instance of it 🙌.
Examples of such Enumservices include "xmpp" [RFC4979] and "sip" [RFC3764] 💬.
4.2.2.1. Protocol-Based Enumservice "Type" Strings 🍓
A protocol-based Enumservice SHOULD use the lowercase name of the protocol as its Type string 🔤. Names registered in the IANA Port Number Registry (http://www.iana.org/assignments/port-numbers, defined in Section 8 and 9 of [RFC2780]) are preferred 🌈.
4.2.2.2. Protocol-Based Enumservice "Subtype" Strings 🎀
okay so if there's only one URI Scheme tied to the protocol, a Subtype SHOULD NOT be specified for the Enumservice 🙅♀️ no extra label needed, bestie ✨
if there are a bunch of different URI Schemes for the protocol, the Enumservice Specification MAY use the empty Subtype for every URI Scheme it marks as mandatory to implement 💜 but every URI Scheme that is NOT mandatory to implement MUST get its own distinct Subtype string 🚨
and if you're defining Subtypes at all, it's RECOMMENDED to use the URI Scheme name as the Subtype string 🍓
4.2.3. Application-Based Enumservice Classes 🌸
Application-based Enumservices are for when the kind of service isn't fully defined by a protocol spec. there are three cases here 👀
- Common Application Enumservice:
the application reflects a kind of interaction that can be realized by different protocols, but the publisher's intent is the same. from a user's point of view it's one common kind of interaction, and HOW it gets implemented isn't the important part 💅 The Enumservice Specification MUST describe the interaction and expected behavior in enough detail that an implementation can decide if this activity is one it can engage in. However, it is RECOMMENDED that the Enumservice be defined in a way that will allow others to use it at a later date. An Enumservice that defines a generalized application is preferred to one that has narrow use.
email is the classic example and it's kinda sneaky, because it looks like a "pure" protocol scheme but it's NOT 🙃 The URI Scheme is mailto, and it doesn't identify the protocol used to offer or retrieve emails by the sender or the recipient.
the Short Messaging Service (SMS) is another one. the Enumservice existing means the publishing entity is capable of sending or receiving a message according to the SMS specifications 📱 The underlying protocol and the URI Scheme for the addressable end point can differ, but the "user visible" interaction of sending and receiving an SMS is similar.
- Subset Enumservice:
the application interaction reflects a subset of the interactions the protocol can do. Using this Enumservice means some options available through the protocol won't be accepted, or aren't possible in this case 🙈 Any such Enumservice Specification MUST define the options available by use of this NAPTR in enough detail that an implementation can decide whether or not it can use this Enumservice. examples are "voice:tel" and "fax:tel". In both cases the URI holds a telephone number, but the essential feature is that the number can receive a voice call or a Facsimile transmission, respectively. These form subsets of the interactions possible with that telephone number, so they get their own Enumservices. They let an end point check that it has the right capability to engage in the advertised user service (a voice call or sending a fax), rather than just being able to connect to the destination address. This is especially important where there's no underlying mechanism within the protocol to negotiate a different kind of user interaction 🦋
- Ancillary Application Enumservice
another variant is the Ancillary Application 🧚 This is one where further processing (potentially using a number of different protocols or methods) is the intended result of using this Enumservice. An example is the "pstn:tel" Enumservice, which indicates that the NAPTR holds number portability data. It implies the client should engage in number portability processing using the associated URI. Note that this Enumservice usually does NOT itself define the kind of interaction available using the associated URI. That application is negotiated with some other "out of band" means (either through prior negotiation, or explicitly through the number portability process, or through negotiation following the selection of the final destination address) 💫
4.2.3.1. Application-Based Enumservice "Type" Strings 🦋
It is recommended that Application-class Enumservices use the lowercase well-known name of the abstract application as the Type string.
4.2.3.2. Application-Based Enumservice "Subtype" Strings 🍓
It is RECOMMENDED that the URI Scheme(s) used by the application be used as the Subtype string(s). Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement.
if it's foreseen that there is only one URI Scheme ever to be used with the application, the empty Subtype string MAY be used ✨
4.2.4. Data Type-Based Enumservice Class 💖
"Data Type" Enumservices typically refer to a specific data type or format, which may be addressed using one or more URI Schemes and protocols. examples of these include "vpim" [RFC4238] and "vcard" [RFC4969] 📇
4.2.4.1. Data Type-Based Enumservice "Type" Strings 🌷
It is recommended to use the lowercase well known name of the data type or format name as the Type string.
4.2.4.2. Data Type-Based Enumservice "Subtype" Strings 💜
It is RECOMMENDED to use the URI Schemes used to access the service as Subtype strings. Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement.
if there's only one URI Scheme foreseen to access the data type or format, the empty Subtype string MAY be used 🫶
4.2.5. Other Enumservice 🌈
in case an Enumservice proposal can't be assigned to any of the classes above, the <class> element (Enumservice Class) in the IANA Registration Template (see Section 5.2) MUST be populated with "Other". In that case, the Enumservice Specification MUST contain a section elaborating on why the Enumservice doesn't fit into the classification structure 🙏
5. Required Sections and Information 📋
There are several sections that MUST appear in an Enumservice Specification. These sections are as follows, and they SHOULD be in the given order.
The following terms SHOULD begin with a capital letter, whenever they refer to the IANA Registration:
- Class
- Type
- Subtype
- URI Scheme
5.1. Introduction (REQUIRED) 🌸
An introductory section MUST be included. This section will explain, in plain English, the purpose and intended use of the proposed Enumservice registration.
The Introduction SHOULD start with a short sentence about ENUM, introduce the protocol used in the Enumservice, and discuss the Enumservice as it refers from the E.164 number to the protocol or service.
5.2. IANA Registration (REQUIRED) 📝
This section MUST be included in an Enumservice Specification. Where a given Enumservice Type has multiple Subtypes, there MUST be a separate "IANA Registration" section for each Subtype. The following sections list the elements that are to be used in the XML-chunk-based Registration Template of an "IANA Registration" section.
5.2.1. Enumservice Class (<class>) 👑
This element contains the Class of the Enumservice as defined in Section 4.2. Its value MUST be one of (without quotes):
Protocol-Based: The Enumservice belongs to the Protocol-based class as described in Section 4.2.2.Application-Based, Common: The Enumservice is a "common" case of the Application-based class as described in Section 4.2.3.Application-Based, Subset: The Enumservice belongs to the "subset" case of the Application-based class as described in Section 4.2.3.Application-Based, Ancillary: The Enumservice is an "ancillary" case of the Application-based class, as described in Section 4.2.3.Data Type-Based: The Enumservice belongs to the Data Type-Based class as described in Section 4.2.4.Other: The majority of the functionality of the Enumservice does not fall into one of the classes defined.
Class Example 🎀
<class>Protocol-Based</class>5.2.2. Enumservice Type (<type>) 🧚
The Type of the Enumservice. All Types SHOULD be listed in lower-case. The choice of Type depends on the Enumservice Class. Please find further instructions in Section 4.
Type Example 🦄
<type>foo</type>5.2.3. Enumservice Subtype (<subtype>) 🦋
The Subtype of the Enumservice. All Subtypes SHOULD be listed in lower-case. The choice of Subtype depends on the Enumservice Class. Should the Enumservice not utilize a Subtype, then the <subtype> element MUST be omitted in the IANA Registration Template. If a given Enumservice Type has multiple Subtypes, then there MUST be a separate IANA Registration Template for each Subtype. Please find further instructions in Section 4.
Subtype Example 🍓
<subtype>bar</subtype>5.2.4. URI Scheme(s) (<urischeme>) 🔗
The URI Schemes [RFC3986] that are used with the Enumservice. The selection of URI Schemes often depends on the Enumservice Class, Type, and/or Subtype. A colon MUST NOT be placed after the URI Scheme name. If there is more than one URI Scheme, then one <urischeme> element per URI scheme MUST be used in the IANA Registration Template. Please find further instructions in Section 4.
URI Scheme Example 💫
<urischeme>bar</urischeme>
<urischeme>sbar</urischeme>Note: A client cannot choose a specific ENUM record in a record set based on the URI Scheme - the selection is only based on Type and Subtype, in accordance with [RFC3402].
5.2.5. Functional Specification (<functionalspec>) 💅
The Functional Specification describes how the Enumservice is used in connection with the URI to which it resolves.
Functional Specification Example 🌈
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI in order to foo the bar.
</paragraph>
<paragraph>
[...]
</paragraph>
</functionalspec>Where the terms used are non-obvious, they should be defined in the Enumservice Specification, or a reference to an external document containing their definition should be provided.
5.2.6. Security Considerations (<security>) 🔐
A reference to the "Security Considerations" section of a given Enumservice Specification.
Security Considerations Example ⭐
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>5.2.7. Intended Usage (<usage>) 🎀
Pick one of these three values (no quotes in the actual value, bestie):
COMMON: this Enumservice is meant for widespread use on the public Internet, and its scope isn't limited to one environment. 🌍LIMITED USE: this Enumservice is meant for a smaller scope, like private ENUM-ish app setups. The use case in the Enumservice Specification should describe that scenario. 🔒DEPRECATED: this Enumservice has been declared deprecated (see Section 11.7) and shouldn't be used in new deployments. 🥀 Apps SHOULD still expect to run into legacy instances of it, though, so don't be shocked when they show up.
Intended Usage Example
<usage>COMMON</usage>5.2.8. Enumservice Specification (<registrationdocs>) 📜
This is the reference (or references) to the document(s) that contain the Enumservice Specification. Basically, where the receipts live. 🧾
Enumservice Specification Examples
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>or
<registrationdocs>
<xref type="rfc" data="rfc2026"/> (obsoleted by RFC 2551)
<xref type="rfc" data="rfc2551"/>
</registrationdocs>or
<registrationdocs>
[International Telecommunications Union,
"Enumservice Specification for Foobar",
ITU-F Recommendation B.193, Release 73, Mar 2009.]
</registrationdocs>5.2.9. Requesters (<requesters>) 🙋♀️
These are the people asking for the Enumservice to be registered. Usually they're the authors of the Enumservice Specification, so it's the glow-up squad. ✨
Requesters Example
<requesters>
<xref type="person" data="John_Doe"/>
</requesters>
[...]
<people>
<person id="John_Doe">
<name>John Doe</name>
<org>ACME Research and Development Inc.</org>
<uri>mailto:jd@acme.example.com</uri>
<updated>2008-11-20</updated>
</person>
</people>Okay, so if there's more than one requester, there MUST be one <xref> element per requester in the <requesters> element, and one <person> chunk per requester in the <people> element. No shortcuts, periodt. 💅
5.2.10. Further Information (<additionalinfo>) 🦋
This is the bonus section for anything else the authors find interesting, including artwork. Share your vibes here. 🎨
Further Information Example
<additionalinfo>
<paragraph>more info goes here</paragraph>
</additionalinfo>Note: If there's no extra info, then the <additionalinfo> element just gets left out. No need to force it. 🙈
5.3. Examples (REQUIRED) 🌸
This section MUST show at least one example of the Enumservice being registered, just to illustrate things. The examples will in no way limit the different forms a given Enumservice can take, and you should say so right at the top of this section. 📝 The examples MUST show the specific formatting of the intended NAPTRs (according to [RFC3403] and [RFC6116]), including one or more NAPTR examples, and a short plain-English description (one or more sentences) explaining the different parts or attributes of the records. Explain it like you're texting someone who's never seen DNS before. 💬
The examples SHOULD include a quick description of how a client that supports this Enumservice could behave, unless that's already covered in something like the Introduction or the Functional Specification. 🧠
The examples SHOULD also follow any relevant IETF guidelines for domain names, phone numbers, and other resource identifier examples, like [RFC2606]. Reserved names only, no cap. 🚫
For example:
$ORIGIN 9.7.8.0.6.9.2.3.6.1.4.4.e164.arpa.
@ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" .5.4. Implementation Recommendations / Notes (OPTIONAL) 🛠️
Recommendations about implementation and/or operations SHOULD be included here. This section is super helpful for anyone reading an Enumservice Specification who's trying to figure out how to actually use it to support their network or service. Think of it as the pro tips tab. 💡
5.5. DNS Considerations (REQUIRED) 🌐
If bringing protocols and URI Schemes into ENUM specifically creates new DNS issues, those MUST be described in this section. No hiding the drama. 😭
Such DNS issues include, but aren't limited to, the following:
- Assumptions about ownership or administrative control of the namespace.
- Requirement or need to use DNS wildcards.
- Incompatibility with DNS wildcards.
- Presence or absence of respective NAPTR Resource Records at particular levels in the DNS hierarchy (for example, only for "full" E.164 numbers or wildcards only).
- Use of any Resource Records (especially non-NAPTR) within or beyond the e164.arpa namespace, other than those needed to resolve the domain names that appear in the "replacement" URI.
- Potential for significant additional load on the nameserver chain due to use of the service, and the mitigation of that additional load.
- Mitigation of potential for DNS loops, specifically where the result URI of an Enumservice might be used to trigger additional (subsequent) ENUM queries. This applies in particular to Enumservices using the 'tel' URI Scheme [RFC3966] or any other (future) URI Scheme using (E.164) numbers. "The ENUM Dip Indicator Parameter for the tel URI" [RFC4759] gives an example of a loop mitigation mechanism. 🔁
Rationale: some Enumservices try to exploit side effects of the DNS, and those need to be explicitly discussed. Not just vibes, bestie. 🧐
5.6. Security Considerations (REQUIRED) 🔐
A section explaining any potential security threats that are especially relevant to the given registration MUST be included. This MUST also cover any information about access to Personally Identifiable Information (PII). Big deal, big responsibility. 🚨
An Enumservice Specification SHOULD NOT include general and obvious security recommendations, like "secure your servers with strong password authentication." We all know that one already. 🙄
For extra background, [RFC3552] gives guidance on writing a good Security Considerations section. [RFC6116] already outlines security considerations affecting ENUM as a whole. Enumservice Specifications don't need to, and SHOULD NOT, repeat the considerations already listed in that document. However, Enumservice Specifications SHOULD include a reference to that section. Link back, don't copy-paste. 🔗
Also, ENUM refers to resources using existing URI Schemes and protocols. Enumservice Specifications don't need to, and SHOULD NOT, repeat security considerations that affect those protocols and URI Schemes themselves. 🙅♀️
However, in some cases, bringing those protocols and URI Schemes into ENUM specifically could introduce new security issues. In those cases, the issues or risks MUST be covered in the "Security Considerations" section of the Enumservice Specification. Authors should pay extra attention to indirect risks tied to a proposed Enumservice, including cases where it could lead to the discovery or disclosure of Personally Identifiable Information (PII). This is the part where the plot twist can get scary. 👀💀
5.7. IANA Considerations (REQUIRED) 📮
Describe the task IANA needs to complete to process the Enumservice Registration Document.
For example:
This document requests the IANA registration of the Enumservice with Type "foo" and Subtype "bar" according to the definitions in this document, [RFC6117], and [RFC6116].
For example:
This document requests an update of the IANA registration of the Enumservice Type "foo" with Subtype "bar", according to the definitions in this document, [RFC6117], and [RFC6116]. Therefore, in the existing IANA registration for this Enumservice, the <registrationdocs> element (Enumservice Specification) is enhanced by adding a supplementary reference that points to this document. 🔄
For example:
This document requests an update of the IANA registration of the Enumservice Type "foo" with all its Subtypes, in order to declare it deprecated. Therefore, in the existing IANA registration for this Enumservice, the <usage> element (Intended Usage) is changed to "DEPRECATED", and the <registrationdocs> element (Enumservice Specification) is enhanced by adding a supplementary reference that points to this document. Rest in peace, Enumservice. 🪦
5.8. Other Sections (OPTIONAL) 🎈
Other sections beyond the ones required above MAY be included in an Enumservice Specification. These can cover the specifics of the intended use of the Enumservice registration, plus any technical, operational, administrative, or other concerns. Add whatever you need. ✨
A use case SHOULD be included by the authors of the proposal, so that experts can better understand the problem the proposal is trying to solve (the intended use of the Enumservice). Including one will speed up the Expert Review process and make any eventual registration easier for other parties to understand and implement. Receipts for the win. 🏆
6. The Process of Registering New Enumservices 🚀
This section is an illustration of how a new Enumservice Registration Document gets submitted for review and comment, how those proposed Enumservices get reviewed, and how they get published. It's a non-normative description of the process. The normative process is described in [RFC5226]. 📖
Figure 1 shows what authors of a Registration Document describing an Enumservice must do before the document can be formally submitted to IANA for Expert Review. Figure 2 shows the process from Expert Review onwards. 🗺️
+----------------------------+
| Step 1: Read this document |
+----------------------------+
|
V
+-------------------------------+
| Step 2: Write R-D and submit |
+-------------------------------+
|
V
+--------------------------------------------+
| Step 3: Announce R-D and solicit feedback |<--+
+--------------------------------------------+ |
| |
V |
.^. |
. . |
+------------+ . Feed- . +------------+
| Update R-D |<---------< back >------------>| Update R-D |
| and submit | non-sub- . results . substantial | and submit |
+------------+ stantial . in: . changes +------------+
| changes . . needed
| needed Y
| | no changes needed
| V
| +-----------------------------+
+-------->| Step 4: Submit R-D to IANA |
+-----------------------------+
:
:
V
R-D: Registration Document
Figure 16.1. Step 1: Read This Document in Detail 📚
This document, particularly Sections 3, 4, and 5, describes all of the recommended and required sections, along with the requirements and suggestions for what goes in an Enumservice Specification. Read it before you write anything, bestie. 🫶
6.2. Step 2: Write and Submit Registration Document ✨
okay so first you need an Internet-Draft (or another spec, if that fits better) that's written up and publicly available, aka submitted 📝 The Registration Document shall follow the guidelines in Sections 4 and 5 of this document. And the Review Guidelines for experts are in Section 7.2, so bookmark that one bestie 🔖
6.3. Step 3: Request Comments From the IETF Community 🗣️
now you email the ENUM folks at <enum@ietf.org> and ask for comments on your Registration Document. You must include a proper public reference to the doc in that email (a URL is recommended, and honestly it's giving very clean).
Note: The ENUM WG mailing list <enum@ietf.org> will be kept open after conclusion of the ENUM WG. 📬
Give people a reasonable amount of time to reply, like two to four weeks, to collect feedback. Then you decide whether to take any of those comments on board by making changes and submitting a revision, or just keep going as is. The choice is up to you, the authors' judgement call 💅 Here are the outcomes you can land on:
6.3.1. Outcome 1: No Changes Needed 🌸
No changes get made to the Registration Document, and you move on to Step 4 below.
This one is recommended when the feedback doesn't lead to a new revision of the Registration Document.
6.3.2. Outcome 2: Changes, But No Further Comments Requested ✨
You update the Registration Document, and you're confident all the issues are sorted and nothing needs more discussion. Then you proceed to Step 4 below. The authors update and the author(s) is/are confident, you know how it is 🫶
This one is recommended when minor objections or minor changes came up.
6.3.3. Outcome 3: Changes and Further Comments Requested 🔁
You update and submit the Registration Document, then go back to Step 3 above, which means sending another email to <enum@ietf.org> to ask for more comments on the new version.
This one is recommended when substantial objections or substantial changes came up. Big moves, big loops 🌀
6.4. Step 4: Submit Registration Document to IANA 🦋
You submit the Registration Document to IANA through the <http://www.iana.org/> website for Expert Review.
:
:
V
+-----------------------+
| Step 5: Expert Review |<-------------+
+-----------------------+ |
| |
V |
.^. |
. . |
.---------. . Expert . +------------+
( Bad luck! )<-------- < Review >------------>| Update R-D |
`---------' experts . results . changes | and submit |
reject . in: . required +------------+
. .
Y
| experts approve
V
+-----------------------------------+
| Step 6: Publication of R-D |
+-----------------------------------+
|
V
+---------------------------------------------+
| Step 7: Adding Enumservice to IANA Registry |
+---------------------------------------------+
R-D: Registration DocumentFigure 2 (the whole journey, bestie 🗺️)
6.5. Step 5: Expert Review 👑
IANA handles the "Expert Review" for you, following [RFC5226]. The Expert Review guidelines live in Section 7.2 of this document. The authors must be ready to keep talking with IANA and the experts, so don't ghost them 💀
6.5.1. Outcome 1: Experts Approve the Registration Document 💖
No more changes get made to the Registration Document (unless you're done for real this time). IANA tells the authors, and then you move on to Step 6 below.
6.5.2. Outcome 2: Changes Required 🛠️
The experts might want changes before they approve. So you update and submit the Registration Document, then let the experts know there's an update, and they carry on with the Expert Review Process.
6.5.3. Outcome 3: Experts Reject the Registration Document 😭
An expert might reject the Registration, which means the Expert Review process gets discontinued. Rough day, but we move forward 🫂
6.6. Step 6: Publication of the Registration Document 📰
The authors are responsible for making sure the Registration Document gets published according to "Specification Required" as defined in [RFC5226].
As set out in Section 3.4, it is strongly RECOMMENDED that Enumservice Specifications be published RFCs. For any RFC, the normal IETF publication process applies (see [Instructions2authors]). In other words, the Registration Document gets submitted as an Internet Draft (for example through an IETF Working Group or a sponsoring Area Director). [Instructions2authors] also has an option to publish an RFC as 'Independent Submission', which is further described in "Independent Submissions to the RFC Editor" [RFC4846]. Options, options, options 🎀
6.7. Step 7: Adding Enumservice to the IANA Registry 🧚
If the Registration Document is going to be published as an RFC, the RFC publication process makes sure IANA adds the Enumservice to the registry. Easy peasy 🌈
If the Registration Document is going to be published in a specification that isn't an RFC, the authors must tell IANA as soon as the Enumservice Specification has been published according to "Specification Required" as defined in [RFC5226]. The <registrationdocs> element in the IANA Registration Template must contain an unambiguous reference to the Enumservice Specification (see also Section 5.2). On top of that, the authors must give IANA a stable URL to the Enumservice Specification, so IANA can get the information included in it. Then IANA adds the Enumservice to the registry. Ta-da ✨
7. Expert Review 🔍
7.1. Expert Selection Process 🎓
According to Section 3.2 of [RFC5226], experts are appointed by the IESG. The IESG is responsible for making sure there is always a big enough pool of experts available. 🫶
7.2. Review Guidelines 📋
Generally, the "Expert Review" process of an Enumservice follows the guidelines documented in Section 3.3 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. Note that RFC 5226 says 'The review may be wide or narrow, depending on the situation and the judgment of the designated expert'. So the list below is a guideline, not a binding list 🙃
If [RFC5226] and the guidelines in this section ever conflict, [RFC5226] remains authoritative.
The expert evaluates the criteria set out in [RFC5226], and should additionally consider the following:
- Verify conformance with the ENUM specification [RFC6116].
- Verify that the requirements set out in this document (Sections 3 and 5) are met. This includes checking for completeness and whether all the aspects described in Sections 3 and 5 are sufficiently addressed.
- If a use case is provided, the experts should verify whether the proposed Enumservice does actually match the use case. The experts should also determine whether the use case could be covered by an existing Enumservice.
- Verify that the proposed Enumservice cannot be confused with identical (or similar) other Enumservices already registered.
- If the Enumservice is classified according to Section 4.2, the experts must verify that the principles of the Class in question are followed.
- In case the Enumservice is not classified, the experts must verify whether a convincing reason for the deviation is provided in the Registration Document.
- Investigate whether the proposed Enumservice has any negative side effects on existing clients and infrastructure, particularly the DNS.
- If the output of processing an Enumservice might be used for input to more ENUM processing (especially services returning 'tel' URIs), the experts should verify that the authors have adequately addressed the issue of potential query loops. 🔁
7.3. Appeals ⚖️
Appeals of Expert Review decisions follow the process described in Section 7 of [RFC5226] and Section 6.5 of [RFC2026].
8. Revision of Existing Enumservice Specifications 🔄
Lots of Enumservice registrations, published via IETF RFCs, already exist from before this document was written. These existing Enumservice Specifications MAY be revised to comply with the specifications contained herein. All revisions of Enumservice Specifications MUST be compliant with the specifications contained herein.
Note: Enumservice Specifications updated only by [RFC6118] are not compliant with the specifications contained herein! 🚩
9. Extension of Existing Enumservice Specifications 🧩
Sometimes it makes more sense to extend an existing Enumservice registration than to propose a brand-new one. Adding a new Subtype to an existing Type is one example. Depending on how big the extension is, the original Enumservice Specification either needs to be extended (Updates) or replaced (Obsoletes) [RFC2223]. An update is the right call when a new Subtype is added without changing the existing repertoire. A replacement is needed if the default changes, or if the assumptions about URI support in clients change.
Any Enumservice Specifications for existing Enumservices that get extended MUST comply with the specifications contained herein. Because of that, revisions of existing Enumservice Specifications may be required according to Section 8.
10. Security Considerations 🔐
10.1. Considerations Regarding This Document 🛡️
Since this document doesn't introduce any new technology, protocol, or Enumservice Specification, there are no specific security issues to consider for this document. However, this is a guide for authors of new Enumservice Specifications, so authors and experts should look closely at the next section.
10.2. Enumservice Security Considerations Guideline 🚨
Guidelines for the Security Considerations section of an Enumservice Specification can be found in Section 5.6. Please take them seriously, this part is not a drill 💀
11. IANA Considerations 🦕
11.1. Registry Update 🗂️
IANA updated the registry "Enumservice Registrations" as defined in (this) Section 11, which replaces the old mechanism defined in [RFC3761].
This process only applies to ordinary Enumservice registrations. The registration process for "X-" Enumservices is beyond the scope of this document, and as per [RFC6116], "P-" Enumservices will not be registered at all. 💅
11.2. Registration Template (XML chunk) ✨
okay bestie, this is the IANA Registration Template in XML chunk form, and it's giving very organised 🗂️💅 Each <record> holds the Enumservice's details, and <people> holds the person info for the requesters.
<record>
<class> <!-- Enumservice Class --> </class>
<type> <!-- Type --> </type>
<subtype> <!-- Subtype --> </subtype>
<urischeme> <!-- URI Schema Name --> </urischeme>
<urischeme> <!-- another URI Schema Name --> </urischeme>
<functionalspec>
<paragraph>
<!-- Text that explains the functionality of
the Enumservice to be registered -->
</paragraph>
</functionalspec>
<security>
<!-- Security Considerations of the
Enumservice to be registered -->
</security>
<usage> <!-- COMMON, LIMITED USE, or OBSOLETE --> </usage>
<registrationdocs>
<!-- Change accordingly -->
<xref type="rfc" data="rfc2551"/>
</registrationdocs>
<requesters>
<!-- Change accordingly -->
<xref type="person" data="John_Doe"/>
<xref type="person" data="Jane_Dale"/>
</requesters>
<additionalinfo>
<paragraph>
<!-- Text with additional information about
the Enumservice to be registered -->
</paragraph>
<artwork>
<!-- There can be artwork sections, too -->
:-)
</artwork>
</additionalinfo>
</record>
<people>
<person id="John_Doe">
<name> <!-- Firstname Lastname --> </name>
<org> <!-- Organisation Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated>
</person>
<!-- repeat person section for each person -->
</people>Authors of an Enumservice Specification are encouraged to use these XML chunks as a template to build their IANA Registration Template. 🎀 Examples of how to use it are in Appendix A, so go peek there if you want to see it in action 👀
11.3. Location 📍
Approved Enumservice registrations get published in the IANA registry called "Enumservice Registrations". You can find it at http://www.iana.org/assignments/enum-services. 🌐
This registry publishes representations that come from the IANA Registration Template, which is described in Section 11.2 and specified in Section 5.2.
If the Enumservice Specification isn't an RFC, IANA has to hold an escrow copy of that Enumservice Specification. That escrow copy is the master reference for that Enumservice registration, so it's basically the source of truth 🔐
11.4. Structure 🧩
IANA keeps the Enumservice Registry sorted in alphabetical order. The first sort field is Type, and the second is Subtype.
[RFC6118] updates the existing Enumservices by turning them into the new XML-chunk-based IANA Registration Template. See also Section 8 for more on that 🦋
11.5. Expert Review Procedure 🔍
Whenever a Registration Document gets submitted through the IANA website, IANA takes care of the "Expert Review" process. That process follows "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].
To prevent clashes, IANA checks whether a request with an identical "type:subtype" (or just "type" without a Subtype) was already submitted for Expert Review. If it was, IANA lets the experts know. The experts are allowed to resolve clashes however they think is best, and the requesters might need to update their registration request before they get expert approval 🫶
Once the experts have conditionally approved the Enumservice, IANA tells the authors. That message should also remind them that (i) the authors are now responsible for publishing the Registration Document (see also Section 6.6), and (ii) the Enumservice only gets added to the IANA registry after its Enumservice Specification is published under the "Specification Required" policy as defined in [RFC5226] (see also Section 6.7). ⚠️
Note: After IANA sends the approval note to the authors, IANA has no further responsibilities beyond keeping internal records of the approved Registration Documents. IANA gets involved again when the Enumservice is registered (see Section 11.6).
11.6. Registration Procedure 🚀
The process is a little different depending on whether or not the Enumservice Specification will be published as an RFC. The reason is the current RFC publication process, which involves IANA shortly before an RFC gets published 📰
11.6.1. Published as an RFC
As part of the RFC publication process, IANA receives the Enumservice Specification to carry out its IANA actions shortly before the RFC is published. The IANA action is to register the Enumservice, which means adding it to the IANA "Enumservice Registrations" registry (see also Section 11.3).
IANA must only add Enumservices to the Registry if the experts have (conditionally) approved the corresponding Enumservice Specification. IANA should try to resolve any conflicts that come up together with the experts. If there are substantial changes between the (conditionally) approved version and the version to be published, IANA may reject the request after consulting the experts.
IANA must make sure that any further substantial changes the Enumservice Specification might go through before final RFC publication are approved by the experts 🧐
Note: Clearly editorial changes (such as typos), or minor changes in purely editorial sections (such as Authors' Addresses, Acknowledgments, References, and alike), are not considered substantial. 💅
11.6.2. Published as a Non-RFC
Once the authors have told IANA about the publication, IANA must make sure that the requirements for "Specification Required" as defined in [RFC5226] are met. It also has to check that the reference to the specification is unambiguous, and that the content of the Enumservice Specification is identical to the Registration Document the experts approved. Then IANA registers the Enumservice by adding it to the IANA "Enumservice Registrations" registry, and makes an escrow copy (see also Section 11.3). 🔐✨
IANA must only add Enumservices to the Registry if the experts have approved the corresponding Enumservice Specification. IANA should try to resolve any conflicts that come up together with the experts. If there are substantial changes between the approved version and the published version, IANA may reject the request after consulting the experts.
Note: Clearly editorial changes (such as typos), or minor changes in purely editorial sections (such as Authors' Addresses, Acknowledgments, References, and alike), are not considered substantial.
11.7. Change Control 🔄
Change control for any Enumservice registrations is done by "Specification Required", which means using a Designated Expert, according to [RFC5226]. Updates of Enumservice Specifications MUST comply with the requirements described in this document. Updates are handled the same way as initial Enumservice registrations 🌸
The Authorized Change Controllers are the experts and the IESG.
Enumservice registrations must not be deleted 🙅♀️ If an Enumservice is believed to be no longer appropriate for use, it can be declared deprecated by publishing a new Enumservice Specification that changes the Enumservice <usage> element (Intended Usage) to "DEPRECATED". Those Enumservices will be clearly marked in the lists IANA publishes. Obsoletions count as updates, so they're handled the same way as initial Enumservice registrations too. Alternatively, Enumservices can be declared deprecated by an IESG action. 🪦
11.8. Restrictions 🚫
As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first character, nor as the second character, nor as the last character of a Type or a Subtype. Also, the Type or Subtype of any Enumservice MUST NOT be set to "E2U", nor start with "E2U". Any Enumservice registration request that doesn't follow these restrictions must be rejected by IANA, and the Expert Review process should not be started for it 🙈
Section 5.2 contains examples for Enumservice registrations. Because of that, IANA must not register an Enumservice with a Type or Subtype set to "foo", "bar", or "sbar", unless the experts explicitly confirm an exception 🧚
12. Acknowledgments 🫶
The authors would like to thank these people, who gave feedback or made significant contributions to the development of this document: Jari Arkko, Stewart Bryant, Gonzalo Camarillo, Lawrence Conroy, Michelle Cotton, Miguel Garcia, David Harrington, Alfred Hoenes, Ari Keranen, Peter Koch, Edward Lewis, Alexey Melnikov, Jon Peterson, Pekka Savola, and Peter Saint-Andre. 💖
Lawrence Conroy wrote extensive text for the Enumservice Classification section, so he's an absolute legend 👑
Section 3 of [RFC3761], which was edited by Patrik Faltstrom and Michael Mealling, has been incorporated into this document. For more acknowledgments, check the Acknowledgments section in RFC 3761 🌈
13. References 📚
13.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116,
March 2011.13.2. Informative References 📚
okay so these are the extra reads 🤓 not required to implement the thing, but they're the background, the history, and the stuff the RFC leans on. bestie, don't skip the list!!
[ITU.E164.2005] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, Feb 2005.
[Instructions2authors] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", RFC Editor http://www.rfc-editor.org/rfc-editor/instructions2authors.txt, August 2004.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
[RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip Indicator Parameter for the "tel" URI", RFC 4759, December 2006.
[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", RFC 4969, August 2007.
[RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", RFC 4979, August 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, March 2011.
Appendix A. IANA Registration Template Examples 🧚
this bit is non-normative, so it's just examples to show you what the XML-chunk-based IANA Registration Template looks like in real life ✨
here's the first one 💅
<record>
<class>Protocol-Based</class>
<type>email</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
can be addressed by the associated URI in
order to send an email.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4355"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/>
</registrationdocs>
<requesters>
<xref type="person" data="Lawrence_Conroy"/>
</requesters>
</record>
<people>
<person id="Lawrence_Conroy">
<name>Lawrence Conroy</name>
<org>Siemens Roke Manor Research</org>
<uri>mailto:lwc@roke.co.uk</uri>
<updated>2008-11-20</updated>
</person>
</people>and the second one, which is giving XMPP vibes 🦋
<record>
<class>Protocol-Based</class>
<type>xmpp</type>
<urischeme>xmpp</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the
resource identified is an XMPP entity.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>
<requesters>
<xref type="person" data="Alexander_Mayrhofer"/>
</requesters>
</record>
<people>
<person id="Alexander_Mayrhofer">
<name>Alexander Mayrhofer</name>
<org>enum.at GmbH</org>
<uri>mailto:alexander.mayrhofer@enum.at</uri>
<updated>2008-10-10</updated>
</person>
</people>and now the third one, the voicemsg example 🎀
<record>
<class>Application-Based</class>
<type>voicemsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI scheme in order to initiate a voice
communication session to a voice messaging system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4279"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4279"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Donald_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of
examples in <xref type="rfc" data="rfc4279"/>,
Section 7.
</paragraph>
</additionalinfo>
</record>
<people>
<person id="Jason_Livingood">
<name>Jason Livingood</name>
<org>Comcast Cable Communications</org>
<uri>mailto:jason_livingood@cable.comcast.com</uri>
<updated>2008-11-20</updated>
</person>
<person id="Donald_Troshynski">
<name>Donald Troshynski</name>
<org>Acme Packet</org>
<uri>mailto:dtroshynski@acmepacket.com</uri>
<updated>2008-11-20</updated>
</person>
</people>okay bestie, pay attention here 👀 in that third example, the "voicemsg" Enumservice has several Subtypes, and the example only shows one of them. Every Subtype needs its own Registration Template submitted to IANA, so an Enumservice with several Subtypes ends up with several matching IANA Registration Templates. Why? So there's zero confusion about which <subtype> goes with which <urischeme> 💖
Appendix B. Changes from RFC 3761 🌸
this section is the glow-up log 💅 it lists what changed in the Enumservice registration process and the IANA registry definition, compared to RFC 3761.
- Ok so RFC 3761 wanted "Standards track or Experimental" RFCs before an Enumservice could be registered, but this document goes with "Specification Required" instead, which means a Designated Expert is involved 🧑⚖️
- This document defines how Enumservices are classified. The IANA Registration Template got a <class> element (Enumservice Class) 🏷️
- A brand new <registrationdocs> element (Enumservice Specification) joined the IANA Registration Template 📄
- The old field "Any other information that the author deems interesting" in the IANA Registration Template became the <additionalinfo> element (Further Information) ✨
- The Enumservice "Name" field got removed from the IANA Registration Template 👋
- The Registration Template is now a chunk of XML data, which matches IANA's recent work converting registries to XML 🫶
Authors' Addresses 🫶
the people behind this one, with all their contact info:
Bernie Hoeneisen
Ucom Standards Track Solutions GmbH
CH-8000 Zuerich
Switzerland
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Alexander Mayrhofer
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Jason Livingood
Comcast Cable Communications
One Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
USA
Phone: +1-215-286-7813
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com/and that's a wrap on RFC 6117, bestie!! 🌈💖✨
📦 where this page comes from
- ietf: rfc6117 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms