RFC 5483

ENUM Implementation Issues and Experiences

📅 published March 2009, from ietf

1. Introduction ✨

1.1. Document Goal

Okay bestie, let's meet RFC 5483 🎀 It's an Informational doc, so it's sharing knowledge, not an Internet standard. It's by L. Conroy (RMRL) and K. Fujiwara (JPRS), dated March 2009, and it doesn't list anything it obsoletes or updates. The title is ENUM Implementation Issues and Experiences 💅

The goal is to clarify the ENUM and Dynamic Delegation Discovery System (DDDS) standards 🦋 It doesn't revise them itself. It's there to give technical input for future revisions, and to warn implementers about the pitfalls they might run into. It also highlights where ENUM implementations have read the standards differently, or have straight up failed to implement some features as specified. Iconic behaviour from the implementations, not so iconic 💀

Beyond clarifying the standards text, the doc also mentions potential choices that can be made, to help components that use this protocol work together 🫶 Just remember that others may make different choices!

The core specifications for the E.164 Number Mapping (ENUM) protocol [RFC3761] and the Dynamic Delegation Discovery System (DDDS) [RFC3403] [RFC3401] [RFC3402] [RFC3404] [RFC3405] are defined elsewhere. This doc can't give you an overview of them, so it assumes you've already read and understood the whole set of ENUM normative documents. No shortcuts, bestie 📚

The Domain Name System (DNS) is ENUM's database 🌸 ENUM uses the NAPTR (Naming Authority Pointer) resource record type to store its DDDS rules into DNS domains. ENUM also relies on DNS services, so it's really important for ENUM implementers to do a thorough analysis of all the existing DNS standard documents. You need to know what services ENUM gets, and what load ENUM provisioning and queries will put on the DNS. The DNS is the foundation, babe 🧚

A great deal of the rationale behind the choices in this document is available to anyone who explores the standards. The trick is understanding those standards and the subtle implications of some of their features 🔥 In almost all cases, the choices presented here are just selections from values that are permissible within the standards.

1.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]. 📖✨

2. Character Sets and ENUM 🌈

2.1. Character Sets - Non-ASCII Considered Harmful

[RFC3403] and [RFC3761] specify, respectively, that NAPTR resource records and ENUM support Unicode using the UTF-8 encoding defined in [RFC3629]. This raises an issue when implementations use "single byte" string-processing routines 😭 If there are multi-byte characters within an ENUM NAPTR, incorrect processing may well result from these UTF-8-unaware systems. Not it 🙈

The UTF-8 encoding has a US-ASCII equivalent range, so every character in US-ASCII [ASCII] from 0x00 to 0x7F hexadecimal maps to UTF-8 with an identity map. The encodings are the same, no drama. In UTF-8, characters with Unicode code points above this range get encoded using more than one byte, and all of those bytes are in the range 0x80 to 0xFF hexadecimal. So it's important to consider the different fields of a NAPTR and whether multi-byte characters can or should appear in them 💅

Also, the non-printable portion of US-ASCII (0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) is "difficult" 🫠 NAPTRs are processed by machines, but they may sometimes need to be written in a human-readable form. Specifically, if NAPTR content is shown to an end user so they can choose, it is imperative that the content is human-readable. So it's unwise to use non-printable characters, even if they sit within the US-ASCII range. The ENUM client may have good reason to reject NAPTRs that include these characters, since they can't readily be presented to an end user.

There are two numeric fields in a NAPTR: the ORDER and PREFERENCE/PRIORITY fields. These contain binary values, so no risk is involved, because string processing should not be applied to them. The string-based fields are the Flags, Services, and Regexp fields. The Replacement field holds an uncompressed domain name, encoded according to the standard DNS mechanism [RFC1034][RFC1035]. The Internationalised Domain Name (IDN) can be supported (as specified in [RFC3490], [RFC3491], and [RFC3492]). Any such IDN MUST be further encoded using Punycode [RFC3492]. 🔐 The Replacement field holds a domain name that is not subject to replacement or modification (other than Punycode processing), so it's not a concern here ✨

Taking the string fields in turn: the Flags field contains characters that indicate the disposition of the NAPTR 🦋 This field may be empty, in which case the NAPTR is "non-terminal". Otherwise it may include a flag character as specified in [RFC3761]. All of these characters fall into the printable US-ASCII equivalent range, so multi-byte characters cannot occur here. Main character energy, zero chaos 👑

The Services field includes the DDDS Application identifier ("E2U") used for ENUM, a set of Enumservice identifiers, and the '+' character that separates Enumservices from one another and from this DDDS Application identifier. Any of those Enumservice identifiers may embed the ':' separator character 🧚 In Section 2.4.2 of [RFC3761], Enumservice identifier tokens are specified as 1*32 ALPHA/DIGIT, so there is no possibility of non-ASCII characters in the Services field. Clean and safe 🌸

2.1.1. Non-ASCII in the Regular Expression Field ✨

okay so the Regexp field is where things get a little more complicated 🙈 It's a sed-like substitution expression (defined in [RFC3402]), and it's made of two sub-fields:

  • a POSIX Extended Regular Expression (ERE) sub-field [IEEE.1003-2.1992]
  • a replacement (Repl) sub-field [RFC3402]

Also, [RFC3402] says a flag character can be tacked on at the end, but the only flag it defines (the 'i' case-insensitivity flag) isn't it for ENUM. More on that in Section 2.2 💅

The ERE sub-field matches against the "Application Unique String." For ENUM, [RFC3761] defines that as digit characters with an initial '+' character 🧚 It's basically the global-number-digits thing from a tel: URI ([RFC3966]), just with the visual separators taken out. Put simply, it's a telephone number ([E.164]) in a restricted format. All of these characters live in the US-ASCII equivalent range of UTF-8, and so do the characters that matter to ERE processing 🫶

