idnits 2.17.1 draft-ietf-enum-experiences-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1441. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 2008) is 5635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 2916 (Obsoleted by RFC 3761) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM L. Conroy 3 Internet-Draft RMRL 4 Intended status: Informational K. Fujiwara 5 Expires: May 24, 2009 JPRS 6 November 20, 2008 8 ENUM Implementation Issues and Experiences 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 24, 2009. 36 Abstract 38 This document captures experience in implementing systems based on 39 the ENUM protocol, and experience of ENUM data that have been created 40 by others. As such, it clarifies the ENUM and Dynamic Delegation 41 Discovery System standards. Its aim is to help others by reporting 42 what is "out there" and the potential pitfalls in interpreting the 43 set of documents that specify the protocol. It does not revise the 44 standards, but it is intended to provide technical input to future 45 revisions of those documents. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Changes since last version . . . . . . . . . . . . . . . . 4 53 3. Character Sets and ENUM . . . . . . . . . . . . . . . . . . . 4 54 3.1. Character Sets - Non-ASCII considered harmful . . . . . . 4 55 3.1.1. Non-ASCII in Regular expression Field . . . . . . . . 6 56 3.1.2. Non-ASCII Support - Conclusions . . . . . . . . . . . 7 57 3.2. Case Sensitivity . . . . . . . . . . . . . . . . . . . . . 8 58 3.3. Regexp field delimiter . . . . . . . . . . . . . . . . . . 8 59 3.4. Regexp Meta-character Issue . . . . . . . . . . . . . . . 8 60 4. Unsupported NAPTRs . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1. Non-compliant client behaviour . . . . . . . . . . . . . . 10 62 5. ENUM NAPTR Processing . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Common Non-Compliant ENUM Processing . . . . . . . . . . . 11 64 5.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 12 65 5.2. Order/Priority values - Processing sequence . . . . . . . 13 66 5.3. Use of Order and Preference fields . . . . . . . . . . . . 14 67 5.4. NAPTRs with identical ORDER/PRIORITY values . . . . . . . 14 68 5.4.1. Compound NAPTRs and implicit ORDER/REFERENCE Values . 15 69 5.5. Processing Order value across Domains . . . . . . . . . . 15 70 6. Non-Terminal NAPTR Processing . . . . . . . . . . . . . . . . 16 71 6.1. Non-Terminal NAPTRs - necessity . . . . . . . . . . . . . 16 72 6.2. Non-Terminal NAPTRs - considerations . . . . . . . . . . . 17 73 6.2.1. Non-Terminal NAPTRs - general . . . . . . . . . . . . 17 74 6.2.2. Non-Terminal NAPTRs - loop detection and response . . 17 75 6.2.3. Field content in Non-Terminal NAPTRs . . . . . . . . . 18 76 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 21 77 7.1. Services field syntax . . . . . . . . . . . . . . . . . . 21 78 8. Collected Implications for ENUM Provisioning . . . . . . . . . 22 79 9. Collected Implications for ENUM clients . . . . . . . . . . . 24 80 9.1. Non-terminal NAPTR processing . . . . . . . . . . . . . . 25 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 88 Intellectual Property and Copyright Statements . . . . . . . . . . 31 90 1. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Introduction 98 2.1. Document Goal 100 The goal of this document is to clarify the ENUM and Dynamic 101 Delegation Discovery System (DDDS) standards. It does not itself 102 revise ENUM or DDDS standards, but is intended to provide technical 103 input to future revisions of those documents. It also serves to 104 advise implementers on the pitfalls that they may find. It 105 highlights areas where ENUM implementations have differed over 106 interpretation of the standards documents, or have outright failed to 107 implement some features as specified. 109 As well as clarifications to standards text, this document also 110 mentions potential choices that can be made, in an attempt to help to 111 foster interworking between components that use this protocol. The 112 reader is reminded that others may make different choices. 114 The core specifications for the E.164 Number Mapping (ENUM) protocol 115 ([RFC3761]) and the Dynamic Delegation Discovery System (DDDS, 116 [RFC3403] [RFC3401] [RFC3402] [RFC3404] [RFC3405]) are defined 117 elsewhere. Unfortunately, this document cannot provide an overview 118 of the specifications, so the reader is assumed to have read and 119 understood the complete set of ENUM normative documents. 121 The Domain Name System (DNS) is ENUM's database. ENUM uses the NAPTR 122 (Naming Authority Pointer) resource record type to store its DDDS 123 rules into DNS domains. ENUM relies on DNS services. Thus it is 124 also important for ENUM implementers to carry out a thorough analysis 125 of all of the existing DNS standard documents to understand what 126 services are provided to ENUM, and the load that ENUM provisioning 127 and queries will place on DNS. 129 A great deal of the rationale for making the choices listed in this 130 document is available to those who explore the standards. The trick 131 of course is in understanding those standards and the subtle 132 implications that are involved in some of their features. In almost 133 all cases, the choices presented here are merely selections from 134 values that are permissible within the standards. 136 2.2. Changes since last version 138 ----[RFC Editor: This section to be removed before publication]---- 139 V10-V11: Further clarification, particularly of order/preference 140 processing, and a few stray typos were removed. 142 V9-V10: Revisions to cover IESG discussions - document goal has been 143 re-clarified, acronym expansions updated, strengths adjusted to 144 reflect the standards correctly, text pre-phrased in several places, 145 text on non-ASCII characters sharpened and spelt out as operational 146 issue only, mentioned expected clarification to service field syntax 147 text in future revision of ENUM, forward references to Security 148 Considerations added, ENUM processing sequence (ORDER/PREFERENCE 149 issues) section extensively re-written, and added new sub-section 150 highlighting that some common behaviour is non-compliant, and 151 explaining rationale for this behaviour. 153 V8-V9: After AD review - emphasised document role as clarification, 154 and de-emphasised input to standard revision. Corrected more typos, 155 and simplified phrasing are re-structured slightly. 157 V7-V8: Minor textual changes have been made as a result of GEN-ART 158 and LC comments. The IANA requirement has been clarified, as has 159 non-terminal loop detection. Several cases of non-compliant 160 behaviour have been made explicit; these were implied but not stated 161 in earlier versions. 163 V6-V7: The previous version classified its advice in terms of 164 potential clarifications to standards, reminders of existing 165 standards, advice on encountered client and provisioning 166 (mis-)behaviours, and recommendations to improve interworking. Each 167 proposal was "tagged" to show the kind of recommendation made. These 168 hints have been removed in this version; they didn't help. This 169 document supports implementers of ENUM clients that consume E2U 170 Naming Authority Pointer (NAPTR) data published in DNS, and those who 171 design systems to provision data into those zones, by helping them 172 make choices on values and implementation strategies. To make this 173 clearer, this version has collected the recommendations for 174 Provisioning systems and Clients in their own sections. 176 3. Character Sets and ENUM 178 3.1. Character Sets - Non-ASCII considered harmful 180 [RFC3761] and [RFC3403] specify respectively that ENUM and NAPTRs 181 (Naming Authority Pointer resource records) support Unicode using the 182 UTF-8 encoding defined in [RFC3629]. This raises an issue where 183 implementations use "single byte" string processing routines. If 184 there are multi-byte characters within an ENUM NAPTR, incorrect 185 processing may well result from these UTF-8 unaware systems. 187 The UTF-8 encoding has a "US-ASCII equivalent range", so that all 188 characters in US-ASCII [ASCII] from 0x00 to 0x7F hexadecimal have an 189 identity map to the UTF-8 encoding; the encodings are the same. In 190 UTF-8, characters with Unicode code points above this range will be 191 encoded using more than one byte, all of which will be in the range 192 0x80 to 0xFF hexadecimal. Thus it is important to consider the 193 different fields of a NAPTR and whether or not multi-byte characters 194 can or should appear in them. 196 In addition, characters in the "non-printable" portion of US-ASCII 197 (0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) are "difficult". 198 Although NAPTRs are processed by machine, they may sometimes need to 199 be written in a "human readable" form. Specifically, if NAPTR 200 content is shown to an end user so that he or she may choose, it is 201 imperative that the content is human readable. Thus it is unwise to 202 use non-printable characters even if they lie within the US-ASCII 203 range; the ENUM client may have good reason to reject NAPTRs that 204 include these characters as they cannot readily be presented to an 205 end-user. 207 There are two numeric fields in a NAPTR; the ORDER and PREFERENCE/ 208 PRIORITY fields. As these contain binary values, no risk is involved 209 as string processing should not be applied to them. The string-based 210 fields are the Flags, Services, and Regexp fields. The Replacement 211 field holds an uncompressed domain name encoded according to the 212 standard DNS mechanism [RFC1034][RFC1035]. Internationalized Domain 213 Name (IDN) can be supported (as specified in [RFC3490], [RFC3491], 214 and [RFC3492]). Any such IDN MUST be further encoded using Punycode 215 [RFC3492]. As the Replacement field holds a domain name that is not 216 subject to replacement or modification (other than Punycode 217 processing), it is not of concern here. 219 Taking the string fields in turn, the Flags field contains characters 220 that indicate the disposition of the NAPTR. This may be empty, in 221 which case the NAPTR is "non-terminal", or it may include a flag 222 character as specified in [RFC3761]. These characters all fall into 223 the printable US-ASCII equivalent range, so multi-byte characters 224 cannot occur. 226 The Services field includes the DDDS Application identifier ("E2U") 227 used for ENUM, the '+' character used to separate Enumservices and 228 this application identifier, and a set of Enumservice identifiers, 229 any of which may embed the ':' separator character. In section 2.4.2 230 of [RFC3761] these identifier tokens are specified as 1*32 ALPHA/ 231 DIGIT, so there is no possibility of non-ASCII characters in the 232 Services field. 234 3.1.1. Non-ASCII in Regular expression Field 236 The Regexp field is more complex. It forms a sed-like substitution 237 expression, defined in [RFC3403], and consists of two sub-fields: 238 o the POSIX Extended Regular Expression (ERE) sub-field 239 [IEEE.1003-2.1992] 240 o a replacement (Repl) sub-field [RFC3403]. 242 Additionally, [RFC3403] specifies that a flag character may be 243 appended, but the only flag currently defined there (the 'i' case 244 insensitivity flag) is not appropriate for ENUM - see later in this 245 document. 247 The ERE sub-field matches against the "Application Unique String"; 248 for ENUM, this is defined in [RFC3761] to consist of digit 249 characters, with an initial '+' character. It is similar to a 250 global-number-digits production of a tel: URI, as specified in 251 [RFC3966], but with visual-separators removed. In short, it is a 252 telephone number (see [E.164]) in restricted format. All of these 253 characters fall into the US-ASCII equivalent range of UTF-8 encoding, 254 as do the characters significant to the ERE processing. 256 Strictly, the ERE might include other characters. The ERE could 257 include choice elements matching against different items, some of 258 which might not be an ENUM Application Unique String. Those 259 alternative matching elements might conceivably include non-ASCII 260 characters. As an operational issue, it is not reasonable to include 261 such constructs as ENUM NAPTRs match against telephone numbers. 263 In the normal situation in which E2U NAPTRs are provisioned in ENUM 264 domains, there will be no multi-byte characters within this sub-field 265 as the ERE will be intended to match against telephone numbers. ENUM 266 clients must be able to handle NAPTRs that do contain such multi-byte 267 characters (as the standard does not preclude them), but there is no 268 operational reason for these ever being provisioned in ENUM domains. 269 If NAPTRs provisioned in ENUM domains are encountered containing such 270 multi-byte characters, these could reasonably be discarded. 272 The Repl sub-field can include a mixture of explicit text used to 273 construct a URI and characters significant to the substitution 274 expression, as defined in [RFC3403]. Whilst the latter set all fall 275 into the US-ASCII equivalent range of UTF-8 encoding, this might not 276 be the case for all conceivable text used to construct a URI. 277 Presence of multi-byte characters could complicate URI generation and 278 processing routines. 280 URI generic syntax is defined in [RFC3986] as a sequence of 281 characters chosen from a limited subset of the repertoire of US-ASCII 282 characters. The current URIs use the standard URI character escaping 283 rules specified in the URI generic syntax, and so any multi-byte 284 characters will be pre-processed; they will not occur in the explicit 285 text used to construct a URI within the Repl sub-field. 287 3.1.1.1. Impact of Future Support for IRIs 289 As currently specified, ENUM only permits URIs to be generated in the 290 Regexp field. However, even if this were to be extended in future 291 revisions of the ENUM specification to allow the use of 292 Internationalised Resource Identifiers (IRI, defined in [RFC3987]), 293 further support for non-ASCII characters may be avoided. The IRI is 294 defined as extending the syntax of URIs, and specifies a mapping from 295 an IRI to a URI. IRI syntax allows characters with multi-byte UTF-8 296 encoding. 298 Given that this is the only place within an ENUM NAPTR where such 299 multi-byte encodings might reasonably be found, a simple solution is 300 to use the mapping method specified in section 3.1 of [RFC3987] to 301 convert any IRI into its equivalent URI. 303 This process consists of two elements; the domain part of an IRI MUST 304 be processed using Punycode if it has a non-ASCII domain name, and 305 the remainder MUST be processed using the extended escaping rules 306 specified in the IRI document if it contains characters outside the 307 normal URI repertoire. Using this process, there will be no non- 308 ASCII characters in any part of any URI, even if it has been 309 converted from an IRI that contains such characters. 311 3.1.2. Non-ASCII Support - Conclusions 313 From the analysis just given, the only place within an ENUM NAPTR 314 where non-ASCII characters might be found is the Regexp field. It is 315 possible to remove any requirement to process characters outside the 316 US-ASCII equivalent range by adding very few operational 317 restrictions. There is no obvious benefit in providing characters 318 outside this range. Handling multi-byte characters complicates 319 development and operation of client programs, and many existing 320 programs do not include such support. 322 As the gain from permitting characters outside the US-ASCII 323 equivalent range is unclear, and the costs of multi-byte character 324 processing are very clear, ENUM NAPTRs SHOULD NOT include characters 325 outside the printable US-ASCII equivalent range. 327 3.2. Case Sensitivity 329 The only place where NAPTR field content is case sensitive is in any 330 static text in the Repl sub-field of the Regexp field. Everywhere 331 else, case insensitive processing can be used. 333 The case insensitivity flag ('i') could be added at the end of the 334 Regexp field. However, in ENUM, the ERE sub-field operates on a 335 string defined as the '+' character, followed by a sequence of digit 336 characters. This flag is redundant for E2U NAPTRs, as it does not 337 act on the Repl sub-field contents. 339 Thus the case sensitivity flag is inappropriate for ENUM, and SHOULD 340 NOT be provisioned into E2U NAPTRs. 342 3.3. Regexp field delimiter 344 It is not possible to select a delimiter character that cannot appear 345 in one of the sub-fields. The '!' character is used as a delimiter 346 in all of the examples in [RFC3403] and in [RFC3761]. It is the only 347 character seen in existing zones, and a number of different client 348 implementations are still "hardwired" to expect this character as a 349 delimiter. 351 The '!' character will not normally appear in the ERE sub-field. It 352 may appear in the content of some URIs, as it is a valid character 353 (e.g. in http URLs). If it is present in the Regexp field, then that 354 instance MUST be escaped using the standard technique proposed in 355 section 3.2 of [RFC3402]; a backslash character (U+005C) should be 356 inserted before it in the string. Otherwise, a client may attempt to 357 process this as a standard delimiter and interpret the Regexp field 358 contents differently from the system that provisioned it. 360 3.4. Regexp Meta-character Issue 362 In ENUM, the ERE sub-field may include a literal character '+', as 363 the Application Unique String on which it operates includes this. 364 However, if it is present, then '+' MUST be escaped using a single 365 backslash character (to produce the sub-string U+005C U+002B), as '+' 366 is a meta-character in POSIX Extended Regular Expression syntax. 368 Not escaping the '+' character produces an invalid ERE, but is a 369 common mistake. Even standards have given incorrect examples; the 370 obsolete [RFC2916] (Section 3.4.3 example 3) has this problem. 372 For example, the following NAPTR example is incorrect: 373 * IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\\1@example.net!" . 375 A correct way to write this example is: 376 * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" 377 . 379 Note that when a NAPTR RR is shown in DNS master file syntax (as in 380 this example above), the backslash itself must be escaped using a 381 second backslash. The DNS on-the-wire packet will have only a single 382 backslash. 384 4. Unsupported NAPTRs 386 An ENUM client MAY discard a NAPTR received in response to an ENUM 387 query because: 388 o the NAPTR is syntactically or semantically incorrect, 389 o the NAPTR has a different (non-empty) DDDS Application identifier 390 from the 'E2U' used in ENUM, 391 o the NAPTR's ERE does not match the Application Unique String for 392 this ENUM query, 393 o the ENUM client does not recognise any Enumservice held in this 394 NAPTR, or 395 o this NAPTR (only) contains an Enumservice that is unsupported. 397 These conditions SHOULD NOT cause the whole ENUM query to terminate, 398 and processing SHOULD continue with the next NAPTR in the returned 399 Resource Record Set (RRSet). 401 When an ENUM client encounters a compound NAPTR (i.e. one containing 402 more than one Enumservice - see also Section 5.4.1) and cannot 403 process or cannot recognise one of the Enumservices within it, that 404 ENUM client SHOULD ignore this Enumservice and continue with the next 405 Enumservice within this NAPTR's Services field, discarding the NAPTR 406 only if it cannot handle any of the Enumservices contained. These 407 conditions SHOULD NOT be considered errors. 409 ENUM uses regular expression processing when generating URIs from the 410 REGEXP field of "terminal" NAPTRs. In common with all uses of 411 regular expressions, there is a potential for buffer overrun when 412 generating this output. There may be repeated back-reference 413 patterns in a NAPTR's Repl sub-field, and the output these generate 414 may consume a considerable amount of buffer space. 416 Even if an ENUM client would normally encounter only NAPTRs with 417 short URIs, it may also receive NAPTRs with repeated back-reference 418 patterns in their Repl sub-fields that could generate strings longer 419 than the client's buffer. Such NAPTRs may have been misconfigured 420 accidentally or by design. The client MUST NOT fail in this case. 421 It SHOULD NOT discard the entire ENUM query, but instead just discard 422 the NAPTR that would otherwise have caused this overrun. 424 If a problem is detected when processing an ENUM query across 425 multiple domains (by following non-terminal NAPTR references), then 426 the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD 427 continue at the next NAPTR after the non-terminal NAPTR that referred 428 to the domain in which the problem would have occurred. See 429 Section 6.2.2 for more details. 431 4.1. Non-compliant client behaviour 433 From experience monitoring current ENUM clients, a number of non- 434 compliant behaviours have been detected. These behaviours are 435 incorrect, but may be encountered in still operational client 436 implementations. 438 ENUM clients have been known to discard NAPTRs in which the Services 439 field holds more than one Enumservice. 441 ENUM clients have also been known to discard NAPTRs with a "non- 442 greedy" ERE sub-field expression (i.e. EREs that are dissimilar to 443 "^.*$"). 445 ENUM clients have been known to discard NAPTRs that do not use '!' as 446 their Regexp delimiter character. 448 ENUM clients have been known to discard NAPTRs in which the delimiter 449 is NOT the last character in the Regexp field. 451 ENUM clients have been known to discard NAPTRs with an empty Flags 452 field (i.e. "non-terminal" NAPTRs). 454 ENUM clients have been known to ignore the ORDER field value 455 entirely, sorting the NAPTRs in an RRSet based solely on the 456 PREFERENCE/PRIORITY field values. 458 Finally, many ENUM clients have been known to discard a NAPTR where 459 they have local knowledge that the URI that would be generated by 460 processing the NAPTR is unusable. 461 This behaviour is strictly speaking non-compliant, but might be 462 considered reasonable (see Section 5.1). 464 5. ENUM NAPTR Processing 466 ENUM is a DDDS Application, and the way in which NAPTRs in an RRSet 467 are processed reflects this. The details are described in section 468 3.3 of [RFC3402]. The client is expected to sort the records it 469 receives into a sequence and then to process these in that sequence. 470 The sequence reflects the ORDER and PREFERENCE/PRIORITY field values 471 in each of the NAPTRs. 473 The ORDER field value is the major or most significant sort term and 474 the PREFERENCE/PRIORITY field value is the minor or least significant 475 sort term. The combination of ORDER and PREFERENCE/PRIORITY field 476 values indicates the sequence chosen by the publisher of this data, 477 and NAPTRs will be considered in this sequence. 479 Once the NAPTRs are sorted into sequence, further processing is done 480 to determine if each of the NAPTRs is appropriate for this ENUM 481 evaluation. This involves looking at the Flags field. If the flag 482 field is empty, this is a "non-terminal" NAPTR, and is processed as 483 described in Section 6. 485 If the "u" Flag is present (and so the NAPTR is a "terminal" rule 486 that generates a URI), the Services field is checked to ensure that 487 this NAPTR is intended for ENUM (i.e. that this NAPTR includes the 488 "E2U" DDDS Application Identifier in the Services field). The ERE in 489 the Regexp field is checked and must match the Application Unique 490 String (AUS) for this ENUM evaluation (the queried telephone number). 491 Unless each of these checks succeeds, the NAPTR is discarded and the 492 next in sequence is processed. 494 During this processing, clients will also consider the Enumservices 495 within the Services field. Enumservices indicate the kind of 496 interaction that can be achieved through use of the URI this NAPTR 497 generates. If there is local knowledge that a NAPTR includes only an 498 Enumservice that is either not supported or not recognised, then this 499 NAPTR can be discarded and the next in sequence will be processed. 500 Thus, for a system that has support only for SIP interactions, if it 501 receives an RRSet in which the "best" NAPTR indicates the H323 502 Enumservice, then that client could reasonably discard that NAPTR and 503 go on to the next in sequence. 505 5.1. Common Non-Compliant ENUM Processing 507 The processing of ORDER and PREFERENCE/PRIORITY fields has been a 508 significant source of confusion, and many ENUM clients do not 509 implement the processing exactly as specified. 511 In particular, many ENUM clients use local prior knowledge about URIs 512 during ENUM processing. If a client has prior knowledge that a 513 particular URI will not result in an acceptable outcome, it might 514 discard that NAPTR and consider the next one in the sequence. 515 Examples of such local prior knowledge are - the URI does not 516 resolve, authentication has been recently rejected, or even that user 517 policies mark a particular URI as unacceptable (the URI could be a 518 "premium rate" telephone number that would be charged at an 519 unacceptable rate). 521 Strictly speaking, this behaviour is non-compliant if the next NAPTR 522 record has a different ORDER value. The ENUM algorithm ([RFC3402] 523 Section 3.3, and [RFC3403] section 4.1) states that, once a match has 524 been found for the Application Unique String (AUS), and the service 525 description satisfies the client's requirements, NAPTR records with a 526 larger ORDER values must not be considered (but that other NAPTR 527 records with the same ORDER value can still be considered). 529 However, embedding local knowledge about the URI within the ENUM 530 evaluation process is almost universal in systems employing ENUM. 531 Also, since the difference between ORDER and PRIORITY/PREFERENCE has 532 been unclear, NAPTR records have been provisioned in ways that would 533 make strictly compliant systems unusable in practice. Given that 534 such systems are intended to provide communications, this non- 535 compliant "embedded decision" behaviour is understandable. 537 It is proposed that when the ENUM specification is updated, 538 processing of ORDER and PRIORITY/PREFERENCE should be updated based 539 on implementation and deployment experience described in this 540 document. 542 5.1.1. Example 544 The example in this section is intended to help understanding the 545 difference between what [RFC3402] and [RFC3403] specify, and what 546 existing ENUM clients do. 548 WARNING: The NAPTR records shown in this section are intended to 549 illustrate somewhat unclear corner cases, and are not intended as 550 good examples of how to do ENUM provisioning. 552 Consider the following RRset, which maps numbers in the UK drama 553 range to one server, and all other numbers to a second server: 554 * 3600 IN NAPTR 1 1 "u" "e2u+sip" 555 "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . 556 * 3600 IN NAPTR 2 1 "u" "e2u+sip" 557 "!^(.*)$!sip:\\1@biloxi.example.com!" . 559 According to the processing specified in [RFC3402] and [RFC3403], the 560 ENUM client is never intended to consider the second rule for e.g. 561 AUS "+441632960123", even if it does not support "sips" URIs, or the 562 atlanta.example.com server cannot be reached, or the user indicates 563 not wishing to contact atlanta.example.com. However, existing ENUM 564 implementations are known to do this, and as described above, it can 565 be useful if the alternative is failing to communicate at all. 567 To prevent a client from considering the second rule for the UK drama 568 range, the example could be rewritten to have more predictable 569 behaviour as follows: 570 * 3600 IN NAPTR 1 1 "u" "e2u+sip" 571 "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . 572 * 3600 IN NAPTR 2 1 "u" "e2u+sip" 573 "!^(\\+[^4].*|\\+4[^4].*|\\+44[^1].*|\\+441[^6].*|\\+4416[^3].*| 574 \\+44163[^2].*|\\+441632[^9].*|\\+4416329[^6].*| 575 \\+44163296[^0].*)$!sip:\\1@biloxi.example.com!" . 577 5.2. Order/Priority values - Processing sequence 579 [RFC3761] and [RFC3403] state that the ENUM client MUST sort the 580 NAPTRs using the ORDER field value ("lowest value is first") and 581 SHOULD order the NAPTRs using the PREFERENCE/PRIORITY field value as 582 the minor sort term (again, lowest value first). The NAPTRs in the 583 sorted list must be processed in order. Subsequent NAPTRs with worse 584 ORDER values must only be dealt with once the current ones with a 585 better ORDER value have been processed. 587 However, as described in the introduction to this section, this 588 stated behaviour is a simplification. Once sorted into a sequence 589 reflecting ORDER and PREFERENCE/PRIORITY values, other fields are 590 also considered during evaluation of retrieved NAPTRs and local 591 knowledge may play a factor in the decision process, once a NAPTR has 592 reached that point in the sequence at which it is considered. 594 ENUM clients may also include the end user "in the decision loop", 595 offering the end user the choice from a list of possible NAPTRs. 596 Conceptually this choice is embedded within step 4 of the DDDS 597 algorithm (as described in section 3.3 of [RFC3402]). Given that the 598 ORDER field value is the major sort term, one would expect a 599 conforming ENUM client to present only those NAPTRs with the 600 currently "best" ORDER field value as choices. When/if all the 601 presented options had been rejected, then the ENUM client might offer 602 those with the "next best" ORDER field value, and so on. As this may 603 be confusing for the end user, some clients simply offer all of the 604 available NAPTRs as options to the end user for his or her selection 605 at once, in the sequence defined by the ORDER and PREFERENCE/PRIORITY 606 fields. 608 In summary, ENUM clients will take into account the Services field 609 value, the Flags field, and the Regexp ERE sub-field, along with the 610 ORDER and PREFERENCE/PRIORITY field values, and may consider local 611 policies or available local knowledge. 613 The Registrant and the ENUM zone provisioning system he or she uses 614 must be aware of this and SHOULD NOT rely on ENUM clients solely 615 taking account of the value of the ORDER and the PREFERENCE/PRIORITY 616 fields alone. 618 Specifically, it is unsafe to assume that a ENUM client will not 619 consider another NAPTR if there is one with a better ORDER value. 620 The instruction (in sections 4.1 and section 8 of [RFC3403]) may or 621 may not be followed strictly by different ENUM clients for perfectly 622 justifiable reasons. 624 Where the ENUM client presents a list of possible URLs to the end 625 user for his or her choice, it MUST do so in the sequence defined by 626 the ORDER and PREFERENCE/PRIORITY values specified by the Registrant. 628 However, a Registrant SHOULD place into his or her zone only contacts 629 that he or she is willing to support; even those with the worst ORDER 630 and PREFERENCE/PRIORITY values MAY be selected by an end user. 632 5.3. Use of Order and Preference fields 634 NAPTRs in ENUM zones that hold incorrect ORDER values can cause major 635 problems. [RFC3403] highlights that having both ORDER and 636 PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR 637 resource record type. It is reasonable to have a common default 638 value for the ORDER field, relying on the PREFERENCE/PRIORITY field 639 to indicate the preferred sort. 641 We have noticed a number of ENUM domains with NAPTRs that have 642 identical PREFERENCE/PRIORITY field values and different ORDER 643 values. This may be the result of an ENUM zone provisioning system 644 "bug" or a misunderstanding over the uses of the two fields, or 645 simply a difference of interpretation of the standards. 647 To clarify, the ORDER field value is the major sort term, and the 648 PREFERENCE/PRIORITY field value is the minor sort term. Thus one 649 should expect to have a set of NAPTRs in a zone with identical ORDER 650 field values and different PREFERENCE/PRIORITY field values; not the 651 other way around. 653 To avoid these common interoperability issues, it is recommended that 654 ENUM NAPTRs SHOULD hold a default value in their ORDER field. 656 5.4. NAPTRs with identical ORDER/PRIORITY values 658 From experience, there are zones that hold discrete NAPTRs with 659 identical ORDER and identical PREFERENCE/PRIORITY field values. This 660 will lead to indeterminate client behaviour and so SHOULD NOT 661 normally occur. 663 Such a condition indicates that these NAPTRs are truly identical in 664 priority, and there is no preference between the services these 665 NAPTRs offer. Implementers SHOULD NOT assume that the DNS will 666 deliver NAPTRs within an RRSet in a particular sequence. 668 Multiple NAPTRs with identical ORDER and identical PREFERENCE/ 669 PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless 670 the intent is that these NAPTRs are truly identical in priority and 671 there is no preference between them. 673 Some ENUM client implementations have considered this case to be an 674 error, and have rejected such duplicates entirely. Others have 675 attempted to further randomise the order in which such duplicates are 676 processed. Thus use of such duplicate NAPTRs is unwise, as client 677 implementations exist that will behave in different ways. 679 5.4.1. Compound NAPTRs and implicit ORDER/REFERENCE Values 681 With [RFC3761], it is possible to have more than one Enumservice 682 associated with a single NAPTR. These Enumservices share the same 683 Regexp field and so generate the same URI. Such a "compound" NAPTR 684 could well be used to indicate a mobile phone that supports both 685 "voice:tel" and "sms:tel" Enumservices. 686 The services field in that case would be "E2U+voice:tel+sms:tel". 688 A Compound NAPTR can be treated as a set of NAPTRs each holding a 689 single Enumservice. These reconstructed NAPTRs share the same ORDER 690 and PREFERENCE/PRIORITY field values but should be treated as if each 691 had a logically different priority. In this case the reconstructed 692 NAPTR holding the leftmost Enumservice within the Compound NAPTR has 693 a better priority, and the reconstructed NAPTR holding the rightmost 694 Enumservice has the worst priority in this set. 696 To avoid indeterminate behaviour, it is recommended that ENUM clients 697 SHOULD process the Enumservices within a compound NAPTR in a left to 698 right sequence. ENUM provisioning systems SHOULD assume that such a 699 processing order will be used and provision the Enumservices within a 700 compound NAPTR accordingly. 702 5.5. Processing Order value across Domains 704 Using a different ORDER field value in different domains is 705 unimportant for most queries. However, DDDS includes a mechanism for 706 continuing a search for NAPTRs in another domain by including a 707 reference to that other domain in a "non-terminal" NAPTR. The 708 treatment of non-terminal NAPTRs is covered in the next section, but 709 if these are supported then it does have a bearing on the way that 710 ORDER and PREFERENCE/PRIORITY field values are processed. 712 Two main questions remain from the specifications of DDDS and 713 [RFC3761]: 714 o If there is a different (lower) order field value in a domain 715 referred to by a non-terminal NAPTR, then does this mean that the 716 ENUM client discards any remaining NAPTRs in the referring RRSet? 717 o Conversely, if the domain referred to by a non-terminal NAPTR 718 contains entries that only have a higher ORDER field value, then 719 does the ENUM client ignore those NAPTRs in the referenced domain? 721 Whilst one interpretation of [RFC3761] is that the answer to both 722 questions is "yes", this is not the way that those examples of non- 723 terminal NAPTRs that do exist (and those ENUM clients that support 724 them) seem to be designed. 726 In keeping with the interpretation made so far, ENUM implementations 727 MUST consider the ORDER and PREFERENCE/PRIORITY values only within 728 the context of the domain currently being processed in an ENUM query. 729 These values MUST be discarded when processing other RRSets in the 730 query. 732 6. Non-Terminal NAPTR Processing 734 6.1. Non-Terminal NAPTRs - necessity 736 Consider an ENUM RRSet that contains a non-terminal NAPTR record. 737 This non-terminal NAPTR holds, as its target, another domain that has 738 a set of NAPTRs. In effect, this is similar to the non-terminal 739 NAPTR being replaced by the NAPTRs contained in the domain to which 740 it points. 742 It is possible to have a non-terminal NAPTR in a domain that is, 743 itself, pointed to by another non-terminal NAPTR. Thus a set of 744 domains forms a "chain", and the list of NAPTRs to be considered is 745 the set of all NAPTRs contained in all of the domains in that chain. 747 For an ENUM management system to support non-terminal NAPTRs, it is 748 necessary for it to be able to analyse, validate and (where needed) 749 correct not only the NAPTRs in its current ENUM domain but also those 750 referenced by non-terminal NAPTRs in other domains. If the domains 751 pointed to have non-terminal NAPTRs of their own, the management 752 system will have to check each of the referenced domains in turn, as 753 their contents forms part of the result of a query on the "main" ENUM 754 domain. The domain content in the referenced domains may well not be 755 under the control of the ENUM management system, and so it may not be 756 possible to correct any errors in those RRSets. This is both complex 757 and prone to error in the management system design, and any reported 758 errors in validation may well be non-intuitive for users. 760 For an ENUM client, supporting non-terminal NAPTRs can also be 761 difficult. Processing non-terminal NAPTRs causes a set of sequential 762 DNS queries that can take an indeterminate time, and requires extra 763 resources and complexity to handle fault conditions like non-terminal 764 loops. The indeterminacy of response time makes ENUM supported 765 Telephony Applications difficult (such as in an "ENUM-aware" PBX), 766 whilst the added complexity and resources needed makes support 767 problematic in embedded devices like "ENUM-aware" mobile phones. 769 Given that, in principle, a non-terminal NAPTR can be replaced by the 770 NAPTRs in the domain to which it points, support of non-terminal 771 NAPTRs is not needed and non-terminal NAPTRs may not be useful. 772 Furthermore, some existing ENUM clients do not support non-terminal 773 NAPTRs and ignore them if received. 775 To avoid interoperability problems, some kind of acceptable advice is 776 needed on non-terminal NAPTRs. As current support is limited, non- 777 terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that 778 all ENUM clients this environment supports can process these. 780 6.2. Non-Terminal NAPTRs - considerations 782 The following specific issues need to be considered if non-terminal 783 NAPTRs are to be supported in a particular environment. These issues 784 are gleaned from experience, and indicate the kinds of conditions 785 that should be considered before support for non-terminal NAPTRs is 786 contemplated. Note that these issues are in addition to the point 787 just mentioned on ENUM provisioning or management system complexity 788 and the potential for that management system to have no control over 789 the zone contents to which non-terminal NAPTRs in its managed zones 790 refer. 792 6.2.1. Non-Terminal NAPTRs - general 794 As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the 795 NAPTRs contained in another domain. The NAPTRs in the domain 796 referred to by the non-terminal NAPTR may have a different ORDER 797 value from that in the referring non-terminal NAPTR. See Section 5.5 798 for details. 800 6.2.2. Non-Terminal NAPTRs - loop detection and response 802 Where a chain of non-terminal NAPTRs refers back to a domain already 803 traversed in the current query, this implies a "non-terminal" or 804 referential loop. An implementation MAY treat a chain of more than 5 805 domains traversed during a single ENUM query as an indication that a 806 self-referential loop has been entered. 808 There are many techniques that can be used to detect such a loop, but 809 the simple approach of counting the number of domains queried in the 810 current ENUM query suffices. 812 Where a loop has been detected, processing SHOULD continue at the 813 next NAPTR in the referring domain (i.e. after the non-terminal NAPTR 814 that included the reference that triggered the loop detection). 816 6.2.3. Field content in Non-Terminal NAPTRs 818 The set of specifications defining DDDS and its applications are 819 complex and multi-layered. This reflects the flexibility that the 820 system provides, but it does mean that some of the specifications 821 need clarification as to their interpretation, particularly where 822 non-terminal rules are concerned. 824 6.2.3.1. Flags field content with Non-Terminal NAPTRs 826 [RFC3761], section 2.4.1 states that the only flag character valid 827 for use with the "E2U" DDDS Application is 'u'. The flag 'u' is 828 defined (in [RFC3404], section 4.3) thus: 'The "u" flag means that 829 the output of the Rule is a URI'. 831 [RFC3761] section 2.4.1 also states that an empty Flags field 832 indicates a non-terminal NAPTR. This is also the case for other DDDS 833 Application specifications, such as that specified in [RFC3404]. One 834 could well argue that this is a feature potentially common to all 835 DDDS Applications, and so might have been specified in [RFC3402] or 836 [RFC3403]. 838 The Flags field will be empty in non-terminal NAPTRs encountered in 839 ENUM processing. ENUM does not have any other way to indicate a non- 840 terminal NAPTR. 842 6.2.3.2. Services field content with Non-Terminal NAPTRs 844 Furthermore, [RFC3761] states that any Enumservice Specification 845 requires definition of the URI that is the expected output of this 846 Enumservice. This means that, at present, there is no way to specify 847 an Enumservice that is non-terminal; such a non-terminal NAPTR has, 848 by definition, no URI as its expected output, instead returning a key 849 (DNS domain name) that is to be used in the "next round" of DDDS 850 processing. 852 This in turn means that a non-terminal NAPTR cannot hold a valid 853 (non-empty) Services field when used in ENUM. Section 2.4.2 of 854 [RFC3761] specifies the syntax for this field content, and requires 855 at least one element of type (i.e. at least one 856 Enumservice identifier). Given that there cannot be a non-terminal 857 Enumservice (and so no such Registered Enumservice identifier), this 858 syntax cannot be met with a non-terminal NAPTR; there are no non- 859 terminal Enumservices to put into this field. 861 A reasonable interpretation of the specifications is that for a non- 862 terminal NAPTR, the Services field must also be empty. This appears 863 to be the approach taken by those clients that do either process non- 864 terminal NAPTRs or check the validity of the fields. 866 It is expected that future revisions of the ENUM standard will 867 clarify this text, making this interpretation plain. This was the 868 intent of the current standard, and the intent will be made explicit 869 in its revision. 871 In keeping with existing implementations, in a non-terminal NAPTR 872 encountered in an ENUM query, the Services field SHOULD be empty, and 873 clients SHOULD ignore any content it contains. 875 Of course, such non-terminal NAPTRs with an empty services field are 876 not specific to any DDDS application. Thus other means must be used 877 to ensure a non-terminal NAPTR that is intended only for a particular 878 DDDS application cannot be encountered during a lookup for another 879 DDDS application (for example, by ensuring that the same domain is 880 not used to host NAPTRs for more than one such DDDS application). 882 6.2.3.3. Regular Expression and Replacement field content with Non- 883 terminal NAPTRs 885 The descriptive text in section 4.1 of [RFC3403] is intended to 886 explain how the fields are to be used in a NAPTR. However, the 887 descriptions associated with the Regexp and Replacement elements have 888 led to some confusion over which of these should be considered when 889 dealing with non-terminal NAPTRs. 891 [RFC3403] is specific; these two elements are mutually exclusive. 892 This means that if the Regexp element is not empty then the 893 Replacement element must be empty, and vice versa. However, is does 894 not specify which is used with terminal and non-terminal rules. 896 The descriptive text of section 4.1 of [RFC3403] for the NAPTR 897 Replacement element shows that this element holds an uncompressed 898 domain name. Thus it is clear that this element cannot be used to 899 deliver the terminal string for any DDDS application that does not 900 have a domain name as its intended terminal output. 902 However, the first paragraph of descriptive text for the NAPTR Regexp 903 element has led to some confusion. It appears that the Regexp 904 element is to be used to find "the next domain name to lookup". This 905 might be interpreted as meaning that a client program processing the 906 DDDS application could need to examine each non-terminal NAPTR to 907 decide whether the Regexp element or instead the Replacement element 908 were to be used to construct the key (a domain name) to be used next 909 in non-terminal rule processing. 911 Given that a NAPTR holding a terminal rule (a "terminal NAPTR") must 912 use the Substitution expression field to generate the expected output 913 of that DDDS application, the Regexp element is also used in such 914 rules. Indeed, unless that DDDS application has a domain name as its 915 terminal output, the Regexp element is the only possibility. 917 Thus from the descriptive text of this section, a Replacement element 918 can be used only in NAPTRs holding a non-terminal rule (a "non- 919 terminal NAPTR") unless that DDDS Application has a domain name as 920 its terminal output, whilst the alternative Regexp element may be 921 used either to generate a domain name as the next key to be used in 922 the non-terminal case, or to generate the output of the DDDS 923 application. 925 Note that each DDDS Application is free to specify the set of flags 926 to be used with that application. This includes specifying whether a 927 particular flag is associated with a terminal or non-terminal rule, 928 and also to specify the interpretation of an empty Flags field (i.e. 929 whether this is to be interpreted as a terminal or non-terminal rule, 930 and if it is terminal, then the expected output). ENUM (as specified 931 in section 2.4.1 of [RFC3761]) uses only the 'u' flag, with an empty 932 Flags field indicating a non-terminal NAPTR. 934 The general case in which a client program must check which of the 935 two elements to use in non-terminal NAPTR processing complicates 936 implementation, and this interpretation has NOT been made in current 937 ENUM implementations. It would be useful to define exactly when a 938 client program can expect to process the Regexp element and when to 939 expect to process the Replacement element, if only to improve 940 robustness. Generating an ENUM domain name from the Regexp field is 941 difficult at best and impossible for the general case of a variable 942 length telephone number, or one that has more than 9 digits. Thus, 943 it is proposed that when the ENUM specification is updated, this 944 option is deprecated, and using the Regexp field for non-terminal 945 ENUM NAPTRs is prohibited. 947 In keeping with current implementations, the target domain of a non- 948 terminal ENUM NAPTR MUST be placed in the (non-empty) Replacement 949 field. This field MUST be interpreted as holding the domain name 950 that forms the next key output from this non-terminal rule. 951 Conversely, the Regexp field MUST be empty in a non-terminal NAPTR 952 encountered in ENUM processing and ENUM clients MUST ignore its 953 content. 955 7. Backwards Compatibility 957 7.1. Services field syntax 959 [RFC3761] is the current standard for the syntax for NAPTRs 960 supporting the ENUM DDDS application. This obsoletes the original 961 specification that was given in [RFC2916]. There has been a change 962 to the syntax of the Services field of the NAPTR that reflects a 963 refinement of the concept of ENUM processing. 965 As defined in [RFC3403], there is now a single identifier that 966 indicates the DDDS Application. In the obsolete specification 967 ([RFC2915]), there were zero or more "Resolution Service" identifiers 968 (the equivalent of the DDDS Application). The same identifier string 969 is defined in both [RFC3761] and in the old [RFC2916] specifications 970 for the DDDS identifier or the Resolution Service; "E2U". 972 Also, [RFC3761] defines at least one but potentially several 973 Enumservice sub-fields; in the obsolete specification, only one 974 "protocol" sub-field was allowed. 976 In many ways, the most important change for implementations is that 977 the order of the sub-fields has been reversed. [RFC3761] specifies 978 that the DDDS Application identifier is the leftmost sub-field, 979 followed by one or more Enumservice sub-fields, each separated by the 980 '+' character delimiter. [RFC2916] specified that the protocol sub- 981 field was the leftmost, followed by the '+' delimiter, in turn 982 followed by the "E2U" resolution service tag. 984 [RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404] 985 and by [RFC3761]. However, [RFC3824] suggests that ENUM clients 986 should be prepared to accept NAPTRs with the obsolete syntax. Thus, 987 an ENUM client implementation may have to deal with both forms. This 988 need not be difficult. For example, an implementation could process 989 the Services field into a set of tokens, and expect exactly one of 990 these tokens to be "E2U". In this way, the ENUM client might be 991 designed to handle both the old and the current forms without added 992 complexity. 994 To facilitate this method, IANA should reject any request to register 995 an Enumservice with the label "E2U". 997 To summarise, ENUM clients MUST support ENUM NAPTRs according to 998 [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs 999 according to the obsolete syntax of [RFC2916]; there are still zones 1000 that hold "old" syntax NAPTRs. ENUM zones MUST NOT be provisioned 1001 with NAPTRs according to the obsolete form, and MUST be provisioned 1002 with NAPTRs in which the Services field is according to [RFC3761]. 1004 8. Collected Implications for ENUM Provisioning 1006 ENUM NAPTRs SHOULD NOT include characters outside the printable US- 1007 ASCII equivalent range (U+0020 to U+007E) unless it is clear that all 1008 ENUM clients they are designed to support will be able correctly to 1009 process such characters. If ENUM zone provisioning systems require 1010 non-ASCII characters, these systems SHOULD encode the non-ASCII data 1011 to emit only US-ASCII characters by applying the appropriate 1012 mechanism ([RFC3492], [RFC3987]). Non-printable characters SHOULD 1013 NOT be used, as ENUM clients may need to present NAPTR content in a 1014 human-readable form. 1016 The case sensitivity flag ('i') is inappropriate for ENUM, and SHOULD 1017 NOT be provisioned into the Regexp field of E2U NAPTRs. 1019 ENUM zone provisioning systems SHOULD use '!' (U+0021) as their 1020 Regexp delimiter character. 1022 If the Regexp delimiter is a character in the static text of the Repl 1023 sub-field, it MUST be "escaped" using the escaped-delimiter 1024 production of the BNF specification shown in section 3.2 of [RFC3402] 1025 (i.e. "\!", U+005C U+0021). Note that when a NAPTR RR is entered in 1026 DNS master file syntax, the backslash itself must be escaped using a 1027 second backslash. 1029 If present in the ERE sub-field of an ENUM NAPTR, the literal 1030 character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note 1031 that, as always, when a NAPTR RR is entered in DNS master file 1032 syntax, the backslash itself must be escaped using a second 1033 backslash. 1035 The Registrant and the ENUM zone provisioning system he or she uses 1036 SHOULD NOT rely on ENUM clients solely taking account of the value of 1037 the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a 1038 Registrant SHOULD place into his or her zone only contacts that he or 1039 she is willing to support; even those with the worst ORDER and 1040 PREFERENCE/PRIORITY values MAY be selected by an end user. 1042 Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have 1043 been detected in provisioned ENUM zones. To avoid these common 1044 interoperability issues, provisioning systems SHOULD NOT use 1045 different ORDER field values for NAPTRs in a Resource Record Set 1046 (RRSet). To generalise, all ENUM NAPTRs SHOULD hold a default value 1047 in their ORDER field. A value of "100" is recommended, as it seems 1048 to be used in most provisioned domains. 1050 Multiple NAPTRs with identical ORDER and identical PREFERENCE/ 1051 PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless 1052 the intent is that these NAPTRs are truly identical and there is no 1053 preference between them. Implementers SHOULD NOT assume that the DNS 1054 will deliver NAPTRs within an RRSet in a particular sequence. 1056 An ENUM zone provisioning system SHOULD assume that, if it generates 1057 compound NAPTRs, the Enumservices will normally be processed in left 1058 to right order within such NAPTRs. 1060 ENUM zone provisioning systems SHOULD assume that, once a non- 1061 terminal NAPTR has been selected for processing, the ORDER field 1062 value in a domain referred to by that non-terminal NAPTR will be 1063 considered only within the context of that referenced domain (i.e. 1064 the ORDER value will be used only to sort within the current RRSet, 1065 and will not be used in the processing of NAPTRs in any other RRSet). 1067 Whilst this client behaviour is non-compliant, ENUM provisioning 1068 systems and their users should be aware that some ENUM clients have 1069 been detected with poor (or no) support for non-trivial ERE sub-field 1070 expressions. 1072 ENUM provisioning systems SHOULD be cautious in the use of multiple 1073 back-reference patterns in the Repl sub-field of NAPTRs they 1074 provision. Some Clients have limited buffer space for character 1075 expansion when generating URIs (See also Section 4). These 1076 provisioning systems SHOULD check the back-reference replacement 1077 patterns they use, ensuring that regular expression processing will 1078 not produce excessive length URIs. 1080 As current support is limited, non-terminal NAPTRs SHOULD NOT be 1081 provisioned in ENUM zones unless it is clear that all ENUM clients 1082 this environment supports can process these. 1084 When populating a set of domains with NAPTRs, ENUM zone provisioning 1085 systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 1086 such NAPTRs will be processed in an ENUM query. 1088 In a non-terminal NAPTR encountered in an ENUM query (i.e. one with 1089 an empty Flags field), the Services field SHOULD be empty. 1091 A non-terminal NAPTR MUST include its target domain in the (non- 1092 empty) Replacement field. This field MUST be interpreted as holding 1093 the domain name that forms the next key output from this non-terminal 1094 rule. The Regexp field MUST be empty in a non-terminal NAPTR 1095 intended to be encountered during an ENUM query. 1097 ENUM zones MUST NOT be provisioned with NAPTRs according to the 1098 obsolete form, and MUST be provisioned with NAPTRs in which the 1099 services field is according to [RFC3761]. 1101 9. Collected Implications for ENUM clients 1103 ENUM clients SHOULD NOT discard NAPTRs in which they detect 1104 characters outside the US-ASCII "printable" range (0x20 to 0x7E 1105 hexadecimal). 1107 ENUM clients MAY discard NAPTRs that have octets in the Flags, 1108 Services, or Regexp fields that have byte values outside the US-ASCII 1109 equivalent range (i.e. byte values above 0x7F). Clients MUST be 1110 ready to encounter NAPTRs with such values without failure. 1112 ENUM clients SHOULD NOT assume that the delimiter is the last 1113 character of the Regexp field. 1114 Unless they are sure that in their environment this is the case, 1115 in general an ENUM client may still encounter NAPTRs that have 1116 been provisioned with a following 'i' (case insensitive) flag, 1117 even though that flag has no effect at all in an ENUM scenario. 1119 ENUM clients SHOULD discard NAPTRs that have more or less than 3 1120 unescaped instances of the delimiter character within the Regexp 1121 field. 1122 In the spirit of being liberal with what it will accept, if the 1123 ENUM client is sure how the Regexp field should be interpreted, 1124 then it may choose to process the NAPTR even in the face of an 1125 incorrect number of unescaped delimiter characters. If this is 1126 not clear, then the client must discard the NAPTR. 1128 Where the ENUM client presents a list of possible URLs to the end 1129 user for his or her choice, it MAY present all NAPTRs, not just the 1130 ones with the highest currently unprocessed ORDER field value. The 1131 client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values 1132 specified by the Registrant. 1134 ENUM clients SHOULD accept all NAPTRs with identical ORDER and 1135 identical PREFERENCE/PRIORITY field values, and process them in the 1136 sequence in which they appear in the DNS response. (There is no 1137 benefit in further randomising the order in which these are 1138 processed, as intervening DNS Servers might have done this already). 1140 ENUM clients receiving compound NAPTRs (i.e. ones with more than one 1141 Enumservice) SHOULD process these Enumservices using a left-to-right 1142 sort ordering, so that the first Enumservice to be processed will be 1143 the leftmost one, and the last will be the rightmost one. 1145 ENUM clients SHOULD consider the ORDER field value only when sorting 1146 NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be 1147 taken into account when processing NAPTRs across a sequence of DNS 1148 queries created by traversal of non-terminal NAPTR references. 1150 ENUM clients MUST be ready to process NAPTRs that use a different 1151 character from '!' as their Regexp Delimiter without failure. 1153 ENUM clients MUST be ready to process NAPTRs that have non-trivial 1154 patterns in their ERE sub-field values without failure. 1156 ENUM clients MUST be ready to process NAPTRs with a DDDS Application 1157 identifier other than 'E2U' without failure. 1159 ENUM clients MUST be ready to process NAPTRs with many copies of 1160 back-reference patterns within the Repl sub-field without failure 1161 (see also Section 4). 1163 If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query 1164 to terminate and processing SHOULD continue with the next NAPTR in 1165 the returned Resource Record Set (RRSet). 1167 When an ENUM client encounters a compound NAPTR (i.e. one containing 1168 more than one Enumservice) and cannot process or cannot recognise one 1169 of the Enumservices within it, that ENUM client SHOULD ignore this 1170 Enumservice and continue with the next Enumservice within this 1171 NAPTR's Services field, discarding the NAPTR only if it cannot handle 1172 any of the Enumservices contained. These conditions SHOULD NOT be 1173 considered errors. 1175 ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. 1176 ENUM clients SHOULD also support ENUM NAPTRs according to the 1177 obsolete syntax of [RFC2916]; there are still zones that hold "old" 1178 syntax NAPTRs. 1180 9.1. Non-terminal NAPTR processing 1182 ENUM clients MUST be ready to process NAPTRs with an empty Flags 1183 field ("non-terminal" NAPTRs) without failure. More generally, non- 1184 terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY 1185 discard non-terminal NAPTRs they encounter. 1187 ENUM clients SHOULD ignore any content of the Services field when 1188 encountering a non-terminal NAPTR with an empty Flags field. 1190 ENUM clients receiving a non-terminal NAPTR with an empty Flags field 1191 MUST treat the Replacement field as holding the domain name to be 1192 used in the next round of the ENUM query. An ENUM client MUST 1193 discard such a non-terminal NAPTR if the Replacement field is empty 1194 or does not contain a valid domain name. By definition, it follows 1195 that the Regexp field will be empty in such a non-terminal NAPTR. If 1196 present in a non-terminal NAPTR, a non-empty Regexp field MUST be 1197 ignored by ENUM clients. 1199 If a problem is detected when processing an ENUM query across 1200 multiple domains (by following non-terminal NAPTR references), then 1201 the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD 1202 continue at the next NAPTR after the non-terminal NAPTR that referred 1203 to the domain in which the problem would have occurred. 1205 If all NAPTRs in a domain traversed as a result of a reference in a 1206 non-terminal NAPTR have been discarded, then the ENUM client SHOULD 1207 continue its processing with the next NAPTR in the "referring" RRSet 1208 (i.e. the one including the non-terminal NAPTR that caused the 1209 traversal). 1211 ENUM clients MAY consider a chain of more than 5 "non-terminal" 1212 NAPTRs traversed in a single ENUM query as an indication that a 1213 referential loop has been entered. 1215 Where a domain is about to be entered as the result of a reference in 1216 a non-terminal NAPTR, and the ENUM client has detected a potential 1217 referential loop, then the client SHOULD discard the non-terminal 1218 NAPTR from its processing and continue with the next NAPTR in its 1219 list. It SHOULD NOT make the DNS query indicated by that non- 1220 terminal NAPTR. 1222 10. Security Considerations 1224 In addition to the security implications of recommendations in this 1225 document, those in the basic use of ENUM (and specified in the 1226 normative documents for this protocol) should be considered as well; 1227 this document does not negate those in any way. 1229 The clarifications throughout this document are intended only as 1230 that; clarifications of text in the normative documents. They do not 1231 appear to have any security implications above those mentioned in the 1232 normative documents. 1234 The suggestions in Section 3, Section 5, and Section 7 do not appear 1235 to have any security considerations (either positive or negative). 1237 The suggestions in Section 6.2.2 are a valid approach to a known 1238 security threat. It does not open an advantage to an attacker in 1239 causing excess processing or memory usage in the client. It does, 1240 however, mean that an ENUM client will traverse a "tight loop" of 1241 non-terminal NAPTRs in two domains 5 times before the client detects 1242 this as a loop; this does introduce slightly higher processing load 1243 than would be provided using other methods, but avoids the risks they 1244 incur. 1246 As mentioned in Section 4, ENUM uses regular expressions to generate 1247 URIs. Though it is a standard feature of DDDS, use of "non-greedy" 1248 regular expressions with multiple back-reference patterns in the Repl 1249 sub-field does create the potential for buffer overrun attacks. 1250 Provisioning system designers SHOULD be aware of this and SHOULD 1251 limit the repeated use of Back-reference replacement patterns. 1252 Conversely, ENUM client implementers SHOULD avoid using fixed 1253 character buffers when generating URIs from Repl sub-fields that 1254 include Back-reference patterns, and MUST avoid failure in the case 1255 of buffer exhaustion. 1257 11. IANA Considerations 1259 This document includes one IANA consideration. This is the 1260 suggestion (in Section 7.1) that no-one should be allowed to register 1261 an Enumservice with any of its identifying tags set to "E2U". 1263 This document cannot require IANA action. However, it is expected 1264 that the update to the ENUM standard will reflect the proposal made 1265 here, and so the following requirement will be included there. 1266 IANA MUST NOT register an Enumservice with any of its identifying 1267 tags set to "E2U". Any such requests SHALL be rejected. 1269 12. Acknowledgements 1271 We would like to thank the various development teams who implemented 1272 ENUM (both creation systems and clients) and who read the normative 1273 documents differently - without these differences it would have been 1274 harder for us all to develop robust clients and suitably conservative 1275 management systems. We would also thank those who allowed us to 1276 check their implementations to explore behaviour; their trust and 1277 help were much appreciated. 1279 In particular, thanks to Richard Stastny for his hard work on a 1280 similar task TS 102 172 [ETSI-TS102172] under the aegis of ETSI, and 1281 for supporting some of the ENUM implementations that exist today. 1283 Finally, thanks for the dedication of Michael Mealling in giving us 1284 such detailed DDDS specifications, without which the ENUM development 1285 effort would have had a less rigourous framework on which to build. 1286 This document reflects how complex a system it is: Without the 1287 intricacy of [RFC3401] - [RFC3404] and the work that went into them, 1288 it could have been very difficult to ensure interoperability. 1290 13. References 1292 13.1. Normative References 1294 [E.164] ITU-T, "The International Public Telecommunication Number 1295 Plan", Recommendation E.164, February 2005. 1297 [IEEE.1003-2.1992] 1298 Institute of Electrical and Electronics Engineers, 1299 "Information Technology - Portable Operating System 1300 Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", 1301 IEEE Standard 1003.2, January 1993. 1303 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1304 STD 13, RFC 1034, November 1987. 1306 [RFC1035] Mockapetris, P., "Domain names - implementation and 1307 specification", STD 13, RFC 1035, November 1987. 1309 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1310 Part Two: The Algorithm", RFC 3402, October 2002. 1312 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1313 Part Three: The Domain Name System (DNS) Database", 1314 RFC 3403, October 2002. 1316 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1317 Part Four: The Uniform Resource Identifiers (URI)", 1318 RFC 3404, October 2002. 1320 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1321 Part Five: URI.ARPA Assignment Procedures", BCP 65, 1322 RFC 3405, October 2002. 1324 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1325 "Internationalizing Domain Names in Applications (IDNA)", 1326 RFC 3490, March 2003. 1328 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1329 Profile for Internationalized Domain Names (IDN)", 1330 RFC 3491, March 2003. 1332 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1333 for Internationalized Domain Names in Applications 1334 (IDNA)", RFC 3492, March 2003. 1336 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1337 10646", STD 63, RFC 3629, November 2003. 1339 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1340 Resource Identifiers (URI) Dynamic Delegation Discovery 1341 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1343 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1344 RFC 3966, December 2004. 1346 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1347 Resource Identifier (URI): Generic Syntax", STD 66, 1348 RFC 3986, January 2005. 1350 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1351 Identifiers (IRIs)", RFC 3987, January 2005. 1353 13.2. Informative References 1355 [ASCII] American National Standards Institute, "Coded Character 1356 Set - 7-bit American Standard Code for Information 1357 Interchange", ANSI X3.4, 1986. 1359 [ETSI-TS102172] 1360 ETSI, "Minimum Requirements for Interoperability of 1361 European ENUM Implementations", ETSI TS 102 172, 1362 October 2004. 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, March 1997. 1367 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1368 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1370 [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, 1371 September 2000. 1373 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1374 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 1376 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 1377 E.164 numbers with the Session Initiation Protocol (SIP)", 1378 RFC 3824, June 2004. 1380 Authors' Addresses 1382 Lawrence Conroy 1383 Roke Manor Research 1384 Roke Manor 1385 Old Salisbury Lane 1386 Romsey 1387 United Kingdom 1389 Phone: +44-1794-833666 1390 Email: lconroy@insensate.co.uk 1391 URI: http://www.sienum.co.uk 1393 Kazunori Fujiwara 1394 Japan Registry Service Co., Ltd. 1395 Chiyoda First Bldg. East 13F 1396 3-8-1 Nishi-Kanda Chiyoda-ku 1397 Tokyo 101-0165 1398 JAPAN 1400 Email: fujiwara@jprs.co.jp 1401 URI: http://jprs.jp/en/ 1403 Full Copyright Statement 1405 Copyright (C) The IETF Trust (2008). 1407 This document is subject to the rights, licenses and restrictions 1408 contained in BCP 78, and except as set forth therein, the authors 1409 retain all their rights. 1411 This document and the information contained herein are provided on an 1412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1414 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1415 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1416 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1419 Intellectual Property 1421 The IETF takes no position regarding the validity or scope of any 1422 Intellectual Property Rights or other rights that might be claimed to 1423 pertain to the implementation or use of the technology described in 1424 this document or the extent to which any license under such rights 1425 might or might not be available; nor does it represent that it has 1426 made any independent effort to identify any such rights. Information 1427 on the procedures with respect to rights in RFC documents can be 1428 found in BCP 78 and BCP 79. 1430 Copies of IPR disclosures made to the IETF Secretariat and any 1431 assurances of licenses to be made available, or the result of an 1432 attempt made to obtain a general license or permission for the use of 1433 such proprietary rights by implementers or users of this 1434 specification can be obtained from the IETF on-line IPR repository at 1435 http://www.ietf.org/ipr. 1437 The IETF invites any interested party to bring to its attention any 1438 copyrights, patents or patent applications, or other proprietary 1439 rights that may cover technology that may be required to implement 1440 this standard. Please address the information to the IETF at 1441 ietf-ipr@ietf.org.