Telephone Number Mapping R. Walter Internet Draft D. Ranalli Document: draft-walter-ranalli-enum-service-01.txt NetNumber, Inc. Category: Standards Track November, 2001 ENUM Resolution Protocols and Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes a set of ENUM resolution protocols and services that enable communication applications to interoperate with and unambiguously differentiate between multiple communications services associated with an E.164 telephone number. 1. Conventions used in this document 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 RFC-2119 [2]. Walter, et al. Expires May 8, 2002 [Page 1] Internet Draft ENUM Resolution Protocols and Services October 2001 2. Introduction The ENUM protocol described in RFC 2916 [3] utilizes the Domain Name System (DNS) [4] to provide for the translation of E.164 domain names into protocol and service specific uniform resource identifiers or URI's [5]. ENUM enabled applications are responsible for determining if the results of an ENUM query contain protocol and service specific URI's that are relevant to the applications purpose. This is achieved by examining the resolution protocol and service(s) contained in the service field of the returned NAPTR resource records [6]. ENUM resolution protocols are used to determine application service interoperability, where as, resolution services specify application service functionality. RFC 2916 defines no resolution protocols and a single resolution service named "E.164 to URI" (E2U). The E2U resolution service indicates to an application that the result of processing the a NAPTR record is one or more URIs, but does not indicate the specific service associated with the URI(s). The application may infer the nature of the service by examining the resolution protocol, however this is ambiguous when there is more than one NAPTR RR containing the same resolution protocol. A simple example of this is when both a SIP based voice service and a SIP based instant messaging service exist for the same telephone number. The example below highlights the ambiguity created by multiple NAPTR RRs with common resolution protocols. An application cannot discern the SIP-based "voice" service from the SIP-based "instant messaging" service. Similarly, an application cannot discern the SMTP-based "email" service from the SMTP-based "voicemail" service. 4.3.2.1.6.7.9.8.6.4 IN NAPTR 0 0 "u" "sip+E2U" "!^.*$!sip:4689761234@tele.fr!" . IN NAPTR 0 0 "u" "sip+E2U" "!^.*$!sip:pierre33@msn.com!" . IN NAPTR 0 0 "u" "smtp+E2U" "!^.*$!mailto:4689761234@tele.fr!" . IN NAPTR 0 0 "u" "smtp+E2U" "!^.*$!mailto:pierre33@hotmail.com!". Well defined, standardized resolution protocols and services are needed to enable communication applications to interoperate with and unambiguously differentiate between multiple application services that are supported for a telephone number. There are many potential resolution protocols and services that may be associated with an E.164 telephone number. In order to facilitate the deployment of communications applications that interoperate across multiple service provider and technology vendor environments, care must be taken to only specify resolution protocols and services for which there is wide acceptance. This document specifies an initial set of resolution protocols and services for ENUM and provides an IANA framework for advancing the list of protocols and services over time. Walter, et al. Expires May 8, 2002 [Page 2] Internet Draft ENUM Resolution Protocols and Services October 2001 3. Resolution Protocols ENUM resolution protocols specify the communication protocol associated with an application service. The querying application uses the resolution protocol to determine if it can communicate (i.e. interoperate) with the associated application service. Resolution protocols SHOULD be specified in context with the application's communication protocol, which may be different than the underlying network transport protocol. For example, many communication protocols are commonly tunneled through HTTP). In this situation, specifying the resolution protocol as HTTP would lead to ambiguity and is not recommended. Each resolution protocol MUST contain a name, mnemonic and an IANA assigned number. 3.1 Specification of Resolution Protocol - SIP This resolution protocol identifies that the resulting service may be communicated with using Session Initiation Protocol (SIP) [7]. * Name: SIP - Session Initiation Protocol * Mnemonic: SIP * IANA Assigned Number: 1 3.2 Specification of Resolution Protocol - H323 This resolution protocol identifies that the resulting service may be communicated with using H.323 protocols (H323) [8]. * Name: H.323 - IP Telephony Protocol(s) * Mnemonic: H323 * IANA Assigned Number: 2 3.3 Specification of Resolution Protocol - SMTP This resolution protocol identifies that the resulting service may be communicated with using Simple Mail Transfer Protocol (SMTP) [9]. * Name: SMTP - Simple Mail Transfer Protocol * Mnemonic: SMTP * IANA Assigned Number: 3 Walter, et al. Expires May 8, 2002 [Page 3] Internet Draft ENUM Resolution Protocols and Services October 2001 4. Resolution Services ENUM resolution services specify the functionality that the associated application service supports. Resolution services SHOULD be carefully specified to avoid introducing ambiguity and MUST: - Be distinctly different in nature so that an application can unambiguously determine the desired functionality. - Be combinable to represent more sophisticated functionality. For example, real-time voice and voice messaging represent distinct communications services. When combined they represent a more sophisticated telephony service. - contain a name, mnemonic and an IANA assigned number. 4.1 Specification of Service - E2VOICE This resolution service identifies that a voice service is associated with the E.164 number. * Name: E.164 to Voice Service URI * Mnemonic: E2VOICE * IANA Assigned Number: 1 4.2 Specification of Service - E2EM This resolution service identifies that an electronic mail service is associated with the E.164 number. * Name: E.164 to Electronic Mail URI * Mnemonic: E2EM * IANA Assigned Number: 2 4.3 Specification of Service - E2VM This resolution service identifies that a voice messaging service is associated with the E.164 number. * Name: E.164 to Voice Messaging URI * Mnemonic: E2VM * IANA Assigned Number: 3 4.4 Specification of Service - E2IM This resolution service identifies that an instant messaging service is associated with the E.164 number. * Name: E.164 to Instant Messaging URI * Mnemonic: E2IM * IANA Assigned Number: 4 Walter, et al. Expires May 8, 2002 [Page 4] Internet Draft ENUM Resolution Protocols and Services October 2001 5. Examples The following examples illustrate how specific resolution protocols and services MAY be utilized to unambiguously differentiate between multiple application services that have common resolution protocols. 5.1 SIP-based Voice and Instant Messaging Services 4.3.2.1.6.7.9.8.6.4 IN NAPTR 0 0 "u" "sip+E2VOICE" "!^.*$!sip:4689761234@tele.fr!" . IN NAPTR 0 0 "u" "sip+E2IM" "!^.*$!sip:pierre33@msn.com!" . 5.2 SMTP-based E-Mail and Voice Messaging Services 2.1.2.1.5.5.5.9.7.2.1 IN NAPTR 0 0 "u" "smtp+E2EM" "!^.*$!mailto:henry@mail.us!" . IN NAPTR 0 0 "u" "smtp+E2VM" "!^.*$!mailto:hsmith@company.com!" . 5.3 SIP-based Voice and Instant Messaging Services Sharing a URI The following example illustrates two communications services associated with one E.164 telephone number, protocol and URI. 4.3.2.1.6.7.9.8.6.4 IN NAPTR 0 0 "u" "sip+E2VOICE+E2IM" "!^.*$!sip:pierre33@msn.com!" . Note: The service field of the NAPTR is limited to 32 bytes. This should be sufficient as long as the single URI is associated with relatively few services. A less compact implementation of this example would be: 4.3.2.1.6.7.9.8.6.4 IN NAPTR 0 0 "u" "sip+E2VOICE" "!^.*$!sip:pierre33@msn.com!" . IN NAPTR 0 0 "u" "sip+E2IM" "!^.*$!sip:pierre33@msn.com!" . 6. IANA Considerations As per RFC 2434 [10]: "Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned. To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs Guidelines describing the conditions under which new values can be Assigned." Outlined below are the guidelines for the assignment of ENUM resolution protocol and service values: Walter, et al. Expires May 8, 2002 [Page 5] Internet Draft ENUM Resolution Protocols and Services October 2001 (1) The official values for ENUM resolution protocols and services MUST be assigned in accordance with the "IETF Consensus" policy defined in "Guidelines for IANA Considerations" [10]. Under the consensus policy, new assignments are made via RFC's approved by the IESG with input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). (2) Resolution protocols and services MUST have separate IANA registry name spaces where numbers are sequentially assigned starting from the number 1. 7. Security Considerations The use of resolution protocols and services does not introduce any new security considerations. 8. References [1] S. Bradner, "The Internet Standards Process -- Revision 3, BCP9," RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] P. Faltstrom, "E.164 number and DNS," RFC 2916, September 2000. [4] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [5] Berners-Lee, T., Fielding, R.T., Masinter, L. "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [7] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [8] ITU, "Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996. [9] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [10] Narten, T., Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. Walter, et al. Expires May 8, 2002 [Page 6] Internet Draft ENUM Resolution Protocols and Services October 2001 9. Acknowledgments Thanks to Michael Mealling for his feedback on the intended use of resolution protocols and services. 10. Authors' Addresses Robert H. Walter NetNumber, Inc. 650 Suffolk Street, Suite 307 Lowell, MA 01854 Phone: +1-978-848-2831 Email: rwalter@netnumber.com Douglas J. Ranalli NetNumber, Inc. 650 Suffolk Street, Suite 307 Lowell, MA 01854 Phone: +1-978-848-2830 Email: dranalli@netnumber.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Walter, et al. Expires May 8, 2002 [Page 7]