Strictly speaking, the ERE could include other characters. It could have choice elements matching different items, some of which might not be an ENUM Application Unique String, and those might conceivably include non-ASCII characters. But operationally, it's not reasonable to include stuff like that, since ENUM NAPTRs match against telephone numbers 🙅‍♀️

In the normal situation, where E2U NAPTRs are provisioned in ENUM domains, there won't be any multi-byte characters in this sub-field, because the ERE is meant to match telephone numbers. ENUM clients must be able to handle NAPTRs that do contain multi-byte characters (the standard doesn't rule them out), but there's no operational reason for them to ever be provisioned in ENUM domains. If you do run into NAPTRs in ENUM domains with multi-byte characters, these could reasonably be discarded 😭

The Repl sub-field can mix explicit text used to construct a URI with characters that matter to the substitution expression, as defined in [RFC3403]. The substitution characters all fall into the US-ASCII equivalent range, but that might not be true for every text someone could conceivably use to build a URI. Multi-byte characters could complicate URI generation and processing routines 💀

URI generic syntax ([RFC3986]) is a sequence of characters picked from a limited subset of the US-ASCII repertoire. Current URIs use the standard URI character escaping rules from that generic syntax, so any multi-byte character gets pre-processed, and they won't show up in the explicit text used to construct a URI within the Repl sub-field 🌸

2.1.1.1. Impact of Future Support for IRIs 🦋

As it stands, ENUM only lets URIs be generated in the Regexp field. But even if future revisions of the ENUM specification allowed Internationalised Resource Identifiers (IRIs), defined in [RFC3987], non-ASCII support could still be avoided. IRIs are defined as extending the syntax of URIs, and RFC 3987 specifies a mapping from IRIs to URIs. IRI syntax allows characters with multi-byte UTF-8 encoding 🌈

Since the Regexp field is the only place in an ENUM NAPTR where those multi-byte encodings might reasonably turn up, a simple fix is to use the mapping method in Section 3.1 of [RFC3987] to convert any IRI into its equivalent URI ✨

That process has two parts. The domain part of an IRI MUST be processed using Punycode if it has a non-ASCII domain name, and the rest MUST be processed using the extended escaping rules in [RFC3987] if it contains characters outside the normal URI repertoire. Do this and there won't be any non-ASCII characters in any part of any URI, even one converted from an IRI that had them 🎀

2.1.2. Non-ASCII Support - Conclusions 👑

Okay, the big takeaway: the only place in an ENUM NAPTR where non-ASCII characters might show up is the Regexp field. You can remove any requirement to process characters outside the US-ASCII equivalent range by adding very few operational restrictions. There's no obvious benefit to providing characters outside that range. Handling multi-byte characters complicates the development and operation of client programs, and plenty of existing programs don't support them at all 😤

So the gain from allowing characters outside the US-ASCII equivalent range is unclear, but the costs of multi-byte processing are very clear. That's why ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range 💅

2.2. Case Sensitivity 🍓

The only place NAPTR field content is case sensitive is any static text in the Repl sub-field of the Regexp field. Everywhere else, case-insensitive processing can be used 🫶

The case-insensitivity flag ('i') could be added at the end of the Regexp field. But in ENUM, the ERE sub-field operates on a string made of a '+' character followed by a sequence of digit characters. So the flag is redundant for E2U NAPTRs, since it doesn't act on the Repl sub-field contents 🙄

So the case-sensitivity flag is inappropriate for ENUM and SHOULD NOT be provisioned into E2U NAPTRs. Bye bye, flag 👋

2.3. Regexp Field Delimiter 🔥

You can't pick a delimiter character that's guaranteed not to show up in one of the sub-fields. The '!' character is used as the delimiter in all the examples in [RFC3403] and [RFC3761]. It's the only one seen in existing zones, and a bunch of client implementations are still "hardwired" to expect it as a delimiter 🙈

The '!' character won't normally appear in the ERE sub-field. It can show up in the content of some URIs, since it's a valid character (for example, in http URLs). If it's present in the Regexp field, that instance MUST be escaped using the standard technique proposed in Section 3.2 of [RFC3402]: a backslash character (U+005C) should be inserted before it in the string. Otherwise, a client might try to process it as a standard delimiter and read the Regexp field contents differently from the system that provisioned them. Nobody wants that drama 💀

2.4. Regexp Meta-Character Issue 🧚

In ENUM, the ERE sub-field can include a literal '+' character, since the Application Unique String it operates on includes one. But if it's there, the '+' MUST be escaped using a single backslash character (to produce the sub-string U+005C U+002B), because '+' is a meta-character in POSIX Extended Regular Expression syntax 🧠

Not escaping the '+' produces an invalid ERE, and it's a super common mistake. Even standards have gotten it wrong: the obsolete [RFC2916] (Section 3.4.3, example 3) has this problem 😭

For example, this NAPTR is incorrect:

* IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\\1@example.net!" .

A correct way to write it is:

* IN NAPTR 100 10 "u"
    "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" .
Heads up: when a NAPTR resource record is shown in DNS master file syntax (like the example above), the backslash itself has to be escaped with a second backslash. The DNS on-the-wire packet will only have a single backslash 🙈

3. Unsupported NAPTRs 🚫

An ENUM client MAY discard a NAPTR received in response to an ENUM query because:

  • the NAPTR is syntactically or semantically incorrect,
  • the NAPTR has a different (non-empty) DDDS Application identifier from the 'E2U' used in ENUM,
  • the NAPTR's ERE does not match the Application Unique String for this ENUM query,
  • the ENUM client does not recognise any Enumservice held in this NAPTR, or
  • this NAPTR (only) contains an Enumservice that is unsupported.

These conditions SHOULD NOT cause the whole ENUM query to terminate, and processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet) 🌸

