Internet DRAFT - draft-walter-ranalli-enum-service

draft-walter-ranalli-enum-service










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
               <draft-walter-ranalli-enum-service-01.txt>


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]