idnits 2.17.1 draft-ietf-enum-rfc2916bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC2916, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 27, 2003) is 7701 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 636, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 639, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. '3') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM P. Faltstrom 3 Internet-Draft Cisco Systems Inc 4 Expires: August 28, 2003 M. Mealling 5 VeriSign 6 February 27, 2003 8 The E.164 to URI DDDS Application (ENUM) 9 draft-ietf-enum-rfc2916bis-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 28, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document discusses the use of the Domain Name System (DNS) for 41 storage of E.164 numbers. More specifically, how DNS can be used for 42 identifying available services connected to one E.164 number. It 43 specifically obsoletes RFC 2916 to bring it in line with the Dynamic 44 Delegation Discovery System (DDDS) Application specification found in 45 the document series specified in RFC 3401. It is very important to 46 note that it is impossible to read and understand this document 47 without reading the documents discussed in RFC 3401. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Use for these mechanisms for private dialing plans . . . . . 3 54 1.3 Application of local policy . . . . . . . . . . . . . . . . 3 55 2. The ENUM Application Specifications . . . . . . . . . . . . 5 56 2.1 Application Unique String . . . . . . . . . . . . . . . . . 5 57 2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 5 58 2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 7 62 2.5 Partial E.164 Numbers . . . . . . . . . . . . . . . . . . . 8 63 2.6 What constitutes an 'Enum Resolver'? . . . . . . . . . . . . 8 64 3. Registration mechanism for Enumservices . . . . . . . . . . 10 65 3.1 Registration Requirements . . . . . . . . . . . . . . . . . 10 66 3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 10 67 3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 10 68 3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 11 69 3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 12 70 3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 12 71 3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 12 72 3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 12 73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 78 8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . 18 79 Normative References . . . . . . . . . . . . . . . . . . . . 19 80 Non-normative references . . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 82 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 Through transformation of E.164 [4] numbers into DNS names and the 87 use of existing DNS services like delegation through NS records and 88 NAPTR records, one can look up what services are available for a 89 specific domain name in a decentralized way with distributed 90 management of the different levels in the lookup process. 92 The domain "e164.arpa" is being populated in order to provide the 93 infrastructure in DNS for storage of E.164 numbers. In order to 94 facilitate distributed operations, this domain is divided into 95 subdomains. Holders of E.164 numbers which want to be listed in DNS 96 should contact the appropriate zone administrator in order to be 97 listed, by examining the SOA resource record associated with the 98 zone, just like in normal DNS operations. 100 Of course, as with other domains, policies for such listings will be 101 controlled on a subdomain basis and may differ in different parts of 102 the world. 104 1.1 Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119. 110 All other capitalized terms are taken from the vocabulary found in 111 the DDDS algorithm specification found in RFC 3403 [1]. 113 1.2 Use for these mechanisms for private dialing plans 115 This document specifies how "ENUM" works, that is how to handle 116 numbers allocated according to the ITU-T standard E.164. But, a 117 similar mechanism can be used also for other numbers, such as private 118 dialing plans. To implement that (a) the suffix MUST be selected, 119 MUST NOT be e164.arpa, MUST be known for all parties using the same 120 dialing plan (b) the application unique string SHOULD be the full 121 number as specified but without the leading '+'. 123 1.3 Application of local policy 125 The Order field in the NAPTR record specifies in what order the DNS 126 records are to be interpreted. This is because DNS does not 127 guarantee the order of records returned in the answer section of a 128 DNS packet. In most ENUM cases this isn't an issue because the 129 typical regular expression will be '!^.*$!' since the first query 130 often results in a terminal Rule. 132 But there are other cases (non-terminal Rules) where two different 133 Rules both match the given Application Unique String. As each Rule 134 is evaluated within the algorithm, one may match a more significant 135 piece of the AUS than the other. For example, by using a non- 136 terminal NAPTR a given set of numbers is sent to some intranet 137 specific zone. Within that zone there are two Rules that state that 138 if a match is for the entire exchange and the service is SIP related 139 then the first, SIP-specific rule is used. But the other Rule 140 matches a longer piece of the AUS, specifying that for some other 141 service (instant messaging) that the Rule denotes a departmental 142 level service. If the shorter matching Rule comes before the longer 143 match, it can 'mask' the other rules. Thus, the order in which each 144 Rule is tested against the AUS is an important corner case that many 145 DDDS applications take advantage of. 147 In the case where the zone authority wishes to state that two Rules 148 have the same effect or are identical in usage, then the Order for 149 those records is set to the same value. In that case, the Preference 150 is used to specify a locally over-ridable suggestion by the zone 151 authority that one Rule might simply be better than another for some 152 reason. 154 For ENUM this specifies where a client is allowed to apply local 155 policy and where it is not. The Order field in the NAPTR is a 156 request from the holder of the E.164 number that the records be 157 handled in a specific way. The Preference field is merely a 158 suggestion from that E.164 holder that one record might be better 159 than another. A client implementing ENUM MUST adhere to the Order 160 field but can simply take the Preference value "on advisement" as 161 part of a client context specific selection method. 163 2. The ENUM Application Specifications 165 This template defines the ENUM DDDS Application according to the 166 rules and requirements found in [1]. The DDDS database used by this 167 Application is found in [2] which is the document that defines the 168 NAPTR DNS Resource Record type. 170 2.1 Application Unique String 172 The Application Unique String is a fully qualified E.164 number minus 173 any non-digit characters except for the '+' character which appears 174 at the beginning of the number. The "+" is kept to provide a well 175 understood anchor for the AUS in order to distinguish it from other 176 telephone numbers that are not part of the E.164 namespace. 178 For example, the E.164 number could start out as "+1-770-923-9595". 179 To ensure that no syntactic sugar is allowed into the AUS, all non- 180 digits except for "+" are removed, yielding "+17709239595". 182 2.2 First Well Known Rule 184 The First Well Known Rule for this Application is the identity rule. 185 The output of this rule is the same as the input. This is because 186 the E.164 namespace and this Applications databases are organized in 187 such a way that it is possible to go directly from the name to the 188 smallest granularity of the namespace directly from the name itself. 190 Take the previous example, the AUS is "+17709239595". Applying the 191 First Well Known Rule produces the exact same string, "+17709239595". 193 2.3 Expected Output 195 The output of the last DDDS loop is a Uniform Resource Identifier in 196 its absolute form according to the 'absoluteURI' production in the 197 Collected ABNF found in RFC2396 [3]. 199 2.4 Valid Databases 201 At present only one DDDS Database is specified for this Application. 202 "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS 203 Database" (RFC 3403) [2] specifies a DDDS Database that uses the 204 NAPTR DNS resource record to contain the rewrite rules. The Keys for 205 this database are encoded as domain-names. 207 The output of the First Well Known Rule for the ENUM Application is 208 the E.164 number minus all non-digit characters except for the +. In 209 order to convert this to a unique key in this Database the string is 210 converted into a domain-name according to this algorithm: 212 1. Remove all characters with the exception of the digits. For 213 example, the First Well Known Rule produced the Key 214 "+4689761234". This step would simply remove the leading "+", 215 producing "4689761234". 217 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 219 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 221 4. Append the string ".e164.arpa" to the end. Example: 222 4.3.2.1.6.7.9.8.6.4.e164.arpa 224 This domain-name is used to request NAPTR records which may contain 225 the end result or, if the flags field is blank, produces new keys in 226 the form of domain-names from the DNS. 228 Some nameserver implementations attempt to be intelligent about items 229 that are inserted into the additional information section of a given 230 DNS response. For example, BIND will attempt to determine if it is 231 authoritative for a domain whenever it encodes one into a packet. If 232 it is, then it will insert any A records it finds for that domain 233 into the additional information section of the answer until the 234 packet reaches the maximum length allowed. It is therefore 235 potentially useful for a client to check for this additional 236 information. It is also easy to contemplate an ENUM enhanced 237 nameserver that understand the actual contents of the NAPTR records 238 it is serving and inserts more appropriate information into the 239 additional information section of the response. Thus, DNS servers 240 MAY interpret Flag values and use that information to include 241 appropriate resource records in the Additional Information portion of 242 the DNS packet. Clients are encouraged to check for additional 243 information but are not required to do so. See the Additional 244 Information Processing section of RFC 3403 [1], Section 4.2 for more 245 information on NAPTR records and the Additional Information section 246 of a DNS response packet. 248 The character set used to encode the substitution expression is UTF- 249 8. The allowed input characters are all those characters that are 250 allowed anywhere in an E.164 number. The characters allowed to be in 251 a Key are those that are currently defined for DNS domain-names. 253 2.4.1 Flags 255 This Database contains a field that contains flags that signal when 256 the DDDS algorithm has finished. At this time only one flag, "U", is 257 defined. This means that this Rule is the last one and that the 258 output of the Rule is a URI [3]. See RFC 3404 [2]. 260 If a client encounters a record with an unknown flag, it MUST ignore 261 it and move to the next Rule. This test takes precedence over any 262 ordering since flags can control the interpretation placed on fields. 263 A novel flag might change the interpretation of the regexp and/or 264 replacement fields such that it is impossible to determine if a 265 record matched a given target. 267 If this flag is not present then this rule is non-terminal. If a 268 Rule is non-terminal then clients MUST use the Key produced by this 269 Rewrite Rule as the new Key in the DDDS loop (i.e. causing the 270 client to query for new NAPTR records at the domain-name that is the 271 result of this Rule). 273 2.4.2 Services Parameters 275 Service Parameters for this Application take the following form and 276 are found in the Service field of the NAPTR record. 278 service_field = "E2U" 1*(servicespec) 279 servicespec = "+" enumservice 280 enumservice = type 0*(subtypespec) 281 subtypespec = ":" subtype 282 type = 1*32(ALPHA / DIGIT) 283 subtype = 1*32(ALPHA / DIGIT) 285 In other words, a non-optional "E2U" (used to denote ENUM only 286 Rewrite Rules in order to mitigate record collisions) followed by 1 287 or more or more Enumservices which indicate what class of 288 functionality a given end point offers. Each Enumservice is 289 indicated by an initial '+' character. 291 2.4.2.1 ENUM Services 293 Enumservice specifications contain the functional specification (i.e. 294 what it can be used for), the valid protocols, and the URI schemes 295 that may be returned. Note that there is no implicit mapping between 296 the textual string "type" or "subtype" in the grammar for the 297 Enumservice and URI schemes or protocols. The mapping, if any, have 298 to be made explicit in the specification for the Enumservice itself. 299 A registration of a specific Type also have to specify the Subtypes 300 allowed. 302 The only exception to the registration rule is for Types and Subtypes 303 used for experimental purposes, and those are to start with the facet 304 "X-". These elements are unregistered, experimental, and should be 305 used only with the active agreement of the parties exchanging them. 307 The registration mechanism is specified in Section 3. 309 2.5 Partial E.164 Numbers 311 In certain circumstances a client may be presented with a telephone 312 number for which it cannot determine if that number is a fully 313 qualified E.164 number or not. This can easily happen in situations 314 where a client is attempting to learn about a number that is from a 315 dialing plan it isn't familiar with. In this case it is possible for 316 a client to inadvertently request NAPTR records for some intermediate 317 node within the e164.arpa tree. 319 While this may happen, whether or not the behavior is useful or 320 should be standardized is undefined at this time. Thus, ENUM clients 321 SHOULD NOT attempt to query for intermediate nodes within the 322 e164.arpa tree. 324 2.6 What constitutes an 'Enum Resolver'? 326 There has been some confusion over what exactly an ENUM Resolver 327 returns and what relation that has to the 'Note 1' section in RFC 328 3402. On first reading it seems as though it might be possible for 329 an ENUM Resolver to return two Rules. The answer to that depends on 330 which of two possible definitions you use for an ENUM Resolver: 332 The first type of resolver can be called an 'intelligent' resolver. 333 It understands its target application very well. In that case the 334 test done at the beginning of Step 4 in the algorithm is a very 335 complex one. It can include call backs to the calling thread, GUI 336 events, etc. Its at this point that a client can be presented with 337 the idea of "multiple Rules" because its at this step that Order is 338 understood relative to the other ordered records. In this case the 339 ENUM Resolver still returns one Rule to the calling application but 340 its smart enough internally that it can apply application specific 341 knowledge to the Rule selection test. 343 The other type of resolver can be called a 'dumb' or 'driven' 344 resolver. It is generic in the sense that there is no internal 345 application knowledge. It is run from the 'outside' by a smart 346 application that changes the selection criteria that are fed to the 347 ENUM Resolver before it starts its resolution task. It returns one 348 Rule only and the caller has to determine if that Rule is ok or not. 349 If it isn't then it re-runs the resolver with a new set of selection 350 criteria. Some might consider the combination of this dumb resolver 351 and the application that's driving it as some uber-ENUM-Resolver. In 352 that case it can "return more than one Rule" because it can simply 353 re-run the algorithm several times to collect an appropriate set of 354 Rules. But that uber-ENUM-Resolver is stretching the definition of 355 an ENUM Resolver to the point of being unrecognizable. 357 The key point is that the Algorithm only returns one Rule. 359 3. Registration mechanism for Enumservices 361 As specified in the ABNF found in Section 2.4.2, an 'enumservice' is 362 made up of 'types' and 'subtypes'. For any given 'type', the 363 allowable 'subtypes' must be specified in the registration. There is 364 currently no concept of a registered 'subtype' outside the scope of a 365 given 'type'. Thus the registration process uses the 'type' as its 366 main key within the IANA Registry. While the combination of each 367 type and all of its subtypes constitutes the allowed values for the 368 'enumservice' field, it is not sufficient to simply document those 369 values. A complete registration will also include the allowed URI 370 schemes, a functional specification, security considerations, 371 intended usage, and any other information needed to allow for 372 interoperability within ENUM. In order to be a registered ENUM 373 Service, the entire specification, including the template, requires 374 approval by the IESG and publication of the Enumservice registration 375 specification as an RFC either on the Standards Track or as a BCP. 377 3.1 Registration Requirements 379 Service registration proposals are all expected to conform to various 380 requirements laid out in the following sections. 382 3.1.1 Functionality Requirement 384 A registered Enumservice must be able to function as a selection 385 mechanism when choosing one NAPTR resource record from another. That 386 means that the registration MUST specify what is expected when using 387 that very NAPTR record, and the URI which is the outcome of the use 388 of it. 390 Specifically, a registered Enumservice MUST specify the URI scheme(s) 391 that may be used for the Enumservice, and, when needed, other 392 information which will have to be transfered into the URI resolution 393 process itself (LDAP DNs, transferring of the AUS into the resulting 394 URI, etc). 396 3.1.2 Naming requirement 398 The Enumservice MUST be unique in order to be useful as a selection 399 criteria. Since the Enumservice is made up of a type and a type- 400 dependent subtype, it is sufficient to require that the 'type' itself 401 be unique. The 'type' MUST be unique, conform to the ABNF specified 402 in Section 2.4.2, and MUST NOT start with the facet "X-" which is 403 reserved for experimental, private use. 405 The subtype, being dependent on the type, MUST be unique within a 406 given 'type'. It must conform to the ABNF specified in Section 407 2.4.2, and MUST NOT start with the facet "X-" which is reserved for 408 experimental, private use. The subtype for one type MAY be the same 409 as a subtype for a different registered type but it is not sufficient 410 to simply reference another type's subtype. The function of each 411 subtype must be specified in the context of the type being 412 registered. 414 3.1.3 Security requirement 416 An analysis of security issues is required for all registered 417 Enumservices. (This is in accordance with the basic requirements for 418 all IETF protocols.) 420 All descriptions of security issues must be as accurate as possible 421 regardless of registration tree. In particular, a statement that 422 there are "no security issues associated with this Enumservice" must 423 not be confused with "the security issues associates with this 424 Enumservice have not been assessed". 426 There is no requirement that Enumservices registered must be secure 427 or completely free from risks. Nevertheless, all known security 428 risks must be identified in the registration of a Enumservice. 430 The security considerations section of all registrations is subject 431 to continuing evaluation and modification. 433 Some of the issues that should be looked at in a security analysis of 434 a Enumservice are: 436 1. Complex Enumservices may include provisions for directives that 437 institute actions on a user's resources. In many cases provision 438 can be made to specify arbitrary actions in an unrestricted 439 fashion which may then have devastating results. Especially if 440 there is a risk for a new ENUM lookup, and because of that an 441 infinite loop in the overall resolution process of the E.164. 443 2. Complex Enumservices may include provisions for directives that 444 institute actions which, while not directly harmful, may result 445 in disclosure of information that either facilitates a subsequent 446 attack or else violates the users privacy in some way. 448 3. An Enumservice might be targeted for applications that require 449 some sort of security assurance but do not provide the necessary 450 security mechanisms themselves. For example, a Enumservice could 451 be defined for storage of confidential medical information which 452 in turn requires an external confidentiality service. 454 3.1.4 Publication Requirements 456 Proposals for Enumservices registered must be published as RFCs on 457 the Standards Track or as a BCP. IANA will retain copies of all 458 Enumservice registration proposals and "publish" them as part of the 459 ENUM Enumservice Registration tree itself. 461 3.2 Registration procedure 463 3.2.1 IANA Registration 465 Provided that the Enumservice has obtained the necessary approval, 466 and the RFC is published, IANA will register the Enumservice and make 467 the Enumservice registration available to the community in addition 468 to the RFC publication itself. 470 3.2.1.1 Location of ENUM Enumservice Registrations 472 Enumservice registrations will be published in the IANA repository 473 and made available via anonymous FTP at the following URI: "ftp:// 474 ftp.iana.org/assignments/enum-services/". 476 3.2.1.2 Change Control 478 Change control of Enumservices stay with the IETF via the RFC 479 publication process. Especially, Enumservice registrations may not 480 be deleted; Enumservices which are no longer believed appropriate for 481 use can be declared OBSOLETE by publication of a new RFC and a change 482 to their "intended use" field; such Enumservice will be clearly 483 marked in the lists published by IANA. 485 3.2.2 Registration Template 487 Enumservice Type: 489 Enumservice Subtype(s): 491 URI Scheme(s): 493 Functional Specification: 495 Security considerations: 497 Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) 499 Author: 501 Any other information that the author deems interesting: 503 Note: In the case where a particular field has no value, that field 504 is left completely blank, especially in the case where a given type 505 has no subtypes. 507 4. Examples 509 The examples below use theoretical services which uses Enumservices 510 which might not make sense, but they are still used for educational 511 purposes. For example, the protocol used is in some cases exactly 512 the the same string as the URI scheme. That was the specification in 513 RFC 2916, but this default specification of a Enumservice is no 514 longer allowed. All Enumservices need to be registered explicitly by 515 the procedure specified in section Section 3. 517 4.1 Example 519 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. 520 IN NAPTR 10 100 "u" "E2U+sip" 521 "!^.*$!sip:info@example.com!" . 522 IN NAPTR 10 101 "u" "E2U+h323:voice" 523 "!^.*$!h323:info@example.com!" . 524 IN NAPTR 10 102 "u" "E2U+msg:mailto" 525 "!^.*$!mailto:info@example.com!" . 527 This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is 528 preferably contacted by SIP, secondly via H.323 for voice, and 529 thirdly by SMTP for messaging. Note that the tokens "sip", "msg", 530 "h323", "voice" and "mailto" are Types and Subtypes registered with 531 IANA, and they have no implicit connection with the protocols or URI 532 schemes with the same names. 534 In all cases, the next step in the resolution process is to use the 535 resolution mechanism for each of the protocols, (specified by the URI 536 schemes sip, h323 and mailto) to know what node to contact for each. 538 5. IANA Considerations 540 This memo requests that the IANA delegate the E164.ARPA domain 541 following instructions to be provided by the IAB. Names within this 542 zone are to be delegated to parties according to the ITU 543 recommendation E.164. The names allocated should be hierarchic in 544 accordance with ITU Recommendation E.164, and the codes should 545 assigned in accordance with that Recommendation. 547 IAB is to coordinate with ITU-T TSB if the technical contact for the 548 domain e164.arpa is to change, as ITU-T TSB has an operational 549 working relationship with this technical contact which needs to be 550 reestablished. 552 Delegations in the zone e164.arpa (not delegations in delegated 553 domains of e164.arpa) should be done after Expert Review, and the 554 IESG will appoint a designated expert. 556 IANA is to create a registry for ENUM Enumservices as specified in 557 Section 3. Whenever a new ENUM Enumservice is registered by the RFC 558 process in the IETF, IANA is at the time of publication of the RFC to 559 register the Enumservice and add a pointer to the RFC itself. 561 6. Security Considerations 563 As this system is built on top of DNS, one can not be sure that the 564 information one gets back from DNS is more secure than any DNS query. 565 To solve that, the use of DNSSEC [7] for securing and verifying zones 566 is to be recommended. 568 The caching in DNS can make the propagation time for a change take 569 the same amount of time as the time to live for the NAPTR records in 570 the zone that is changed. The use of this in an environment where 571 IP-addresses are for hire (for example, when using DHCP [8]) must 572 therefore be done very carefully. 574 There are a number of countries (and other numbering environments) in 575 which there are multiple providers of call routing and number/name- 576 translation services. In these areas, any system that permits users, 577 or putative agents for users, to change routing or supplier 578 information may provide incentives for changes that are actually 579 unauthorized (and, in some cases, for denial of legitimate change 580 requests). Such environments should be designed with adequate 581 mechanisms for identification and authentication of those requesting 582 changes and for authorization of those changes. 584 A large amount of Security Issues have to do with the resolution 585 process itself, and use of the URIs produced by the DDDS mechanism. 586 Those have to be specified in the registration of the ENUM 587 Enumservice used, as specified in Section 3.1.3. 589 7. Acknowledgments 591 Support and ideas leading to RFC 2916 have come from people at 592 Ericsson, Bjorn Larsson and the group which implemented this scheme 593 in their lab to see that it worked. Input has also arrived from ITU- 594 T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and 595 Enumservice Definition), the ENUM working group in the IETF, John 596 Klensin and Leif Sunnegardh. 598 This update of RFC 2916 is created with specific input from: Randy 599 Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim 600 Stralmark, Robert Walter and James Yu. 602 8. Changes since RFC 2916 604 Part from clarifications in the text in this document, the major 605 changes are two: 607 The document uses an explicit DDDS algorithm, and not only NAPTR 608 resource records in an "ad-hoc" mode. In reality this doesn't imply 609 any changes in deployed base of applications, as the algorithm used 610 for ENUM resolution is exactly the same. 612 The format of the service field has changed. The old format was of 613 the form "example+E2U", while the new format is "E2U+example". 614 Reason for this change have to with the added subtypes in the 615 enumservice, the ability to support more than one enumservice per 616 NAPTR RR, and a general agreement in the IETF that the main selector 617 between different NAPTR with the same owner (E2U in this case) should 618 be first. 620 Normative References 622 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 623 Three: The DNS Database", RFC 3403, February 2002. 625 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 626 Four: The URI Resolution Application", RFC 3404, February 2002. 628 [3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 629 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 631 [4] ITU-T, "The International Public Telecommunication Number Plan", 632 Recommendation E.164, May 1997. 634 Non-normative references 636 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 637 One: The Comprehensive DDDS Standard", RFC 3401, February 2002. 639 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 640 Two: The Algorithm", RFC 3402, February 2002. 642 [7] Eastlake, D., "Domain Name System Security Extensions", RFC 643 2535, March 1999. 645 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 646 March 1997. 648 Authors' Addresses 650 Patrik Faltstrom 651 Cisco Systems Inc 652 Ledasa 653 273 71 Lovestad 654 Sweden 656 EMail: paf@cisco.com 657 URI: http://www.cisco.com 659 Michael Mealling 660 VeriSign 661 21345 Ridgetop Circle 662 Sterling, VA 20166 663 US 665 EMail: michael@neonym.net 666 URI: http://www.verisignlabs.com 668 Full Copyright Statement 670 Copyright (C) The Internet Society (2003). All Rights Reserved. 672 This document and translations of it may be copied and furnished to 673 others, and derivative works that comment on or otherwise explain it 674 or assist in its implementation may be prepared, copied, published 675 and distributed, in whole or in part, without restriction of any 676 kind, provided that the above copyright notice and this paragraph are 677 included on all such copies and derivative works. However, this 678 document itself may not be modified in any way, such as by removing 679 the copyright notice or references to the Internet Society or other 680 Internet organizations, except as needed for the purpose of 681 developing Internet standards in which case the procedures for 682 copyrights defined in the Internet Standards process must be 683 followed, or as required to translate it into languages other than 684 English. 686 The limited permissions granted above are perpetual and will not be 687 revoked by the Internet Society or its successors or assigns. 689 This document and the information contained herein is provided on an 690 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 691 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 692 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 693 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 694 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 696 Acknowledgement 698 Funding for the RFC Editor function is currently provided by the 699 Internet Society.