When an ENUM client runs into a compound NAPTR (meaning one with more than one Enumservice, see also Section 4.4.1) and can't process or recognise one of the Enumservices in it, that client SHOULD ignore that Enumservice and keep going with the next Enumservice in this NAPTR's Services field. It should only discard the NAPTR if it can't handle any of the Enumservices in it. These conditions SHOULD NOT be considered errors ✨

ENUM uses regular-expression processing when generating URIs from the Regexp field of "terminal" NAPTRs. As with any regular expressions, there's a potential for buffer overrun when generating this output. A NAPTR's Repl sub-field may contain repeated back-reference patterns, and the output they generate can eat up a considerable amount of buffer space 😱

Even if a client normally only sees NAPTRs with short URIs, it may still receive NAPTRs whose Repl sub-fields have repeated back-reference patterns that could generate strings longer than the client's buffer. Those NAPTRs may have been misconfigured by accident or on purpose. The client MUST NOT fail in this case. It SHOULD NOT discard the entire ENUM query. Instead, it should just discard the NAPTR that would have caused the overrun 🙅‍♀️

If a problem is detected while processing an ENUM query across multiple domains (by following non-terminal NAPTR references), then the ENUM query SHOULD NOT be abandoned. Instead, processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain where the problem would have happened. See Section 5.2.2 for more details 🧚

3.1. Non-Compliant Client Behaviour 👀

Through monitoring current ENUM clients, a bunch of non-compliant behaviours have been detected. These behaviours are incorrect, but they may still be found in clients that are operational today 🙈

ENUM clients have been known to discard NAPTRs in which the Services field holds more than one Enumservice.

ENUM clients have also been known to discard NAPTRs with a "non-greedy" ERE sub-field expression (i.e., EREs that are dissimilar to "^.*$").

ENUM clients have been known to discard NAPTRs that don't use '!' as their Regexp delimiter character.

ENUM clients have been known to discard NAPTRs in which the delimiter is NOT the last character in the Regexp field.

ENUM clients have been known to discard NAPTRs with an empty Flags field (i.e., "non-terminal" NAPTRs).

ENUM clients have been known to ignore the ORDER field value entirely, sorting the NAPTRs in an RRSet based solely on the PREFERENCE/PRIORITY field values.

Finally, many ENUM clients have been known to discard a NAPTR where they have local knowledge that the URI that would be generated by processing the NAPTR is unusable. This behaviour is, strictly speaking, non-compliant, but it might be considered reasonable (see Section 4.1). Honestly, valid vibes from the client side, but still technically a no-no 💅✨

4. ENUM NAPTR Processing ✨

okay so ENUM is a DDDS Application 💅, and the way NAPTRs in an RRSet get processed totally reflects that. The details are in Section 3.3 of [RFC3402] 📖. The client is expected to sort the records it gets into a sequence and then process them in that order 🦋. That sequence comes from the ORDER and PREFERENCE/PRIORITY field values in each NAPTR ✨.

The ORDER field is the major (most significant) sort term, and PREFERENCE/PRIORITY is the minor (least significant) one 💖. Put together, ORDER and PREFERENCE/PRIORITY show the sequence the publisher picked, and NAPTRs get considered in that order 👑.

Once they're sorted, there's more filtering to decide if each NAPTR fits this ENUM evaluation 🔥. Look at the Flags field. If it's empty, that's a "non-terminal" NAPTR and it gets handled the way Section 5 describes 🧚.

If the "u" Flag is there (so it's a "terminal" rule that makes a URI), the Services field has to be checked to make sure the NAPTR is meant for ENUM. That means it includes the "E2U" DDDS Application identifier in Services 💅. The ERE in the Regexp field gets checked and must match the AUS for this ENUM evaluation (the queried telephone number) 📞. Unless every one of these checks succeeds, the NAPTR gets tossed and the next one in sequence is processed 🙈.

Clients also look at the Enumservices in the Services field during this step 🌸. Enumservices describe the kind of interaction you can have through the URI this NAPTR generates. If there's local knowledge that a NAPTR only includes an Enumservice that's unsupported or unrecognised, that NAPTR can be discarded and the next one in sequence gets processed 💀. For example, a system that only supports SIP gets an RRSet where the "best" NAPTR indicates the H323 Enumservice. It could reasonably skip that one and move on to the next ✨.

4.1. Common Non-Compliant ENUM Processing

okay this section is the spicy one 🌶️🙈. Processing the ORDER and PREFERENCE/PRIORITY fields has caused a lot of confusion, and many ENUM clients don't implement it exactly as specified 😭.

In particular, lots of ENUM clients use local prior knowledge about URIs during ENUM processing 🧠. If a client knows a particular URI won't end well, it might discard that NAPTR and try the next one in sequence. Examples include: the URI doesn't resolve, authentication was recently rejected, or user policies mark a URI as unacceptable (like a "premium rate" number that would be charged at a wild rate 💸).

Strictly speaking, this behaviour is non-compliant if the next NAPTR record has a different ORDER value. The ENUM algorithm (Section 3.3 of [RFC3402] and Section 4.1 of [RFC3403]) says that once a match has been found for the Application Unique String (AUS), and the service description satisfies the client's requirements, NAPTR records with larger ORDER values must not be considered (but other NAPTR records with the same ORDER value can still be considered) 🚫.

However, embedding local knowledge about the URI into the ENUM evaluation process is almost universal in systems that use ENUM 🫶. Also, since the difference between ORDER and PRIORITY/PREFERENCE has been unclear, NAPTR records have been provisioned in ways that would make strictly compliant systems unusable in practice 💀. Given that these systems are meant to provide communications, this non-compliant, "embedded decision" behaviour is pretty understandable 🥹.

It is proposed that when the ENUM specification is updated, processing of ORDER and PRIORITY/PREFERENCE should be updated based on the implementation and deployment experiences described in this document 🦋.

4.1.1. Example

The example in this section is meant to help you understand the difference between what [RFC3402] and [RFC3403] specify and what existing ENUM clients actually do 🧚.

WARNING: The NAPTR records shown in this section are intended to illustrate somewhat unclear corner cases, and are not intended as good examples of how to do ENUM provisioning.

Consider the following RRset, which maps numbers in the UK drama range to one server, and all other numbers to a second server:

* 3600 IN NAPTR 1 1 "u" "e2u+sip"
    "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" .
* 3600 IN NAPTR 2 1 "u" "e2u+sip"
    "!^(.*)$!sip:\\1@biloxi.example.com!" .

According to the processing specified in [RFC3402] and [RFC3403], the ENUM client is never supposed to consider the second rule for, e.g., the AUS "+441632960123". That's true even if it doesn't support "sips" URIs, or the atlanta.example.com server can't be reached, or the user says they don't want to contact atlanta.example.com. However, existing ENUM implementations are known to do this anyway, and as described above, it can be useful when the alternative is failing to communicate at all 🙏.

To stop a client from considering the second rule for the UK drama range, the example could be rewritten to have more predictable behaviour, as follows:

* 3600 IN NAPTR 1 1 "u" "e2u+sip"
    "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" .
* 3600 IN NAPTR 2 1 "u" "e2u+sip"
    "!^(\\+[^4].*|\\+4[^4].*|\\+44[^1].*|\\+441[^6].*|\\+4416[^3].*|
    \\+44163[^2].*|\\+441632[^9].*|\\+4416329[^6].*|
    \\+44163296[^0].*)$!sip:\\1@biloxi.example.com!" .

