ENUM Working Group J. Livingood Internet-Draft Comcast Cable Communications Expires: March 14, 2008 T. Zhou Comcast Cable Communications R. Ferrise Comcast Cable Communications C. Harvey Comcast Cable Communications D. Troshynski Acme Packet H. Kaplan Acme Packet September 2007 IANA Registration for an Enumservice for Video Messaging draft-livingood-enum-videomsg-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 on March 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Livingood et. al. Expires March 14, 2008 [Page 1] Internet-Draft videomsg Enumservice September 2007 This document registers the Enumservice type "videomsg" with the subtype "sip" using the URI scheme 'sip', the subtype "tel" using the URI scheme 'tel', the subtype "http" using the URI scheme 'http', and the subtype "https" using the URI scheme 'https' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the real-time routing of video communications to a video messaging system. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................2 3. Distribution of Data...........................................4 4. ENUM Service Registration for videomsg.........................4 4.1 ENUM Service Registration for "videomsg" with Subtype "sip"4 4.2 ENUM Service Registration for "videomsg" with Subtype "tel"5 4.3 ENUM Service Registration for "videomsg" with Subtype "http"6 4.4 ENUM Service Registration for "videomsg" with Subtype "https" ...............................................................6 5. Examples.......................................................7 5.1 Example of a calling party sent to a video messaging system, Using a 'sip' URI Scheme.......................................7 5.2 Example of a calling party sent to a video messaging system, Using a 'tel' URI Scheme.......................................8 5.3 Example Using a Regular Expression.........................8 5.4 Example of a calling party sent to a video messaging system, Using a 'sip' URI Scheme where the URI does not contain a telephone number...............................................8 6. Implementation Recommendations.................................9 6.1 Call Processing When Multiple Records Are Returned.........9 6.2 NAPTR Configuration issues.................................9 7. Security Considerations........................................9 8. IANA Considerations...........................................10 9. Acknowledgements..............................................10 10. References...................................................10 10.1 Normative References.....................................10 10.2 Informative References...................................11 Authors' Addresses...............................................12 Intellectual Property and Copyright Statements...................13 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 Livingood et. al. Expires March 14, 2008 [Page 2] Internet-Draft videomsg Enumservice September 2007 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that transforms E.164 numbers (The International Public Telecommunication Numbering 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 look up what services are available for a specific domain name. This document registers Enumservices according to the guidelines given in RFC 3761 [1] to be used for provisioning in the services field of a NAPTR [4] resource record to indicate the types 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. Video messaging systems, sometimes called visual voice messaging systems, are beginning to be used with real-time communication services. The need for a video messaging service type has become clear in order to provide certain applications with direct access to various video messaging services, most typically via the use of SIP. Thus, a need has been identified for this video messaging service type that would enable, for example some of the following use cases: * A called party is busy or does not answer a call. A client or server then determines that a video messaging service should be used and sends the calling party’s session to such a service. The client or server needs to be able to determine which server to direct this real-time session to, whether that is within or outside of the called party’s domain. * Similar to the above use case, a real-time session is attempted to a video messaging system, but that system is currently unavailable. Since multiple video messaging service type records may be returned by the original ENUM query, the client or server could then attempt to initiate a session with one or more backup video messaging servers in a manner which is transparent to the calling party, and which supports better overall availability of a video messaging service. * Similar to the above use case, this video message service type could be used to balance load across multiple video messaging servers, whether those are in the same or in different physical locations. * A user with an account on a video messaging service needs to connect to a video messaging service in order to retrieve video messages. They initiate a real-time session and an ENUM query is Livingood et. al. Expires March 14, 2008 [Page 3] Internet-Draft videomsg Enumservice September 2007 performed to discover the video messaging server that holds their mailbox. The authors considered whether this service type could simply use the SIP Enumservice type [16], but found that it does not satisfy their video messaging requirements. For example, a request for access to such a service could be extended to the requesting SIP client, or User Agent Client (UAC), rather than relying upon the local policy of a SIP server, or User Agent Server (UAS), which means that special routing logic within a UAS cannot be relied upon to solve this problem. More importantly, however, the authors have found that without this service type, a UAC or UAS will be presented with multiple SIP URIs, with no ability other than in non-standards-based routing rules or application logic to recognize which one is related to a video messaging service. This is due in part to the fact that the IANA registration for the SIP Enumservice does not register any subtypes. 3. Distribution of Data The authors believe that it is more likely that these records will be distributed on a purely private basis, but they may also be distributed in public ENUM trees. Distribution of this NAPTR data could 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. 4. ENUM Service Registration for videomsg 4.1 ENUM Service Registration for "videomsg" with Subtype "sip" Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtypes: "sip" URI Schemes: 'sip:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. Security Considerations: See Section 9. Livingood et. al. Expires March 14, 2008 [Page 4] Internet-Draft videomsg Enumservice September 2007 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood@cable.comcast.com) Tong Zhou (tong_zhou@cable.comcast.com) Richard Ferrise (rich_ferrise@cable.comcast.com) Chris Harvey (chris_harvey@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Hadriel Kaplan (hkaplan@acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 5. 4.2 ENUM Service Registration for "videomsg" with Subtype "tel" Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtype: "tel" URI Schemes: 'tel:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. Security Considerations: See Section 9. Intended Usage: COMMON Authors: Jason Livingood (jason_livingood@cable.comcast.com) Tong Zhou (tong_zhou@cable.comcast.com) Richard Ferrise (rich_ferrise@cable.comcast.com) Chris Harvey (chris_harvey@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Hadriel Kaplan (hkaplan@acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 5. Livingood et. al. Expires March 14, 2008 [Page 5] Internet-Draft videomsg Enumservice September 2007 4.3 ENUM Service Registration for "videomsg" with Subtype "http" Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtype: "http" URI Schemes: 'http:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 9. Intended Usage: COMMON Authors: Jason Livingood (jason_livingood@cable.comcast.com) Tong Zhou (tong_zhou@cable.comcast.com) Richard Ferrise (rich_ferrise@cable.comcast.com) Chris Harvey (chris_harvey@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Hadriel Kaplan (hkaplan@acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 5. 4.4 ENUM Service Registration for "videomsg" with Subtype "https" Enumservice Name: "videomsg" Enumservice Type: "videomsg" Livingood et. al. Expires March 14, 2008 [Page 6] Internet-Draft videomsg Enumservice September 2007 Enumservice Subtype: "https" URI Schemes: 'https:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 9. Intended Usage: COMMON Authors: Jason Livingood (jason_livingood@cable.comcast.com) Tong Zhou (tong_zhou@cable.comcast.com) Richard Ferrise (rich_ferrise@cable.comcast.com) Chris Harvey (chris_harvey@cable.comcast.com) Don Troshynski (dtroshynski@acmepacket.com) Hadriel Kaplan (hkaplan@acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 5. 5. Examples The following sub-sections document several examples for illustrative purposes. These examples shall in no way limit the various forms that this Enumservice may take. 5.1 Example of a calling party sent to a video messaging system, Using a 'sip' URI Scheme $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+videomsg:sip" "!^.*$!sip:12155550123@gw.example.com!". Livingood et. al. Expires March 14, 2008 [Page 7] Internet-Draft videomsg Enumservice September 2007 In this example, a calling party has attempted a session which has gone unanswered after a certain period of time. The calling party’s session is sent to the appropriate video messaging server, a personalized greeting is played to the calling party, after which they record a video message to the called party. 5.2 Example of a calling party sent to a video messaging system, Using a 'tel' URI Scheme $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+videomsg:tel" "!^.*$!tel:1-215-555-0123!". In this example, a calling party has attempted a session which has gone unanswered after a certain period of time. The calling party’s session is sent to the appropriate video messaging server, a personalized greeting is played to the calling party, after which they record a video message to the called party. 5.3 Example Using a Regular Expression $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+videomsg:sip" "!(^.*)$!sip:\1!". In this example, a regular expression replacement function is used to reduce the size of the NAPTR record. The sip URI uses "\1" which would dynamically replace the expression with the TN, in this case +12155550123. 5.4 Example of a calling party sent to a video messaging system, Using a 'sip' URI Scheme where the URI does not contain a telephone number $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. NAPTR 10 100 "u" "E2U+videomsg:sip" "!^.*$!sip:johndoe@gw.example.com!". In this example, a calling party has attempted a session which has gone unanswered after a certain period of time. The calling party’s session is sent to the appropriate video messaging server, a personalized greeting is played to the calling party, after which they record a video message to the called party. The URI that this session is directed to does not include a telephone number, as this user has multiple services that are not particularly tied to telephone numbers whereby text, audio, video and other multimedia messages can be received and accessed. Livingood et. al. Expires March 14, 2008 [Page 8] Internet-Draft videomsg Enumservice September 2007 6. Implementation Recommendations 6.1 Call Processing When Multiple Records Are Returned It is likely that that both E2U+sip and E2U+videomsg Enumservice type records will be returned for a given query. In this case, this could result in what is essentially E2U+sip records for real-time communications with an end user, while the E2U+videomsg records will be used for real-time communications with a video messaging service, when the called party is not available or does not wish to be disturbed. Therefore, the network element that receives the results of this ENUM query will need to know enough information in order to select the videomsg service type, rather than the sip service type. In addition, it is likely that multiple E2U+videomsg Enumservice type records will be returned for a given query. In this case, multiple records may include order and preference to allow recursion or load balancing. Order could be used to designate a primary and a backup video messaging service. Preference could be used to load balance across multiple video messaging servers by weight. Finally, as with multiple records resulting from a typical ENUM query of the e164.arpa tree, it is up to the application using an ENUM resolver to determine which record(s) to use and which record(s) to ignore. Implementers should take this into consideration and build logic into their applications that can select appropriately from multiple records based on business, network, or other rules. 6.2 NAPTR Configuration issues Implementers may wish to consider using regular expressions in order to reduce the size of individual NAPTRs. This will have a significant effect on the overall size of the database involved. 7. Security Considerations DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining videomsg Enumservice data, this information would be 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 by whom it has been accessed. Such data harvesting by third parties is often used to generate lists of targets for unsolicited information. Thus, a third party could use this to generate a list that they can use to make unsolicited "telemarketing" phone calls, or so-called SPAM over Internet Livingood et. al. Expires March 14, 2008 [Page 9] Internet-Draft videomsg Enumservice September 2007 Telephony (SPIT). Many countries have do-not-call registries or other legal or regulatory mechanisms in place to deal with such abuses. As noted earlier carriers, service providers, and other users may simply choose not to publish such information in the public e164.arpa tree, but may instead simply publish this in their internal ENUM routing database that is only able to be queried by trusted elements of their network and/or partner networks, such as softswitches and SIP proxy servers. They may also choose to publish such information in a carrier-only branch of the e164.arpa tree, should one be created. Although an E.164 telephone number does not appear to reveal as much identity information about a user as a name in the format sip:username@hostname or email:username@hostname, the information is still publicly available, thus there is still the risk of unwanted communication. 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]. 8. IANA Considerations This document registers the 'videomsg' Enumservice type and the subtype "tel" and "sip" under the Enumservice registry described in the IANA considerations in RFC 3761. Details of this registration are provided in Section 4 of this document. 9. Acknowledgements TBD 10. References 10.1 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. Livingood et. al. Expires March 14, 2008 [Page 10] Internet-Draft videomsg Enumservice September 2007 [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. [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 10.2 Informative References [13] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005. [14] Bradner, et al., "IANA Registration for Enumservices email, fax, mms, ems and sms", RFC 4355, January 2006. [15] Arends, R. and et al., "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [16] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [17] Foster, M., McGarry, T., and Yu, J., "Number Portability in the GSTN: An Overview", RFC 3482, February 2003. [18] Peterson, J., "enumservice Registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. Livingood et. al. Expires March 14, 2008 [Page 11] Internet-Draft videomsg Enumservice September 2007 [19] Bradner, et al., "IANA Registration for Enumservice 'web' and 'ft', RFC 4022, February 2005. Authors' Addresses Jason Livingood Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-981-7813 Email: jason_livingood@cable.comcast.com Tong Zhou Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-286-7301 Email: tong_zhou@cable.comcast.com Richard Ferrise Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-320-8880 Email: rich_ferrise@cable.comcast.com Chris Harvey Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-981-7813 Email: chris_harvey@cable.comcast.com Livingood et. al. Expires March 14, 2008 [Page 12] Internet-Draft videomsg Enumservice September 2007 Donald Troshynski Acme Packet Email: dtroshynski@acmepacket.com Hadriel Kaplan Acme Packet Email: hkaplan@acmepacket.com Intellectual Property and Copyright Statements Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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 Livingood et. al. Expires March 14, 2008 [Page 13] Internet-Draft videomsg Enumservice September 2007 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. Acknowledgment Funding for the RFC Editor function is currently provided by the IETF Administrative Support Activity (IASA). Livingood et. al. Expires March 14, 2008 [Page 14]