idnits 2.17.1 draft-ietf-enum-cnam-08.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 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 747. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations:' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' an IANA Considerations Section in RFCs", BCP 26, October' ) ** The abstract seems to contain references ([20], [15], [2], [21], [3], [16], [22], [17], [4], [18], [5], [19], [6], [7], [8], [9], [10], [11], [12], [13], [ENUM], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 515: '... MUST include both the reques...' 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 (September 22, 2008) is 5695 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) -- Missing reference section? '16' on line 597 looks like a reference -- Missing reference section? '1' on line 565 looks like a reference -- Missing reference section? '2' on line 569 looks like a reference -- Missing reference section? '3' on line 572 looks like a reference -- Missing reference section? '4' on line 575 looks like a reference -- Missing reference section? '5' on line 579 looks like a reference -- Missing reference section? '6' on line 583 looks like a reference -- Missing reference section? '7' on line 586 looks like a reference -- Missing reference section? '8' on line 590 looks like a reference -- Missing reference section? '15' on line 653 looks like a reference -- Missing reference section? '18' on line 605 looks like a reference -- Missing reference section? '17' on line 600 looks like a reference -- Missing reference section? '9' on line 626 looks like a reference -- Missing reference section? '10' on line 630 looks like a reference -- Missing reference section? '11' on line 637 looks like a reference -- Missing reference section? '12' on line 642 looks like a reference -- Missing reference section? '13' on line 646 looks like a reference -- Missing reference section? '14' on line 650 looks like a reference -- Missing reference section? '19' on line 608 looks like a reference -- Missing reference section? '20' on line 611 looks like a reference -- Missing reference section? '21' on line 615 looks like a reference -- Missing reference section? '22' on line 619 looks like a reference -- Missing reference section? 'ENUM' on line 558 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group R. Shockey-editor 3 INTERNET-DRAFT NeuStar 4 Intended Status : Standards Track September 22, 2008 5 Expires: February 2009 7 IANA Registration for an Enumservice Calling Name Delivery 8 (CNAM) Information and IANA Registration for URI type 9 'pstndata' 11 draft-ietf-enum-cnam-08.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents 16 that any applicable patent or other IPR claims of which he or 17 she is aware have been or will be disclosed, and any of which 18 he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet- Drafts. 26 Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by 28 other documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them other 30 than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed 36 at http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 22, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document registers the Enumservice 'pstndata' and 47 subtype 'cnam' using the URI scheme 'pstndata:' as per the 48 IANA registration process defined in the ENUM specification, 49 RFC 3761 and registers a new URI type 'pstndata:'. 51 This data is used to facilitate the transfer of Calling Name 52 Delivery (CNAM) data for calls that originate on the Public 53 Switched Telephone Network (PSTN) that may be displayed on 54 VoIP or other Real-time Client User Agents (CUA). The 55 pstndata URI is created to facilitate this transfer, however 56 this URI may be used to transport other PSTN data in the 57 future. 59 Table of Contents 61 1. Introduction ........................................ 3 62 2. Protocol Design Considerations. ..................... 4 63 3. Definition of PSTN CNAM Data ........................ 4 64 4. The PSTNDATA URI .................................... 4 65 5. Enumservice Privacy Responses and Parameters ........ 5 66 6. Distribution of CNAM Data ........................... 6 67 7. Enumservice CNAM Response Examples .................. 6 68 8. Usage Considerations ................................ 7 69 9. Privacy Considerations .............................. 7 70 10. Security Considerations ............................ 8 71 11. IANA Considerations ................................ 9 72 11.1 IANA Enumservice Registration for "pstndata" with 73 subtype "cnam"........................................ 9 74 11.2 IANA Registration Template for URI "pstndata:".. 10 75 11.3 Datatype Token Registry......................... 13 76 11.4 IANA Registration Template for datatype Token 77 "cnam"............................................... 13 78 12. Normative References .............................. 14 79 13. Informative References ............................ 15 80 14. Acknowledgements .................................. 16 81 15. Author's Address .................................. 16 82 16. Full Copyright Statement .......................... 17 84 Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 87 "SHALLNOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as 89 described in RFC 2119 [16]. 91 1. Introduction 93 RFC 3761 (ENUM) [1] is a system that transforms E.164 94 numbers (The International Public Telecommunication Number 95 Plan, ITU-T Recommendation E.164) [2] into domain names and 96 then uses the Domain Name System (DNS), RFC 1034 [3] and 97 Naming Authority Pointer Records (NAPTR) records in the 98 Dynamic Delegation Discovery System (DDDS) RFC 3403 [4]) to 99 query the services that are available for a specific domain 100 name. 102 This document registers an Enumservice 'cnam' according to 103 the guidelines given in RFC 3761 [1], to be used for 104 provisioning a NAPTR [4] resource record to indicate a type 105 of functionality associated with an end point and/or 106 telephone number. The registration is defined within the DDDS 107 (Dynamic Delegation Discovery System 108 [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS 109 Application defined in RFC 3761. This document also 110 registers an IANA URI type 'pstndata' per the requirements of 111 RFC 4395[15]. 113 The purpose of this Enumservice is to enable service 114 providers to place Calling Name Delivery information (CNAM) 115 into ENUM databases or to send ENUM queries to a protocol 116 converter that would have access to the Signaling System 7 117 (SS7) Network. This, in turn, could enable such parties to 118 offer Calling Name Delivery services using the technology 119 provided by RFC 3761 [1]. 121 The service parameters defined in RFC 3761 [1] dictate that a 122 'type' and one or more 'subtype' should be specified. Within 123 this set of specifications the convention is assumed that the 124 'type' (being the more generic term) defines the service and 125 at least one of the 'subtype' may indicate the URI scheme. 127 In this document, one type is specified, 'pstndata' and one 128 subtype 'cnam' with the URI scheme specified, 'pstndata:'. 130 2. Protocol Design Considerations. 132 The design of this protocol was influenced by several 133 factors. RFC 3761 [1] has become the defacto query-response 134 protocol of choice for a variety of data types associated 135 with E.164 numbering and addressing including data not 136 necessarily associated with a SIP [18] or other 137 communications session. RFC 3761 [1] is already being used by 138 service providers to query for data that has significant 139 privacy or security issues associated with it. RFC 4769 [17], 140 for instance, describes an Enumservice that associates an 141 E.164 number with a PSTN Local Routing Number. An Enumservice 142 for CNAM data has similar design requirements of being used 143 in private and closed systems. 145 Communications service providers are concerned with the 146 impact of call setup up times on the overall user experience. 147 There is a strong desire to maintain a single query mechanism 148 for data involving E.164 phone numbers and not complicate 149 call processing applications with multiple protocol 150 mechanisms. Were the query for CNAM data to require a 151 secondary protocol mechanism such as LDAP or IRIS to retrieve 152 the data, it could significantly impact call setup times. 154 3. 155 Definition of PSTN CNAM Data 157 Calling Name data is a string of up to 15 ASCII [9] 158 characters of information associated with a specific calling 159 party number [10] [11][12][13][14]. In the Public Switched 160 Telephone Network (PSTN) this data is sent by the originating 161 network only at the specific request of the terminating 162 network via a SS7 Transaction Capabilities Application Part 163 (TCAP) response message. 165 4. 166 The PSTNDATA URI 168 This document proposes a new URI scheme 'PSTNDATA:' 169 specifically to carry PSTN data in general and CNAM data 170 specifically. 172 pstndatauri = "pstndata:" datatype ["/" telephone- 173 subscriber ] ";" content 174 datatype = "cnam" 175 ; Other datatypes can be defined by adding 176 ; alternative values. 177 content = [ mediatype ] [ ":base64" ] "," data 178 mediatype = [ type "/" subtype ] *( ";" parameter ) 179 data = *urlchar 180 parameter = attribute "=" value 182 ANSI standards specify the use of ASCII [9] in the response 183 to TCAP queries for Calling Name data. This specification 184 does not preclude the use of internationalized characters 185 within the pstn URI, nor does it preclude the use of more 186 than 15 characters. 188 5. 189 Enumservice Privacy Responses and Parameters 191 The PSTN defines several values for CNAM data in the event 192 that there are privacy restrictions on the access to that 193 data or that the data is unavailable. These are defined as 194 "Reason for Absence of Name" in GR-1188 [13], consequently 195 the following responses to a query are reserved. 197 Within the datatype 'cnam' two special content cases with 198 mediatype parameters and data are defined: 200 Calling Name Privacy Indicator: 'unavailable=p,' 202 This parameter defined as the Calling Name data information 203 may be available but the Calling Party does not wish to have 204 their Calling Name data displayed by Called Party User 205 Agents. 207 In this case, the data element is populated with 208 rather than the Calling Name itself, such as "Private". 210 Usage: pstndata:cnam;;unavailable=p, 212 Calling Name Status Indicator 214 Definition: 'unavailable=u,' 215 This parameter is defined as there is no Calling Name data 216 for that E.164 number available. 218 In this case, the data element is populated with 219 rather than the Calling Name itself, such as "Unavailable" or 220 "Out of Area". 222 Usage: pstndata:cnam;;unavailable=u, 224 6. 225 Distribution of CNAM Data 227 The distribution of CNAM data is often highly restricted. The 228 NAPTR records described herein should not be part of the 229 e164.arpa DNS tree. Distribution of this NAPTR data would be 230 either within a service providers internal network, or on a 231 private basis between one or more parties using a variety of 232 security mechanisms to prohibit general public access. 234 If such data was distributed in an open DNS system, a 235 national regulatory body may have jurisdiction, especially 236 since CNAM information may contain Personally Identifying 237 Information. Such a body may choose to restrict distribution 238 of the data in such a way that it may not pass over that 239 country's national borders. How Personally Identifying 240 Information is collected, distributed and subsequently 241 regulated is out of the scope of this document 243 7. 244 Enumservice CNAM Response Examples 246 This section documents several examples of how this protocol 247 is used for illustrative purposes only. 249 $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. 250 NAPTR 10 100 "u" "E2U+pstndata:cnam" 251 "!^.*$!pstndata:cnam/+15052121111;;charset=us- 252 ascii,Francois%20Audet!". 254 ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. 255 NAPTR 10 100 "u" "E2U+pstndata:cnam" 256 "!^.*$!pstndata:cnam/+15052121111;;charset=us- 257 ascii,foo=bar,Francois%20Audet!". 259 $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net. 260 NAPTR 10 100 "u" "E2U+pstndata:cnam" 261 "!^.*$!pstndata:cnam/+15052121111;;unavailable=u,Out%20of%20A 262 rea!". 264 $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net. 265 NAPTR 10 100 "u" "E2U+pstndata:cnam" 266 "!^.*$!pstndata:cnam;;unavailable=p,Private!". 268 $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. 269 NAPTR 10 100 "u" "E2U+pstndata:cnam" 271 "!^.*$!pstndata:cnam/+15052121111;image/gif:base64,R0lGODlhDw 272 APAJEBAAAAAL+/v///AAAAACH5BAEAAAEALAAAAAAPAA8AAAIujA2Zx5EC 273 4WIgWnnqvQBJLTyhE4khaG5Wqn4tp4ErFnMY+Sll9naUfGpkFL5DAQA7!". 275 8. 276 Usage Considerations 278 Typically, the Calling Name data in the PSTN is delivered to 279 the called party during the first silent interval after the 280 first ring of the phone. (see GR-1188 requirement R3-341 281 [13]). If the Called party answers the call before this, 282 Calling Name data may not be delivered. 284 This protocol could be invoked, for example, when a user 285 agent within a service providers network receives an INVITE 286 without a display name present. 288 The exact mechanism or determination of when to issue an 289 ENUM-CNAM request, and the formatting of SIP [18] messages is 290 beyond the scope of this document. 292 9. 293 Privacy Considerations 295 It is assumed that carriers, service providers, or other 296 organizations that originate Calling Name data will not 297 publish such information in a globally visible DNS tree, 298 such as e164.arpa for reasons of personal privacy protection 299 unless such publication is consistent with national 300 regulatory policy. 302 Service providers and other organizations will probably 303 privately exchange and publish this data in their internally 304 cached ENUM databases, which is only able to be queried by 305 trusted elements of their network, such as soft switches and 306 SIP [18] proxy servers. 308 Service providers using this query response technique are 309 advised that many national jurisdictions have strict 310 regulations on the use of Calling Name data and that National 311 Regulatory Authorities may have special regulations that 312 permit subscribers to block the use of such data before call 313 setup. Other jurisdictions have services known as anonymous 314 caller rejection, meaning that calls made from a system where 315 Calling Line Identification and Calling Name data are blocked 316 are prevented from establishing a session. 318 10. 319 Security Considerations 321 Use of the CNAM Enumservice shall either be within a service 322 providers internal network, or on a private basis between one 323 or more parties using a variety of security mechanisms to 324 prevent general public access. It should be noted that this 325 content type is designed to carry potentially personal 326 information and as such, may be subject to restrictions 327 within various national jurisdictions. 329 In many cases, the actual information that needs to be 330 protected is the combination of the Name associated with the 331 Telephone Number or the association of the name with the 332 telephone call. So, it will be necessary to protect the 333 response to the query that provides the association between 334 the two elements. 336 The CNAM Enumservice defined in this document is assumed to 337 be used in an environment where elements are trusted and 338 where attackers are not supposed to have access to the 339 protocol messages between those elements. Traffic protection 340 between network elements is sometimes achieved by using IPSec 341 [15] and sometimes by physically protecting the underlying 342 network. In any case, the provider should ensure that 343 measures are taken to prevent both fraud and unauthorized 344 disclosure by using a combination of authentication and 345 Encryption. 347 11. 348 IANA Considerations 350 This document registers the 'cnam' Enumservice using the type 351 'pstn' and the subtype 'cnam' in the Enumservice registry 352 described in the IANA considerations in RFC 3761 [1]. 353 Details of this registration are provided in sections 13 and 354 14 of this document. 356 This document also registers with the IANA the URI 357 'pstndata:' per RFC 4395 [15] 359 11.1 IANA Enumservice Registration for "pstndata" with 360 subtype "cnam" 362 Enumservice Name: "cnam" 363 Enumservice Type: "pstndata" 364 Enumservice Subtype: "cnam" 365 URI Schemes: "pstndata:" 367 Functional Specification: 369 This Enumservice indicates that a resource record contains 370 Calling Name Delivery Information that can be addressed by 371 the associated 'pstndata:' URI scheme in order to facilitate 372 the display of Calling Party information from a PSTN endpoint 373 to a VoIP Client User Agent or other application. 375 Security Considerations: See Section 9. 377 Intended Usage: COMMON 379 Authors: 381 Richard Shockey and Jason Livingood, et. al. (for author 382 contact detail see Authors' Addresses section) 383 11.2 IANA Registration Template for URI "pstndata:" 385 URI scheme name. 387 The name of the URI is "pstndata:". 389 Status. 391 The intended status is Permanent. NOTE: The distribution of 392 CNAM data is often highly restricted. Usage of this URI 393 should either be within a service providers internal network, 394 or on a private basis between one or more parties using a 395 variety of security mechanisms to prevent general public 396 access. The records described herein should not be part of 397 the e164.arpa or any other portion of the DNS tree. 399 Other datatypes can be defined by adding alternative values. 400 Tokens are registered with IANA. 402 URI scheme syntax. 404 pstndatauri = "pstndata:" datatype ["/" telephone- 405 subscriber ] ";" content 406 datatype = "cnam" 407 ; Other datatypes can be defined by adding 408 ; alternative values. 409 content = [ mediatype ] [ ":base64" ] "," data 410 mediatype = [ type "/" subtype ] *( ";" parameter ) 411 data = *urlchar 412 parameter = attribute "=" value 414 where "telephone-subscriber" is imported from RFC 3966 415 [19], "urlchar" is imported from RFC 2396 [20], and 416 "attribute" and "value" are imported from RFC 2045 [21]. 418 URI scheme semantics. 420 The PSTN defines several values for CNAM data in the event 421 that there are privacy restrictions on the access to that 422 data or that the data is unavailable. These are defined as 423 "Reason for Absence of Name" in GR-1188 [13], consequently 424 the following responses to a query are reserved. 426 Within the datatype 'cnam' two special content cases with 427 mediatype parameters and data are defined: 429 Calling Name Privacy Indicator: 'unavailable=p,' 431 This parameter defined as the Calling Name data information 432 may be available but the Calling Party does not wish to have 433 their Calling Name data displayed by Called Party User 434 Agents. 436 In this case, the data element is populated with 437 rather than the Calling Name itself, such as "Private". 439 Usage: pstndata:cnam;;unavailable=p, 441 Calling Name Status Indicator 443 Definition: 'unavailable=u,' 445 This parameter is defined as there is no Calling Name data 446 for that E.164 number available. 448 In this case, the data element is populated with 449 rather than the Calling Name itself, such as "Unavailable" or 450 "Out of Area". 452 Usage: pstndata:cnam;;unavailable=u, 454 Encoding considerations. 456 The purpose of this URI is to enable service providers to 457 place Calling Name Delivery information (CNAM) into RFC 458 3761 [1] databases or to send ENUM queries to a protocol 459 converter that would have access to the Signaling System 7 460 (SS7) Network. This, in turn, could enable such parties to 461 offer Calling Name Delivery services using the technology 462 provided by RFC 3761[1]. 464 The information stored in these databases can be encoded to 465 facilitate storage and retrieval operations. The type of 466 encoding used is identified using appropriate media type 467 parameters. If not otherwise identified, character data is 468 presumed to be encoded using US-ASCII. 470 Applications and/or protocols that use this URI scheme name. 472 This URI scheme is intended for use in ENUM RFC 3761 [1] 473 databases. 475 Interoperability considerations. 477 The URI is designed to be used specifically in conjunction 478 with trusted systems that utilize the RFC 3761 [1] databases. 480 Security considerations: 482 The distribution of CNAM data is often highly restricted. 483 Distribution of this data would typically be either within a 484 service providers internal network, or on a private basis 485 between one or more parties using a variety of security 486 mechanisms to prohibit general public access. It should be 487 noted that this content type is designed to carry potentially 488 personal information and as such, may be subject to 489 restrictions within various national jurisdictions. In 490 many cases, the actual information that needs to be protected 491 is the combination of the Name associated with the Telephone 492 Number or the association of the name with the telephone 493 call. So, it will be necessary to protect the response to 494 the query that provides the association between the two 495 elements. 497 The pstn URI defined in this document is assumed to be used 498 in an environment where elements are trusted and where 499 attackers are not supposed to have access to the protocol 500 messages between those elements. Traffic protection between 501 network elements is sometimes achieved by using IPSec [15] 502 and sometimes by physically protecting the underlying 503 network. In any case, the provider should ensure that 504 measures are taken to prevent both fraud and unauthorized 505 disclosure by using a combination of authentication and 506 Encryption. 508 11.3 Datatype Token Registry 510 IANA is requested to create a registry for datatype tokens 511 described in section 11.2. Values shall be registered using 512 the Standards Action policy described in BCP 26 [22]. 514 Specifications presented to the IESG for standards action 515 MUST include both the requested token and a syntax 516 specification for the token. 518 Registry Name: "pstndata: URI datatype Token Registry" 520 Registration Template: 522 Datatype name: 524 Datatype specification: 526 11.4 IANA Registration Template for datatype Token "cnam" 528 Datatype name: cnam 530 Datatype specification: Section 11.2 of this document. 532 Contacts. 534 Richard Shockey 535 NeuStar 536 46000 Center Oak Plaza 537 Sterling, VA 20166 538 USA 540 Phone: +1-571-434-5651 541 Email: richard.shockey@neustar.biz 543 Jason Livingood 544 Comcast Cable Communications 545 1500 Market Street 546 Philadelphia, PA 19102 547 USA 548 Phone: +1-215-981-7813 549 Email: jason_livingood@cable.comcast.com 551 Author/Change controller. 553 This specification is a work item of the IETF ENUM working 554 group, with the mailing list address enum@ietf.org 556 References. 558 [ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 559 Resource Identifiers (URI) Dynamic Delegation Discovery 560 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 562 12. 563 Normative References 565 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 566 Resource Identifiers (URI) Dynamic Delegation Discovery 567 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 569 [2] ITU-T, "The International Public Telecommunication 570 Number Plan", Recommendation E.164, May 1997. 572 [3] Mockapetris, P., "Domain Names - Concepts and 573 Facilities", RFC 1034, November 1987. 575 [4] Mealling, M., "Dynamic Delegation Discovery System 576 (DDDS) Part Three: The Domain Name System (DNS) Database", 577 RFC 3403, October2002. 579 [5] Mealling, M., "Dynamic Delegation Discovery System 580 (DDDS) Part One: The Comprehensive DDDS", RFC 3401, 581 October 2002. 583 [6] Mealling, M., "Dynamic Delegation Discovery System 584 (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. 586 [7] Mealling, M., "Dynamic Delegation Discovery System 587 (DDDS) Part Four: The Uniform Resource Identifiers (URI)", 588 RFC 3404, October 2002. 590 [8] Mealling, M., "Dynamic Delegation Discovery System 591 (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 592 3405, October 2002. 594 [15] Hansen, T, et al., "The "Guidelines and Registration 595 Procedures for New URI Schemes", RFC 4395, February 2006 597 [16] Bradner, S., "Key words for use in RFC's to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [17] Livingood, J. and Shockey, R. "IANA Registration for 601 an 602 Enumservice Containing Public Switched Telephone Network 603 (PSTN) Signaling Information", RFC 4769, November 2006 605 [18] Rosenberg, J., et al., "SIP: Session Initiation 606 Protocol", RFC 3261, June 2002. 608 [19] Schulzrinne, H., "The tel URI for Telephone Numbers", 609 RFC 3966, December 2004. 611 [20] Berners-Lee, T., et al., "Uniform Resource 612 Identifiers (URI): Generic Syntax", RFC 3986, January 613 2005. 615 [21] Freed, N. and Borenstein, N.S. "Multipurpose Internet 616 Mail Extensions (MIME) Part One: Format of Internet 617 Message Bodies", RFC 2045, November 1996. 619 [22] Narten, T. and Alvestrand, H. "Guidelines for Writing 620 an IANA Considerations Section in RFCs", BCP 26, October 621 1998 623 13. 624 Informative References 626 [9] American National Standards Institute (ANSI), Coded 627 Character Set - 7-Bit American National Standard Code for 628 Information Interchange, ANSI X3.4, 1986. 630 [10] American National Standards Institute (ANSI), 631 Telecommunications Network-to-Customer Installation 632 Interfaces - Analog Voice grade Switched Access Lines 633 with Calling Number Delivery, Calling Name Delivery, or 634 Visual Message-Waiting Indicator Features, ANSI 635 T1.6401.03-1998 637 [11] American National Standards Institute (ANSI), 638 Telecommunications- Integrated Services Digital Network 639 (ISDN) - Calling Line Identification Presentation and 640 Restriction Supplementary Services, ANSI T1.625-1993 642 [12] American National Standards Institute ANSI), 643 Telecommunications - Calling Name Identification 644 Presentation, ANSI T1.641-1995 646 [13] Telcordia Technologies, "CLASS Feature: Calling Name 647 Delivery Generic Requirements", GR-1188-CORE, Issue 2, 648 December 2000 650 [14] Telcordia Technologies, "CLASS Feature: Calling 651 Number Delivery", GR-31-CORE, Issue 1, June 2000 653 [15] Kent, S. et al, "Security Architecture for the 654 Internet Protocol", RFC 4301, December 2005 656 14. 657 Acknowledgements 659 The authors wish to thank Larry Masinter, Paul Kyzivat, 660 Hadriel Kaplan and Don Troshynski for invaluable input to 661 this document. 663 15. 664 Author's Address 666 Richard Shockey - editor 667 NeuStar 668 46000 Center Oak Plaza 669 Sterling, VA 20166 670 USA 671 Phone: +1-571-434-5651 672 Email: richard.shockey@neustar.biz 674 Jason Livingood 675 Comcast Cable Communications 676 1500 Market Street 677 Philadelphia, PA 19102 678 USA 679 Phone: +1-215-981-7813 680 Email: jason_livingood@cable.comcast.com 682 Kevin McCandless 683 Verisign 684 7400 West 129th Street 685 Overland Park, KS 66213 686 USA 687 Phone : +1 913-814-6397 688 Email : KMcCandless@verisign.com 690 Manjul Maharishi 691 Verisign 692 21345 Ridgetop Circle 693 Dulles VA 20166 694 Phone :+1 703-948-3255 695 Email : mmaharishi@verisign.com 697 Scott Hollenbeck 698 Verisign 699 21345 Ridgetop Circle 700 Dulles VA 20166 701 Phone : +1 703-948-3257 702 Email : shollenbeck@verisign.com 704 16. 705 Full Copyright Statement 707 Copyright (C) The IETF Trust (2008). 709 This document is subject to the rights, licenses and 710 restrictions contained in BCP 78, and except as set forth 711 therein, the authors retain all their rights. 713 This document and the information contained herein are 714 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 715 ORGANIZATION HE/SHE PRESENTS OR IS SPONSORED BY (IF ANY), THE 716 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING 717 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 718 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 719 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 720 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 721 PARTICULAR PURPOSE. 723 Intellectual Property 725 The IETF takes no position regarding the validity or scope of 726 any Intellectual Property Rights or other rights that might 727 be claimed to pertain to the implementation or use of the 728 technology described in this document or the extent to which 729 any license under such rights might or might not be 730 available; nor does it represent that it has made any 731 independent effort to identify any such rights. Information 732 on the procedures with respect to rights in RFC documents can 733 be found in BCP 78 and BCP 79. 735 Copies of IPR disclosures made to the IETF Secretariat and 736 any assurances of licenses to be made available, or the 737 result of an attempt made to obtain a general license or 738 permission for the use of such proprietary rights by 739 implementers or users of this specification can be obtained 740 from the IETF on-line IPR repository at 741 http://www.ietf.org/ipr. 743 The IETF invites any interested party to bring to its 744 attention any copyrights, patents or patent applications, or 745 other proprietary rights that may cover technology that may 746 be required to implement this standard. Please address the 747 information to the IETF at ietf-ipr@ietf.org. 749 Acknowledgment 751 Funding for the RFC Editor function is provided by the IETF 752 Administrative Support Activity (IASA).