4.2. Order/Priority Values - Processing Sequence

[RFC3761] and [RFC3403] state that the ENUM client MUST sort the NAPTRs using the ORDER field value ("lowest value is first") and SHOULD order the NAPTRs using the PREFERENCE/PRIORITY field value as the minor sort term (again, lowest value first). The NAPTRs in the sorted list must be processed in order. Subsequent NAPTRs with worse ORDER values must only be dealt with once the current ones with a better ORDER value have been processed 📋.

However, as the intro to this section explained, that stated behaviour is a simplification 🙃. Once the NAPTRs are sorted into a sequence reflecting the ORDER and PREFERENCE/PRIORITY values, other fields are also considered when evaluating the retrieved NAPTRs. Local knowledge may also play a part in the decision, once a NAPTR has reached the point in the sequence where it gets considered 🧩.

ENUM clients may also include the end user "in the decision loop", offering the end user a choice from a list of possible NAPTRs 🙋‍♀️. Conceptually, this choice is embedded within step 4 of the DDDS algorithm (as described in Section 3.3 of [RFC3402]). Since the ORDER field value is the major sort term, you'd expect a conforming ENUM client to only present the NAPTRs with the currently "best" ORDER field value as choices. When/if all of the presented options have been rejected, the ENUM client might offer the ones with the "next best" ORDER field value, and so on. This can be confusing for the end user, though, so some clients simply offer all of the available NAPTRs as options at once, in the sequence defined by the ORDER and PREFERENCE/PRIORITY fields 🌀.

In summary, ENUM clients will take into account the Services field value, the Flags field, and the Regexp ERE sub-field, along with the ORDER and PREFERENCE/PRIORITY field values. They may also consider local policies or available local knowledge 💜.

The Registrant and the ENUM zone provisioning system he or she uses must be aware of this, and SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields alone 🚨.

Specifically, it is unsafe to assume that an ENUM client will not consider another NAPTR just because there's one with a better ORDER value. The instructions in Section 4.1 and Section 8 of [RFC3403] may or may not be followed strictly by different ENUM clients, for perfectly justifiable reasons 🤷‍♀️.

Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MUST do so in the sequence defined by the ORDER and PREFERENCE/PRIORITY values specified by the Registrant 🎀.

However, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support. Even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user 🫶.

4.3. Use of Order and Preference Fields

NAPTRs in ENUM zones that hold incorrect ORDER values can cause major problems 😱. [RFC3403] highlights that having both ORDER and PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR resource record type. It's reasonable to have a common default value for the ORDER field, and rely on the PREFERENCE/PRIORITY field to indicate the preferred sort 🍓.

We've noticed a number of ENUM domains with NAPTRs that have identical PREFERENCE/PRIORITY field values and different ORDER values. This might be the result of an ENUM zone provisioning system "bug", or a misunderstanding about what the two fields are for, or simply a difference in how people interpret the standards 🤔.

To clarify: the ORDER field value is the major sort term, and the PREFERENCE/PRIORITY field value is the minor sort term. So you should expect a set of NAPTRs in a zone to have identical ORDER field values and different PREFERENCE/PRIORITY field values, not the other way around ✨.

To avoid these common interoperability issues, it is recommended that ENUM NAPTRs SHOULD hold a default value in their ORDER field 🌈.

4.4. NAPTRs with Identical ORDER/PRIORITY Values

From experience, it has been learned that there are zones that hold discrete NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values. This leads to indeterminate client behaviour, so it SHOULD NOT normally occur 😵‍💫.

Such a condition indicates that these NAPTRs are truly identical in priority, and that there's no preference between the services they offer. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence 🎲.

Multiple NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical in priority, and there is no preference between them 🙅‍♀️.

Some ENUM client implementations have considered this case to be an error and have rejected such duplicates entirely. Others have tried to further randomise the order in which such duplicates are processed. So using duplicate NAPTRs like this is unwise, because client implementations exist that will behave in different ways 💀🫠.

4.4.1. Compound NAPTRs and Implicit ORDER/REFERENCE Values 🎀

Okay so with [RFC3761], you're allowed to have more than one Enumservice hanging off a single NAPTR ✨ These Enumservices share the same Regexp field, so they all generate the same URI. That's called a "compound" NAPTR and it's giving multitasking 💅 It could totally be used for a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices, and in that case the Services field would be "E2U+voice:tel+sms:tel" 📱

