idnits 2.17.1 draft-bellis-enum-send-n-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. 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 : ---------------------------------------------------------------------------- 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 (June 23, 2008) is 5785 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) == Outdated reference: A later version (-09) exists of draft-ietf-enum-3761bis-03 == Outdated reference: A later version (-08) exists of draft-ietf-enum-cnam-07 == Outdated reference: A later version (-22) exists of draft-ietf-enum-enumservices-guide-10 -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping R. Bellis 3 Working Group Nominet UK 4 Internet-Draft June 23, 2008 5 Expires: December 25, 2008 7 IANA Registrations for the 'Send-N' Enumservice 8 draft-bellis-enum-send-n-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 25, 2008. 35 Abstract 37 This document requests IANA registration of an Enumservice 'Send-N' 38 and extends the definition of the 'pstndata' URI scheme. This 39 service allows more efficient support for overlapped dialling in 40 E.164 Number Mapping (ENUM) applications. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. ENUM Service Registration for "Send-N" . . . . . . . . . . . . 4 50 4. IANA Registration Template for URI scheme "pstndata" . . . . . 4 52 5. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 6.1. United Kingdom . . . . . . . . . . . . . . . . . . . . . . 6 56 6.2. North America . . . . . . . . . . . . . . . . . . . . . . 7 58 7. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. RRset size . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7.2. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 7 61 7.3. Delegations . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.4. Record positions . . . . . . . . . . . . . . . . . . . . . 8 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Intellectual Property and Copyright Statements . . . . . . . . . . 11 79 1. Introduction 81 E.164 Number Mapping (ENUM) [I-D.ietf-enum-3761bis] uses the Domain 82 Name System (DNS) [RFC1035] to refer from E.164 numbers [E.164] to 83 Uniform Resource Identifiers (URIs) [RFC3986] 85 The typical operation of PSTN telephones is that dialled digits are 86 sent to the network operator as soon as they are dialled and the call 87 is initiated as soon as the network recognises that a complete number 88 has been dialled (without using inter-digit timeouts). This PSTN 89 model for dialling is known as "overlapped dialing". This is in 90 contrast to most SIP devices and cellular devices which require the 91 user to dial a complete telephone number and then press a 'send' or 92 'dial' button to initiate dialling. 94 Currently to properly support overlapped dialling from generic PSTN 95 telephones via an ENUM-enabled switch the switch would need to 96 perform an ENUM lookup as each and every digit is dialled. This 97 would impose a significant burden on the DNS servers and could also 98 affect call setup time. 100 By publishing additional information about the structure of the ENUM 101 database it is possible to provide hints that allow unnecessary per- 102 digit DNS lookups to be skipped. 104 This additional information is encoded within NAPTR records since 105 this avoids the need for applications to issue multiple DNS requests 106 with varying QTYPEs depending on the type of information being looked 107 up. To differentiate NAPTR records containing 'Send-N' data from 108 other types of NAPTR record it is necessary to create a new 109 Enumservice which must be registered with IANA. 111 [I-D.ietf-enum-cnam] registers the 'cnam' Enumservice for PSTN data 112 with type 'pstndata' and a specific 'cnam' subtype for Calling Name 113 Delivery. It also registers the 'pstndata' Uniform Resource 114 Identifier (URI) scheme. Both the Enumservice and the URI scheme 115 documented therein are intended to be extensible to represent other 116 PSTN related data. 118 This document therefore requests the registration of a new 119 Enumservice subtype for 'Send-N' and extends the definition of the 120 'pstndata' URI scheme. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 Whilst the term "ENUM" is usually reserved for applications 129 implementing RFC3761 specifically in the public e164.arpa zone, in 130 this document it is taken to mean any system utilising an ENUM-like 131 database structure and algorithm. 133 A "full ENUM record" is an RRset containing NAPTR records about a 134 complete E.164 telephone number. 136 3. ENUM Service Registration for "Send-N" 138 The following template contains information required for the IANA 139 registrations of the 'Send-N' Enumservice: 141 Enumservice Name: Send-N 143 Enum service Class: Ancillary Application Enumservice 145 Enumservice Type: pstndata 147 Enumservice Subtype: send-n 149 URI Schemes: pstndata 151 Functional Specification: 152 This Enumservice indicates that the resource record contains 153 information that describes the structure of the ENUM database 154 tree. 156 Security Considerations: see Section 8 158 Intended Usage: COMMON 160 Author: Ray Bellis 162 4. IANA Registration Template for URI scheme "pstndata" 164 URI scheme name: pstndata 166 Status: provisional 168 URI scheme syntax: (in ABNF [RFC5234]) 169 pstndatauri =/ ( "pstndata:" sendndatatype ) 170 sendndatatype = "send-n/" [ "=" ] digitsmin 171 digitsmin = e164digitcount 172 e164digitcount = %x31-39 / (%x31 %x30-35) 173 ; 1 - 15 digits, per E.164 175 where 'pstndatauri' is imported from [I-D.ietf-enum-cnam] 177 URI scheme semantics: The URI contains information that describes the 178 structure of the ENUM database. 180 Where the URI contains an "equals" sign before the "digitsmin" field 181 then the numeric fields shall be interpreted as an absolute number of 182 digits. 184 Otherwise the information is interpreted to be relative to the domain 185 which contained the NAPTR RR which in turn contained this URI in its 186 'regexp' field. 188 Encoding considerations: None, all valid characters are in US ASCII 190 Applications: ENUM [I-D.ietf-enum-3761bis] 192 Interoperability considerations: none 194 Security considerations: see Section 8 196 Contact: Ray Bellis 198 References: [I-D.ietf-enum-cnam] 200 5. Description 202 This Enumservice and URI scheme described here are primarily intended 203 for use in private ENUM applications and are of particular relevance 204 to Infrastructure ENUM [I-D.ietf-enum-infrastructure]. 206 The NAPTR records contain meta-information about an ENUM database - 207 specifically the minimum depth in the ENUM database at which full 208 ENUM records may be found. 210 In some jurisdictions this data may be static and based on 211 information supplied by the local numbering plan administrator. It 212 is expected however that Send-N records would be synthesised 213 automatically by the DNS server based on the information currently 214 stored in its ENUM database. 216 Note that gaps in the E.164 numbering plan are not represented by 217 this data. The 'Send-N' data only indicates the _potential_ presence 218 of numbers, not their absence. The details of how the absence of 219 ENUM records should be represented (e.g. for invalid or unallocated 220 numbers) are not addressed in this document. 222 The 'digitsmin' field of the data MUST correspond to the minimum 223 number of digits to be dialled which might result in reaching a full 224 ENUM record in the ENUM database. This may be either relative to the 225 current record, or an absolute value. Absolute values are based on 226 canonical E.164 representation, as used as the input to the ENUM 227 algorithm. 229 Having received 'digitsmin' digits the application SHOULD perform 230 another DNS lookup which may return another 'Send-N' record. The 231 information received in the new record MUST override the previously 232 received information and the process repeated. 234 6. Examples 236 6.1. United Kingdom 238 An example ENUM entry containing 'Send-N' data looks like: 240 $ORIGIN 5.6.8.1.4.4.e164.nicc.org.uk. 241 @ IN NAPTR ( 100 10 "u" 242 "E2U+pstndata:send-n" 243 "!.*!pstndata:send-n/5!" . 244 ) 246 This record indicates that at least 5 additional digits are required 247 to reach any valid E.164 number beginning +441865. 249 Having received the NAPTR record from the previous example, the 250 application might subsequently receive the five additional digits 251 "33221". Based on the previously received record the application 252 knows that it need not perform any ENUM lookups for each of the next 253 four digits, but on receiving the fifth it then performs another ENUM 254 lookup, returning the record below: 256 $ORIGIN 1.2.2.3.3.5.6.8.1.4.4.e164.nicc.org.uk. 257 @ IN NAPTR ( 100 10 "u" 258 "E2U+pstndata:send-n" 259 "!.*!pstndata:send-n/1!" . 261 ) 263 This data indicates that at least one further digit needs to be 264 dialled before a full ENUM record might be returned. 266 6.2. North America 268 All E.164 numbers in the North American Numbering Plan (NANP) contain 269 exactly 11 digits. 271 $ORIGIN 1.e164.example.com. 272 @ IN NAPTR ( 100 10 "u" 273 "E2U+pstndata:send-n" 274 "!.*!pstndata:send-n/=11!" . 275 ) 277 This record indicates that a minimum of 11 digits are required for 278 any number beginning +1. The URI could alternatively have been 279 written as "pstndata:send-n/10" to specify that at least 10 280 additional digits are required. 282 7. DNS Considerations 284 7.1. RRset size 286 An RRset MUST NOT contain more than one 'Send-N' NAPTR record. This 287 document accordingly makes no recommendations on suitable values for 288 the 'order' and 'preference' fields. 290 7.2. DNS Wildcards 292 The relative form of these records SHOULD NOT be used with DNS 293 wildcards since DNS wildcards can represent an arbitrary number of 294 labels (or digits, in the ENUM case) and the data in a relative form 295 'Send-N' record is specific to an exact position in the ENUM tree. 297 7.3. Delegations 299 Where an ENUM database contains delegations then the 'digitsmin' data 300 SHOULD reflect the minimum number of digits at which delegation 301 occurs. 303 This helps to ensure that parent domains do not inadvertently provide 304 incorrect 'Send-N' data about delegated number space about which they 305 may have no knowledge. 307 7.4. Record positions 309 These records are mostly likely to be used in intermediate records in 310 the ENUM database, although in countries (such as Austria) that use 311 numbering plans where numbers may appear as leading prefixes of other 312 numbers it might be possible to find both full NAPTR records and 313 'Send-N' NAPTR records in the same RRset. 315 For example, a company switchboard might be reached by dialling the 316 main number and extensions are reached by dialling additional digits. 317 In this case there would be normal NAPTR records containing contact 318 addresses for the switchboard, but there could also be a 'Send-N' 319 record indicating the length of the internal extension numbers. 321 8. Security Considerations 323 This Enumservice and URI scheme were originally designed for use on a 324 large Infrastructure ENUM database, where no new security issues are 325 believed to be introduced through the use of this Enumservice. 327 There is a potential misuse of this data in public ENUM databases 328 where delegations are made to third parties whereby a parent zone 329 could include incorrectly high values in a 'Send-N' record. 331 That might prevent a child zone's 'Send-N' records from being looked 332 up which in return could result in the application over dialling. 333 The effect of that would depend on whether the child zone includes 334 wildcard DNS records to allow for over dialling. 336 The effect of putting incorrectly low values of 'Send-N' is benign. 338 9. IANA Considerations 340 This document requests the IANA registration of the Enumservice 341 'Send-N' with Type 'pstndata' and Subtype 'send-n' according to the 342 definitions in this document, RFCxxxx 343 [I-D.ietf-enum-enumservices-guide] and RFC3761bis 344 [I-D.ietf-enum-3761bis]. The required template is contained in 345 Section 3. 347 This document requests an update to the IANA registration of the URI 348 scheme 'pstndata' according to the definitions in this document and 349 following the process described in [RFC4395]. The required template 350 is contain in Section 4. 352 10. Change Log 354 [Note to editors: This section is to be removed before publication - 355 XML source available on request] 357 draft-bellis-enum-send-n-02 358 Minor editorial NITs from -01 fixed 359 Introduction rewritten slightly 361 draft-bellis-enum-send-n-01 362 Fixed ABNF for 'e164digitcount' 363 Removed support for 'digitsmax' 364 Introduced support for absolute digit counts 365 Expanded DNS considerations 367 draft-bellis-enum-send-n-00 368 initial draft 370 11. Acknowledgements 372 The author would like to thank those members of the Network 373 Interoperability Consultative Committee () 374 and in particular to Clive Feather, who contributed to the NICC 375 specification for a Central Number Portability Database from which 376 this work is derived. 378 The author would also like to thank Alexander Mayrhofer for his 379 assistance. 381 12. References 383 12.1. Normative References 385 [I-D.ietf-enum-3761bis] 386 Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 387 Uniform Resource Identifiers (URI) Dynamic Delegation 388 Discovery System (DDDS) Application (ENUM)", 389 draft-ietf-enum-3761bis-03 (work in progress), March 2008. 391 [I-D.ietf-enum-cnam] 392 Shockey, R., "IANA Registration for an Enumservice Calling 393 Name Delivery (CNAM) Information and IANA Registration 394 for URI type 'pstndata' URI type 'pstn'", 395 draft-ietf-enum-cnam-07 (work in progress), October 2007. 397 [I-D.ietf-enum-enumservices-guide] 398 Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 399 Registration of Enumservices: Guide, Template and IANA 400 Considerations", draft-ietf-enum-enumservices-guide-10 401 (work in progress), May 2008. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 407 Resource Identifier (URI): Generic Syntax", STD 66, 408 RFC 3986, January 2005. 410 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 411 Specifications: ABNF", STD 68, RFC 5234, January 2008. 413 12.2. Informative References 415 [E.164] ITU-T, "The international public telecommunication 416 numbering plan", Recommendation E.164 (02/05), Feb 2005. 418 [I-D.ietf-enum-infrastructure] 419 Livingood, J., "The E.164 to Uniform Resource Identifiers 420 (URI) Dynamic Delegation Discovery System (DDDS) 421 Application for Infrastructure ENUM", 422 draft-ietf-enum-infrastructure-07 (work in progress), 423 December 2007. 425 [RFC1035] Mockapetris, P., "Domain names - implementation and 426 specification", STD 13, RFC 1035, November 1987. 428 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 429 Registration Procedures for New URI Schemes", BCP 115, 430 RFC 4395, February 2006. 432 Author's Address 434 Ray Bellis 435 Nominet UK 436 Edmund Halley Road 437 Oxford OX4 4DQ 438 United Kingdom 440 Phone: +44 1865 332211 441 Email: ray.bellis@nominet.org.uk 442 URI: http://www.nominet.org.uk/ 444 Full Copyright Statement 446 Copyright (C) The IETF Trust (2008). 448 This document is subject to the rights, licenses and restrictions 449 contained in BCP 78, and except as set forth therein, the authors 450 retain all their rights. 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 455 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 456 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 457 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Intellectual Property 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at 482 ietf-ipr@ietf.org.