ENUM Working Group R. Shockey - editor Internet-Draft NeuStar Expires: Oct 2006 J. Livingood Comcast Cable Communications Kevin McCandless Verisign Manjul Maharishi Verisign May 2006 IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information draft-ietf-enum-cnam-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire June 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document registers the Enumservice "pstn" and the compound subtypes subtype "cnam" and "data" using the URI scheme 'data:', as Shockey & Livingood Expires Oct 2006 [Page 1] Internet-Draft CNAM Enumservice May 2006 per the IANA registration process defined in the ENUM specification, RFC 3761 and creates a new media type application/cnam.. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the PSTN that may be displayed on VoIP or other Real-time Client User Agents (CUA). Table of Contents 1. Terminology....................................................2 2. Introduction...................................................2 3. IANA Enumservice Registration:.................................3 4. Definition of CNAM Data........................................3 5. IANA Enumservice Registration for PSTN Data "cnam".............3 6. Structure of CNAM data.........................................4 7. Distribution of CNAM Data......................................5 8. Enumservice CNAM Response Examples.............................5 9. Example of E2U+pstn:cnam:data in Call Processing...............6 Dialed Number..................................................6 10. SIP considerations............................................7 11. Security Considerations.......................................7 12. Privacy Considerations........................................8 13. Internationalized Character Set Considerations................8 14. IANA Registration Template for Media Type "application/cnam"..8 15. IANA Considerations..........................................10 16. References...................................................10 Normative References..........................................10 Informative References........................................11 Authors' Addresses...............................................12 Intellectual Property and Copyright Statements...................12 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC-2119 [1]. 2. Introduction ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms E.164 numbers (The International Public Telecommunication Number Plan, ITU-T Recommendation E.164 [2]) into domain names and then uses DNS (Domain Name System, RFC 1034 [3]) delegation through NS records and NAPTR records (Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 [4]) to query the services that are available for a specific domain name. Shockey & Livingood Expires Oct 2006 [Page 2] Internet-Draft CNAM Enumservice May 2006 This document registers an Enumservice according to the guidelines given in RFC 3761 [1], to be used for provisioning a NAPTR [4] resource record to indicate a type of functionality associated with an end point and/or telephone number. The registration is defined within the DDDS (Dynamic Delegation Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761. This document also registers an IANA application specific media type 'application/cnam'. 3. IANA Enumservice Registration: The purpose of this Enumservice is to enable service providers to place Calling Name Delivery information into ENUM databases or to send ENUM queries to a protocol converter that would have access to the SS7 Network. This, in turn, could enable such parties to offer Calling Name Delivery services using the technology provided by RFC 3761. The service parameters defined in RFC 3761 dictate that a "type" and one or more "subtype" should be specified. Within this set of specifications the convention is assumed that the "type" (being the more generic term) defines the service and at least one of the "subtype" defines the URI scheme. In this document, one type is specified, "pstn" and one compound subtype cnam:data with the URI scheme specified, 'data:', as specified in RFC 2397 [9]. 4. Definition of CNAM Data Caller Display Name is a data string of up to 15 ASCII characters of information associated with a specific calling party number [13] [14] [15] [16] [17]. In the Public Switched Telephone Network (PSTN) this data is sent by the originating network only at the specific request of the terminating network via a SS7 Transaction Capabilities Application Part (TCAP) response message. 5. IANA Enumservice Registration for PSTN Data "cnam" Enumservice Name: "cnam" Enumservice Type: "pstn" Enumservice Subtypes: "cnam" Enumservice Subtypes: "data" Shockey & Livingood Expires Oct 2006 [Page 3] Internet-Draft CNAM Enumservice May 2006 URI Schemes: 'data:' Functional Specification: This Enumservice indicates that a resource record contains Calling Name Delivery Information that can be addressed by the associated 'data' URI scheme [RFC 2397] and a specific media type will be defined as application/cnam in order to facilitate the display of Calling Party information from a PSTN endpoint to a VoIP Client User Agent or other application. Security Considerations: See Section 9. Intended Usage: COMMON Authors: Richard Shockey and Jason Livingood, et. al. (for author contact detail see Authors' Addresses section) Any other information the author deems interesting: None 6. Structure of CNAM data RFC 2397 specifies the structure and parameters for the data URI as follows dataurl := "data:" [ mediatype ] [ ";base64" ] "," data mediatype := [ type "/" subtype ] *( ";" parameter ) data := *urlchar parameter := attribute "=" value In order to distinguish the particular media type used within this URL this document specifically registers with IANA the mediatype "application/cnam". All responses using this specification SHOULD specifically reference the media type "application/cnam" Enumservice Privacy Responses and Parameters The PSTN defines several values for CNAM data in the event that there are privacy restrictions on the access to that data or that the data is unavailable. These are defined as "Reason for Absence of Name" Shockey & Livingood Expires Oct 2006 [Page 4] Internet-Draft CNAM Enumservice May 2006 [R3-50] in GR-1188, consequently the following responses to a query from a well known database are reserved. Within the media type 'application/cnam' a required parameter 'unavaiable' is supported as well as two options are defined. Calling Name Privacy Indicator: 'p' This parameter is defined, as the Calling Party does not wish to have their Display Name displayed Usage: data:application/cnam;unavailable=p, Calling Name Status Indicator Definition: 'u' This parameter is defined as "not available/unavailable" defined as the well known database has no data available for that particular E.164 number Usage: data:application/cnam;unavailable=u, 7. Distribution of CNAM Data The distribution of CNAM data is often highly restricted. The NAPTR records described herein probably would not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either (a) on a private basis (within a service provider's internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access) or (b) openly available on a national basis according to national regulatory policy. The authors believe it is most likely that these records will be distributed on a purely private basis. If such data was distributed nationally, a national regulatory body may have jurisdiction, especially since CNAM information may contain Personally Identifying Information [PII]. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How PII data is collected, distributed and subsequently regulated is out of the scope of this document. 8. Enumservice CNAM Response Examples This section documents an example for illustrative purposes. These examples shall in no way limit the various forms that this Enumservice may take. Shockey & Livingood Expires Oct 2006 [Page 5] Internet-Draft CNAM Enumservice May 2006 $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.carrier1.example. NAPTR 10 100 "u" "E2U+pstn:cnam:data" "!^.*$!data:application/cnam,Francois%20Marie20%Arouet!". Should no media type be present in the data URI it is presumed that the data portion of the URI is ASCII text as per RFC 2397 $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.carrier1.example. NAPTR 10 100 "u" "E2U+pstn:cnam:data" "!^.*$!data:,Francois%20Marie20%Arouet!". Escape codes are placed between names per URI formatting in RFC 2396 $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.carrier1.example. NAPTR 10 100 "u" "E2U+pstn:cnam:data" "!^.*$!data:application/cnam;unavailable=u,!". 9. Example of E2U+pstn:cnam:data in Call Processing Typically, the Caller Display Name in the PSTN is delivered to the called party during the first long silence interval after the first ringing [16] (see requirement R3-341). If the Called party answers the call before this, Calling Name may not be delivered. . This is an example of how a switch, proxy, or other calling application may make use of this Enumservice type during the call initiation process. Dialed Number a) A PSTN user, say from +1-703-729-1234, which is connected to a calling application, dials an E.164 telephone number: +1-215- 981-7813. b) The calling application uses the dialed number to form a FQDN NAPTR query: 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. c) The DNS finds an E2U+sip record and returns a sip URI for processing by the calling application: sip:+1-215-981- 7813@carrier2.example;user=phone.SBC1.cox.net SBC2.cox.net etc d) A SIP invite is sent to the Called Party proxy at carrier2.example. e) The Called Party's SIP proxy/User Agent sees the SIP message and before alerting the Called User, performs another ENUM request using the E164 number in the SIP INVITE's From field (i.e. +1-703-729-1234), and sends this query to a well known Shockey & Livingood Expires Oct 2006 [Page 6] Internet-Draft CNAM Enumservice May 2006 database source for CNAM queries: 4.3.2.1.9.2.7.3.0.7.1.cnamedb.networks.example f) Once the tel URI containing the CNAM data is returned from the well-known database source, the Called party's proxy/User Agent alerts the Called User about the incoming call and includes the Calling Name in the SIP INVITE sent to the Called User. It then sends a "180 Ringing" message to the Calling party's proxy, signaling the desire to establish the session. At that point the Called Party's Client User Agent could display the CNAM data. g) Once the Called User decides to accept the call, the RTP stream commences and the session begins. NOTE: The above example describes in general the approach that would be required by a terminating SIP UA/Proxy to acquire and send CNAM information to the Called Party. The exact mechanism, determination of when to issue ENUM-CNAM request, and formatting of SIP messages is beyond the scope of this document. 10. SIP considerations In those cases where SIP proxy's must carry CNAM data as P-asserted identity fields as defined in RFC 3325 11. Security Considerations DNS, as used by ENUM, is a global, distributed database. Thus, an implementation of this Enumservice that uses e164.apra or any other publicly accessible domain means that the information stored there is visible to anyone anonymously. While this is not qualitatively different from publication in a Telephone Directory, it does open or ease access to such data without any indication that such data has been accessed or who has accessed it. The CNAM ENUMservice defined in this document is assumed to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPSec and sometimes by physically protecting the network. In any case, it is presumed the environment where the CNAM request-response mechanism will be used can ensure the integrity and the confidentiality of the contents of the CNAM data. Carriers, service providers, and other users may simply choose not to publish such information in a DNS tree, but may instead simply privately exchange and publish this in their internal ENUM database, Shockey & Livingood Expires Oct 2006 [Page 7] Internet-Draft CNAM Enumservice May 2006 which is only able to be queried by trusted elements of their network, such as soft switches and SIP proxy servers. An analysis of threats specific to the dependence of ENUM on the DNS and the applicability of DNSSEC [13] to this is provided in RFC 3761 [1]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [14]. 12. Privacy Considerations This document does not take into consideration issues of privacy as it relates to Personally Identifying Information transmitted over IP networks. Service providers using this query response technique are advised that many national jurisdictions have strict regulations on the use of Caller Display Name data and that National Regulatory Authorities may have special regulations that permit subscribers to block the use of such data before call setup. Other jurisdictions have services known as anonymous caller rejection, meaning that calls made from a system where Calling Line Identification and Caller Display Name are blocked are prevented from establishing a session. 13. Internationalized Character Set Considerations ANSI standards specify the use of ASCII for in the response to TCAP queries for Caller Display Name. This specification does not preclude the use of internationalized characters within the data URI, nor does it preclude the use of more than 15 characters. As a practical matter, however, it is recommended that the data URI be no longer than 64 characters. 14. IANA Registration Template for Media Type "application/cnam" To: ietf-types@iana.org Subject: Registration of media type application/cnam Type name: application Subtype name: cnam Required parameters: unavailable Optional parameters: Two optional parameters are defined. Calling Name Privacy Indicator: 'p' Shockey & Livingood Expires Oct 2006 [Page 8] Internet-Draft CNAM Enumservice May 2006 This parameter defined as the Calling Party does not wish to have their Display Name displayed. Intended usage: 'unavailable=p' Calling Name Status Indicator: 'u' This parameter is defined as "not available/unavailable" defined as data is available for that particular E.164 number. Intended Usage : 'unavailable=u' Encoding considerations: (none) Security considerations: Interoperability considerations: Published specification: Usage of this media type is defined in RFC 3761 Applications that use this media type: This media type may be used in various forms of SIP applications that interact with PSTN databases for the purpose of displaying Calling Name Information on SIP Client/User agents or other compatible devices. Additional information: Magic number(s): None File extension(s): None Macintosh file type code(s):None Person & email address to contact for further information: Richard Shockey [ richard.shockey@neustar.biz or richard@shockey.us ] Intended usage: Common Restrictions on usage: This content type is designed to carry potentially personally identifying information and as a consequence, may be subject to restrictions within various national jurisdictions. Author/Change Controller: This specification is a work item of the IETF ENUM working group, with the mailing list address enum@ierf.org Other Information: Security Considerations: Shockey & Livingood Expires Oct 2006 [Page 9] Internet-Draft CNAM Enumservice May 2006 15. IANA Considerations This document registers the 'cnam' Enumservice using the type "pstn" and the compound subtypes "cnam" and "data" in the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in sections 3,4 and 5 of this document. This document also registers the media type "application/cnam" 16. References Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.10] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 3261, June 2002. Shockey & Livingood Expires Oct 2006 [Page 10] Internet-Draft CNAM Enumservice May 2006 [11] V. Gurbani, C. Jennings., "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI)Parameter Registry, draft-jennings-iptel-tel-reg-01.txt (work-in-progress) [12] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986. [13] American National Standards Institute (ANSI),Telecommunications _ Network-to-Customer Installation Interfaces _ Analog Voicegrade Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features, ANSI T1.6401.03-1998 [14] American National Standards Institute (ANSI), Telecommunications - Integrated Services Digital Network (ISDN) _ Calling Line identification Presentation and Restriction Supplementary Services, ANSI T1.625-1993 [15] American National Standards Institute (ANSI),Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995 [16] Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2,December 2000 [17] Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000 [18] Jennings, C., et.al "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002 [19] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998 [20] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Informative References [1] Bradner, et al., "IANA Registration for Enumservices email, fax, mms, ems and sms", draft-ietf-enum-msg-05.txt, May 2005. [2] Arends, R. and et al., "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [3] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. Shockey & Livingood Expires Oct 2006 [Page 11] Internet-Draft CNAM Enumservice May 2006 [4] Peterson, J., "enumservice Registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. Authors' Addresses Richard Shockey NeuStar 46000 Center Oak Plaza Sterling, VA 20166 USA Phone: +1-571-434-5651 Email: richard.shockey@neustar.biz Jason Livingood Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-981-7813 Email: jason.livingood@cable.comcast.com Kevin McCandless Verisign 7400 West 129th Street Overland Park, KS 66213 USA Phone : +1 913-814-6397 Email : KMcCandless@verisign.com Manjul Maharishi Verisign 21345 Ridgetop Circle Dulles VA 20166 Phone :+1 703-948-3255 Email : mmaharishi@verisign.com Intellectual Property and Copyright Statements Intellectual Property Statement Shockey & Livingood Expires Oct 2006 [Page 12] Internet-Draft CNAM Enumservice May 2006 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shockey & Livingood Expires Oct 2006 [Page 13]