Here's the tea 🫖: a compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice 🧚 These reconstructed NAPTRs all share the same ORDER and PREFERENCE/PRIORITY field values, but they should be treated as if each one had a logically different priority. The reconstructed NAPTR holding the leftmost Enumservice in the compound NAPTR gets the best priority, and the one holding the rightmost Enumservice gets the worst priority in that set 🥇

To avoid indeterminate behaviour (aka the "wait, which one goes first??" chaos 😭), it is recommended that ENUM clients SHOULD process the Enumservices within a compound NAPTR in a left-to-right sequence. And ENUM provisioning systems SHOULD assume that this processing order will be used, and provision the Enumservices within a compound NAPTR accordingly 🫶

4.5. Processing Order Value across Domains 🌈

Using a different ORDER field value in different domains is unimportant for most queries 🙄 However, DDDS has a mechanism for continuing a search for NAPTRs in another domain, by including a reference to that other domain in a "non-terminal" NAPTR. Non-terminal NAPTRs are covered in the next section. If they're supported, then the way ORDER and PREFERENCE/PRIORITY field values get processed is affected 👀

Two main questions remain from the specifications of DDDS and [RFC3761]:

  • If there is a different (lower) ORDER field value in a domain referred to by a non-terminal NAPTR, then does this mean that the ENUM client discards any remaining NAPTRs in the referring RRSet?
  • Conversely, if the domain referred to by a non-terminal NAPTR contains entries that only have a higher ORDER field value, then does the ENUM client ignore those NAPTRs in the referenced domain?

Whilst one interpretation of [RFC3761] is that the answer to both questions is "yes", this is not the way those examples of non-terminal NAPTRs that do exist (and those ENUM clients that support them) seem to be designed 🤔

In keeping with the interpretation made so far, ENUM implementations MUST consider the ORDER and PREFERENCE/PRIORITY values only within the context of the domain currently being processed in an ENUM query. These values MUST be discarded when processing other RRSets in the query 🚫

5. Non-Terminal NAPTR Processing 🦋

5.1. Non-Terminal NAPTRs - Necessity

Consider an ENUM RRSet that contains a non-terminal NAPTR record. This non-terminal NAPTR holds, as its target, another domain that has a set of NAPTRs. Basically, it's like the non-terminal NAPTR gets swapped out for the NAPTRs in the domain it points to 🔄

It's possible to have a non-terminal NAPTR in a domain that is itself pointed to by another non-terminal NAPTR. So a set of domains can form a "chain", and the list of NAPTRs to be considered is every NAPTR in all of the domains in that chain ⛓️

For an ENUM management system to support non-terminal NAPTRs, it needs to be able to analyse, validate, and (where needed) correct not only the NAPTRs in its own current ENUM domain, but also the ones referenced by non-terminal NAPTRs in other domains. If the pointed-to domains have non-terminal NAPTRs of their own, the management system will have to check each referenced domain in turn, since their contents form part of the result of a query on the "main" ENUM domain. The domain content in those referenced domains may well not be under the control of the ENUM management system, so it may not be possible to correct errors in those RRSets. This is both complex and error-prone in management system design, and any reported validation errors may well be non-intuitive for users 😵‍💫

For an ENUM client, supporting non-terminal NAPTRs can also be difficult. Processing them causes a set of sequential DNS queries that can take an indeterminate time, and requires extra resources and complexity to handle fault conditions like non-terminal loops. The indeterminacy of response time makes ENUM-supported Telephony Applications difficult (such as an "ENUM-aware" Private Branch Exchange (PBX)), whilst the added complexity and resources make support problematic in embedded devices like "ENUM-aware" mobile phones 📞

Given that, in principle a non-terminal NAPTR can be replaced by the NAPTRs in the domain it points to, so support for non-terminal NAPTRs is not needed and they may not be useful. Plus, some existing ENUM clients don't support non-terminal NAPTRs and just ignore them if received 🙃

To avoid interoperability problems, some kind of acceptable advice is needed on non-terminal NAPTRs. As current support is limited, non-terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that all of the ENUM clients this environment supports can process these. 🚨

5.2. Non-Terminal NAPTRs - Considerations

The following specific issues need to be considered if non-terminal NAPTRs are to be supported in a particular environment. These issues are gleaned from experience and indicate the kinds of conditions that should be considered before support for non-terminal NAPTRs is contemplated. Note that these issues are in addition to the point just mentioned on ENUM provisioning or management system complexity, and the potential for that management system to have no control over the zone contents that non-terminal NAPTRs in its managed zones refer to 🗂️

5.2.1. Non-Terminal NAPTRs - General

As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the NAPTRs contained in another domain. The NAPTRs in the domain referred to by the non-terminal NAPTR may have a different ORDER value from that in the referring non-terminal NAPTR. See Section 4.5 for details 👉

5.2.2. Non-Terminal NAPTRs - Loop Detection and Response

Where a chain of non-terminal NAPTRs refers back to a domain already traversed in the current query, a "non-terminal" or referential loop is implied. An implementation MAY treat a chain of more than 5 domains traversed during a single ENUM query as an indication that a self-referential loop has been entered 🔁

There are many techniques that can be used to detect such a loop, but the simple approach of counting the number of domains queried in the current ENUM query does the job just fine 🧮

Where a loop has been detected, processing SHOULD continue at the next NAPTR in the referring domain (i.e., after the non-terminal NAPTR that included the reference that triggered the loop detection) ➡️

5.2.3. Field Content in Non-Terminal NAPTRs

The set of specifications defining DDDS and its applications is complex and multi-layered. This reflects the flexibility that the system provides, but it does mean that some of the specifications need clarification as to their interpretation, particularly where non-terminal rules are concerned 🧩

5.2.3.1. Flags Field Content with Non-Terminal NAPTRs

Section 2.4.1 of [RFC3761] states that the only flag character valid for use with the "E2U" DDDS Application is u. The flag u is defined (in Section 4.3 of [RFC3404]) thus: "The "u" flag means that the output of the Rule is a URI".

Section 2.4.1 of [RFC3761] also states that an empty Flags field indicates a non-terminal NAPTR. This is also the case for other DDDS Application specifications, such as the one specified in [RFC3404]. One could well argue that this is a feature potentially common to all DDDS Applications, and so might have been specified in [RFC3402] or [RFC3403] 💭

The Flags field will be empty in non-terminal NAPTRs encountered in ENUM processing. ENUM does not have any other way to indicate a non-terminal NAPTR 🫠

5.2.3.2. Services Field Content with Non-Terminal NAPTRs

Furthermore, [RFC3761] states that any Enumservice Specification requires definition of the URI that is the expected output of this Enumservice. This means that, at present, there is no way to specify an Enumservice that is non-terminal. Such a non-terminal NAPTR has, by definition, no URI as its expected output, and instead returns a key (DNS domain name) that is to be used in the "next round" of DDDS processing 🔑

This in turn means that a non-terminal NAPTR cannot hold a valid (non-empty) Services field when used in ENUM. Section 2.4.2 of [RFC3761] specifies the syntax for this field content and requires at least one element of type <servicespec> (i.e., at least one Enumservice identifier). Given that there cannot be a non-terminal Enumservice (and so no such Registered Enumservice identifier), this syntax cannot be met with a non-terminal NAPTR; there are no non-terminal Enumservices to put into this field 🙈

A reasonable interpretation of the specifications is that for a non-terminal NAPTR, the Services field must also be empty. This appears to be the approach taken by those clients that either process non-terminal NAPTRs or check the validity of the fields 🧐

It is expected that future revisions of the ENUM standard will clarify this text, making this interpretation plain. This was the intent of the current standard, and the intent will be made explicit in its revision 📝

In keeping with existing implementations, in a non-terminal NAPTR encountered in an ENUM query, the Services field SHOULD be empty, and clients SHOULD ignore any content it contains 🫶

Of course, such non-terminal NAPTRs with an empty Services field are not specific to any DDDS Application. Thus, other means must be used to ensure that a non-terminal NAPTR intended only for a particular DDDS Application cannot be encountered during a lookup for another DDDS Application (for example, by ensuring that the same domain is not used to host NAPTRs for more than one such DDDS Application) 🌈✨💖

5.2.3.3. Regular Expression and Replacement Field Content with Non-Terminal NAPTRs 🎀

okay so the descriptive text in Section 4.1 of [RFC3403] is supposed to explain how the fields get used in a NAPTR, but the bits about the Regexp and Replacement elements have caused some major confusion 😭 about which one to use when you're dealing with non-terminal NAPTRs.

[RFC3403] is super specific that these two elements are mutually exclusive 💅. So if Regexp isn't empty, then Replacement MUST be empty, and vice versa. BUT [RFC3403] doesn't say which one gets used with terminal rules and which one gets used with non-terminal rules 🙈, so that's where the drama starts.

The descriptive text in Section 4.1 of [RFC3403] says the Replacement element holds an uncompressed domain name. So it's clear that this element can't deliver the terminal string for any DDDS Application that doesn't have a domain name as its intended terminal output 🧚.

Then the first paragraph of the descriptive text for the NAPTR Regexp element has caused some confusion too 🌈. It looks like Regexp is meant to find "the next domain name to lookup". That could make it seem like a client program processing the DDDS Application would have to look at each non-terminal NAPTR and decide whether Regexp or Replacement should be used to build the key (a domain name) for the next step of non-terminal rule processing. Kinda lots of thinking for one field 💀.

Here's the thing ✨: a NAPTR holding a terminal rule (a "terminal NAPTR") has to use the Substitution expression field to generate the expected output of that DDDS Application, so Regexp gets used in those rules too. Honestly, unless that DDDS Application has a domain name as its terminal output, Regexp is the only option 👑.

So based on the descriptive text in this section, a Replacement element can only be used in NAPTRs holding a non-terminal rule (a "non-terminal NAPTR") unless that DDDS Application has a domain name as its terminal output. Meanwhile, the other option, the Regexp element, can be used either to generate a domain name as the next key for the non-terminal case, or to generate the output of the DDDS Application 🦋.

Also, each DDDS Application is free to specify its own set of flags. That includes saying whether a particular flag goes with a terminal or non-terminal rule, and how an empty Flags field should be read (like whether it's a terminal or non-terminal rule, and if it's terminal, what the expected output is). ENUM (as specified in Section 2.4.1 of [RFC3761]) only uses the u flag, and an empty Flags field means a non-terminal NAPTR 💜.

The general case, where a client program has to check which of the two elements to use during non-terminal NAPTR processing, makes implementation way more complicated 😩. And this interpretation has NOT been made in current ENUM implementations. It would be useful to define exactly when a client can expect to process Regexp and when it should expect to process Replacement, even if it's just to make things more robust 🫶. Generating an ENUM domain name from the Regexp field is difficult at best, and impossible in the general case of a variable-length telephone number or one with more than 9 digits. So it's proposed that when the ENUM specification gets updated, this option is deprecated, and using the Regexp field for non-terminal ENUM NAPTRs is prohibited 🙅‍♀️.

To match current implementations, the target domain of a non-terminal ENUM NAPTR MUST be placed in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. On the flip side, the Regexp field MUST be empty in a non-terminal NAPTR encountered in ENUM processing, and ENUM clients MUST ignore its content 🌸.

6. Backwards Compatibility ✨

6.1. Services Field Syntax 🍓

[RFC3761] is the current standard for the syntax of NAPTRs supporting the ENUM DDDS Application. It obsoletes the original specification given in [RFC2916]. RFC 3761 changed the syntax of the Services field of the NAPTR to reflect a refinement of the concept of ENUM processing 💖.

As defined in [RFC3403], there's now a single identifier that indicates the DDDS Application. In the obsolete specification [RFC2915], there were zero or more "Resolution Service" identifiers (the equivalent of the DDDS Application). The same identifier string for either the DDDS identifier or the Resolution Service is defined in both [RFC3761] and [RFC2916]: E2U 🔥.

Also, [RFC3761] defines at least one but potentially several Enumservice sub-fields. In the obsolete specification, only one "protocol" sub-field was allowed 🌈.

In lots of ways, the biggest change for implementations is that the order of the sub-fields has been reversed 😭. [RFC3761] says the DDDS Application identifier is the leftmost sub-field, followed by one or more Enumservice sub-fields, each separated by the + character delimiter. [RFC2916] specified that the protocol sub-field was leftmost, followed by the + delimiter, and then the E2U resolution service tag ✨.

[RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404] and by [RFC3761]. However, [RFC3824] suggests that ENUM clients should be prepared to accept NAPTRs with the obsolete syntax. So an ENUM client implementation may have to deal with both forms. This doesn't need to be hard 💅. For example, an implementation could process the Services field into a set of tokens and expect exactly one of those tokens to be E2U. That way, the ENUM client could be designed to handle both the old and current forms without any extra complexity 🧚.

To make this method work, IANA should reject any request to register an Enumservice with the label E2U 🙅‍♀️.

To sum it all up 🎀: ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916], because there are still zones that hold "old" syntax NAPTRs. ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field follows [RFC3761] 🫶.

7. Collected Implications for ENUM Provisioning 🌸

ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E), unless it's clear that all ENUM clients they're designed to support can process those characters correctly. If ENUM zone provisioning systems need non-ASCII characters, those systems SHOULD encode the non-ASCII data so they only emit US-ASCII characters, using the appropriate mechanism ([RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, since ENUM clients may need to show NAPTR content in a human-readable form 👀.

The case-sensitivity flag (i) is inappropriate for ENUM, and it SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs 🙈.

ENUM zone provisioning systems SHOULD use ! (U+0021) as their Regexp delimiter character 💜.

If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (that is, \!, U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash 🔥.

If the literal character + is present in the ERE sub-field of an ENUM NAPTR, it MUST be escaped as \+ (that is, U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash 💅.

The Registrant, and the ENUM zone provisioning system they use, SHOULD NOT rely on ENUM clients solely taking account of the values of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. So a Registrant SHOULD only place contacts in their zone that they're willing to support, because even the ones with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user 🦋.

Lots of apparent mistakes in ORDER and PREFERENCE/PRIORITY values have been spotted in provisioned ENUM zones 😩. To avoid these common interoperability issues, provisioning systems SHOULD NOT use different ORDER field values for NAPTRs in a Resource Record Set (RRSet). To generalise, all ENUM NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, since it seems to be what most provisioned domains use ✨.

Multiple NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless the intent is that these NAPTRs are truly identical and there's no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in any particular sequence 🌈.

An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left-to-right order within those NAPTRs 🧚.

ENUM zone provisioning systems SHOULD assume that, once a non-terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will only be considered within the context of that referenced domain. In other words, the ORDER value is only used to sort within the current RRSet, and it won't be used when processing NAPTRs in any other RRSet 🫶.

Whilst this client behaviour is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been found with poor (or no) support for non-trivial ERE sub-field expressions 💀.

ENUM provisioning systems SHOULD be cautious when using multiple back-reference patterns in the Repl sub-field of the NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs (see also Section 3). These provisioning systems SHOULD check the back-reference replacement patterns they use, making sure regular expression processing won't produce excessive-length URIs 🌸.

Since current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it's clear that all ENUM clients that this environment supports can process them 🙈.

When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query 👑.

In a non-terminal NAPTR encountered in an ENUM query (that is, one with an empty Flags field), the Services field SHOULD be empty 🍓.

A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query 💖.

ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field follows [RFC3761] 🦋.

8. Collected Implications for ENUM Clients ✨

Okay bestie, this is the clients' checklist and it's giving very specific energy 💅 Let's go through it 🫶

  • ENUM clients SHOULD NOT discard NAPTRs where they spot characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal) 🌸 Printable characters are totally fine, so don't be picky.
  • ENUM clients MAY discard NAPTRs with octets in the Flags, Services, or Regexp fields whose byte values fall outside the US-ASCII equivalent range (aka byte values above 0x7F) 🙈 Clients MUST be ready to meet NAPTRs with those values without failing. No crashing, periodt 💀
  • ENUM clients SHOULD NOT assume the delimiter is the last character of the Regexp field 👀
    • Unless they're sure that's true in their environment, a client may still run into NAPTRs with a trailing i (case-insensitive) flag 🤷‍♀️ Even though that flag does absolutely nothing in an ENUM scenario.
  • ENUM clients SHOULD discard NAPTRs with more or fewer than 3 unescaped instances of the delimiter character in the Regexp field 🙅‍♀️
    • Being liberal with what you accept, though: if the client is sure how the Regexp field should be read, it may choose to process the NAPTR anyway, even with the wrong number of unescaped delimiters. If it's not clear how to read the Regexp field, then the client must discard the NAPTR.
  • When an ENUM client shows an end user a list of possible URLs to pick from, it MAY present all NAPTRs, not just the ones with the highest currently unprocessed ORDER value 🍓 The client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values the Registrant specified.
  • ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the order they appear in the DNS response. (No need to shuffle them again, because intervening DNS Servers might have already done that 🎀)
  • ENUM clients receiving compound NAPTRs (ones with more than one Enumservice) SHOULD process those Enumservices in a left-to-right sort order. The first one processed is the leftmost, and the last is the rightmost ✨
  • ENUM clients SHOULD only consider the ORDER field value when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by following non-terminal NAPTR references 🦋
  • ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failing 💖
  • ENUM clients MUST be ready to process NAPTRs with non-trivial patterns in their ERE sub-field values without failing 🧚
  • ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failing 👑
  • ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns in the Repl sub-field without failing (see also Section 3) 🌈
  • If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate. Processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet) 💅
  • When an ENUM client meets a compound NAPTR (one containing more than one Enumservice) and can't process or can't recognise one of the Enumservices in it, that client SHOULD ignore that Enumservice and carry on with the next Enumservice in this NAPTR's Services field. It should only discard the NAPTR if it can't handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors 🫶
  • ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916], because there are still zones holding "old" syntax NAPTRs 🕰️

8.1. Non-Terminal NAPTR Processing 🔁

Non-terminal NAPTRs are the ones with an empty Flags field, and ENUM clients MUST be ready to process them without failing 💀 More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they come across.

ENUM clients SHOULD ignore any content of the Services field when they meet a non-terminal NAPTR with an empty Flags field 🙈

Here's the big one: ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the domain name to use in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or doesn't contain a valid domain name. By definition, the Regexp field will be empty in a non-terminal NAPTR. If a non-terminal NAPTR does have a Regexp field, and it's non-empty, ENUM clients MUST ignore it 🚫

If a problem comes up while processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned. Instead, processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that pointed to the domain where the problem would have happened 🦋

If all the NAPTRs in a domain traversed because of a reference in a non-terminal NAPTR have been discarded, the ENUM client SHOULD continue with the next NAPTR in the "referring" RRSet (the one including the non-terminal NAPTR that caused the traversal) ✨

ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as a sign that a referential loop has been entered. Ooh, a loop, how spooky 👻

Last but not least: when a domain is about to be entered because of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, the client SHOULD discard that non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR 🛑

9. Security Considerations 🔐

Okay, this part is seriously important, so listen up 👂

In addition to the security implications of the recommendations in this document, the security considerations of basic ENUM use (as specified in the normative documents for this protocol) should be considered as well. This document does not negate those in any way.

The clarifications throughout this document are intended only as that: clarifications of text in the normative documents. They do not appear to have any security implications beyond those mentioned in the normative documents ✔️

The suggestions in Section 2, Section 4, and Section 6 do not appear to have any security considerations, either positive or negative 🌷

The suggestions in Section 5.2.2 are a valid approach to a known security threat. They do not give an attacker an advantage in causing excess processing or memory usage in the client. They do, however, mean that an ENUM client will traverse a "tight loop" of non-terminal NAPTRs in two domains 5 times before it detects this as a loop. This does add a slightly higher processing load than other methods would, but it avoids the risks those methods incur 🧠

As mentioned in Section 3, ENUM uses regular expressions to generate URIs. Although it's a standard feature of DDDS, the use of "non-greedy" regular expressions with multiple back-reference patterns in the Repl sub-field does create the potential for buffer-overrun attacks. 🚨 Provisioning system designers SHOULD be aware of this and SHOULD limit the repeated use of back-reference replacement patterns. On the flip side, ENUM client implementers SHOULD avoid using fixed character buffers when generating URIs from Repl sub-fields that include back-reference patterns, and MUST avoid failure in the case of buffer exhaustion. Buffers are not your friend here, bestie. 🙅‍♀️

10. Acknowledgements 🫶

We'd like to thank the many development teams who implemented ENUM (both creation systems and clients) and who read the normative documents differently 💜 Without those differences, it would've been much harder for all of us to build robust clients and suitably conservative management systems. We'd also like to thank everyone who let us check their implementations so we could explore behaviour. Their trust and help were so appreciated 🌸

Special thanks to Richard Stastny for his hard work on a similar task, TS 102 172 [ETSI-TS102172] under the aegis of ETSI, and for supporting some of the ENUM implementations that exist today 🎀

Finally, thanks to Michael Mealling for the dedication that went into such detailed DDDS specifications. Without them, the ENUM development effort would have had a much less rigorous framework to build on 👑 This document shows how complex a system it is: without the intricacy of [RFC3401] - [RFC3404] and the work that went into them, it could have been very difficult to ensure interoperability 🧚

11. References 📚

11.1. Normative References

  • [E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
  • [IEEE.1003-2.1992] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, January 1993.
  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [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.
  • [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
  • [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
  • [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
  • [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [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.
  • [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

11.2. Informative References ✨

Okay bestie, these are the "good to know" references 📚🫶 They aren't required reading to implement, but they're the receipts behind the spec 💅

[ASCII]    American National Standards Institute, "Coded Character
           Set - 7-bit American Standard Code for Information
           Interchange", ANSI X3.4, 1986.

[ETSI-TS102172]
           ETSI, "Minimum Requirements for Interoperability of
           European ENUM Implementations", ETSI TS 102 172,
           October 2004.

[RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
           (NAPTR) DNS Resource Record", RFC 2915, September 2000.

[RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
           September 2000.

[RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
           Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[RFC3824]  Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using
           E.164 numbers with the Session Initiation Protocol (SIP)",
           RFC 3824, June 2004.

Authors' Addresses 🎀

Meet the brains behind this whole thing 🧠💜 Lawrence Conroy and Kazunori Fujiwara 👑

Lawrence Conroy
Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey
United Kingdom

Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI:   http://www.sienum.co.uk
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F
3-8-1 Nishi-Kanda Chiyoda-ku
Tokyo 101-0165
JAPAN

EMail: fujiwara@jprs.co.jp
URI:   http://jprs.co.jp/en/

That's the whole spec, bestie! 🌈🦋✨

📦 where this page comes from