ENUM Working Group                             R. Shockey - editor
Internet-Draft                                             NeuStar
Expires: 10 December 2006                             J. Livingood
                                      Comcast Cable Communications
                                                     K. McCandless
                                                      M. Maharishi
                                                          Verisign
                                                       August 2006


                IANA Registration for an Enumservice
   Calling Name Delivery (CNAM) Information and IANA Registration for
                   Media type 'application/cnam'
                      draft-ietf-enum-cnam-04


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 January 2007.

Copyright Notice

  Copyright (C) The Internet Society (2006).


Abstract

  This document registers the Enumservice 'pstn' and subtype 'cnam'
  using the URI scheme 'data:' as per the IANA registration process



Shockey & Livingood      Expires Dec 2006                [Page 1]


Internet-Draft           CNAM Enumservice             August 2006


  defined in the ENUM specification, RFC 3761 and registers 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 Public Switched Telephone
  Network (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. Definition of PSTN CNAM Data...........................3
  4. The CNAM data URI......................................3
  5. Distribution of CNAM Data..............................4
  6. Enumservice CNAM Response Examples.....................5
     6.1 Example Call Flow..................................5
  7. SIP Considerations.....................................6
  8. Security Considerations................................7
  9. Privacy Considerations.................................7
  10. IANA Considerations...................................8
  10.1 IANA Enumservice Registration for PSTN Data 'cnam'...8
  10.2 IANA Registration Template for Media Type 'application/cnam'
     ............................................................8
  11. References...........................................10
  11.1 Normative References................................10
  11.2 Informative References..............................11
  Author's Address.........................................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 [17].


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
  the Domain Name System (DNS), RFC 1034 [3] and Naming Authority
  Pointer Records (NAPTR) records in the Dynamic Delegation Discovery
  System (DDDS) RFC 3403 [4]) to query the services that are available
  for a specific domain name.




Shockey & Livingood      Expires Dec 2006                [Page 2]


Internet-Draft           CNAM Enumservice             August 2006


  This document registers an Enumservice 'cnam' 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' per the requirements of BCP 13/RFC 4288 [18].

  The purpose of this Enumservice is to enable service providers to
  place Calling Name Delivery information (CNAM) into ENUM databases or
  to send ENUM queries to a protocol converter that would have access
  to the Signaling System 7 (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' may indicate the URI scheme.

  In this document, one type is specified, 'pstn' and one subtype
  'cnam' with the URI scheme specified, 'data:' as specified in RFC
  2397 [16].


3.   Definition of PSTN CNAM Data

  Calling Name data is a string of up to 15 ASCII [9] characters of
  information associated with a specific calling party number [10] [11]
  [12] [13] [14].  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.


4.   The CNAM data URI

  RFC 2397 [16] specifies the ABNF structure [19] and parameters for the
  data URI as follows

  dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
         mediatype  := [ type "/" subtype ] *( ";" parameter )
         data       := *urlchar
         parameter  := attribute "=" value



Shockey & Livingood      Expires Dec 2006                [Page 3]


Internet-Draft           CNAM Enumservice             August 2006


  In order to distinguish the Calling Name data media type used within
  this URL this document specifically registers with IANA the media
  type 'application/cnam'.

  All responses using this specification SHOULD specifically reference
  the media type 'application/cnam'.

  ANSI standards specify the use of ASCII [9] in the response to TCAP
  queries for Calling Name data.  This specification does not preclude
  the use of internationalized characters within the CNAM data URI, nor
  does it preclude the use of more than 15 characters.

  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" in
  GR-1188 [13], consequently the following responses to a query from a
  well known database are reserved.

  Within the media type 'application/cnam' an two optional parameters
  are supported.

  Calling Name Privacy Indicator: 'unavailable=p'

  This parameter defined as the Calling Name data information may be
  available but the Calling Party does not wish to have their Calling
  Name data displayed by Called Party User Agents.

  Usage: data:application/cnam;unavailable=p

  Calling Name Status Indicator

  Definition: 'unavailable=u'

  This parameter is defined as there is no Calling Name data for that
  E.164 number available.

  Usage: data:application/cnam;unavailable=u



5.   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



Shockey & Livingood      Expires Dec 2006                [Page 4]


Internet-Draft           CNAM Enumservice             August 2006


  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.  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 Personally Identifying Information is collected,
  distributed and subsequently regulated is out of the scope of this
  document.


6.   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.



  $ORIGIN 0.0.1.0.0.0.1.5.5.5.1.e164.carrier1.example.net.
    NAPTR 10 100 "u" "E2U+pstn:cnam"
    "!^.*$!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 after the comma is ASCII text as per RFC
  2397


  $ORIGIN 0.0.1.0.0.0.1.5.5.5.1.carrier1.example.net.
    NAPTR 10 100 "u" "E2U+pstn:cnam"
    "!^.*$!data:,Francois%20Marie20%Arouet!".


  $ORIGIN 0.0.1.0.0.0.1.5.5.5.1..carrier1.example.net.
    NAPTR 10 100 "u" "E2U+pstn:cnam"
    "!^.*$!data:application/cnam;unavailable=u,!".


6.1 Example Call Flow

  Typically, the Calling Name data in the PSTN is delivered to the
  called party during the first silent interval after the first ringing
  [13] (see requirement R3-341).  If the Called party answers the call
  before this, Calling Name data may not be delivered.


Shockey & Livingood      Expires Dec 2006                [Page 5]


Internet-Draft           CNAM Enumservice             August 2006



  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.

       a) A PSTN user, say from +USA: +1(555)100-0199 which is
       connected to a calling application, dials an E.164 telephone
       number: +1(555)100-0100.

       b) The calling application uses the dialed number to form a
       FQDN NAPTR query: 0.0.1.0.0.0.1.5.5.5.1.e164.arpa.

       c) The DNS finds an E2U+sip record and returns a sip URI for
       processing by the calling application:
        sip:+15551000100@sbc2.carrier2.example.net;user=phone.

       d) A SIP invite is sent to the Called Party proxy at
       carrier2.example.net.

       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 from the SIP INVITE From: field
       (i.e. +1-(555)100-0199), and sends this query to a well known
       database source for CNAM queries:
       9.9.1.0.0.0.1.5.5.5.1.cnamedb.networks.example.net

       f) Once the data 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 data 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.


7.   SIP Considerations




Shockey & Livingood      Expires Dec 2006                [Page 6]


Internet-Draft           CNAM Enumservice             August 2006


  When SIP proxies forward CNAM data retrieved by this mechanism to
  other SIP elements, it should be transported using P-asserted
  identity fields as defined in RFC 3325 [15]


8.   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
  underlying 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, or other organizations that originate
  Calling Name data may choose not to publish such information in a
  globally visible DNS tree for reasons of personal privacy protection.
  Service providers and other organizations may choose to privately
  exchange and publish this data in their internal cached ENUM
  databases, 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 [A] to this is provided in RFC 3761
  [1].  A thorough analysis of threats to the DNS itself is covered in
  RFC 3833 [B].


9.   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 Calling 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



Shockey & Livingood      Expires Dec 2006                [Page 7]


Internet-Draft           CNAM Enumservice             August 2006


  system where Calling Line Identification and Calling Name data are
  blocked are prevented from establishing a session.


10.    IANA Considerations

  This document registers the CNAM Enumservice using the type 'pstn'
  and the subtype 'cnam' in the Enumservice registry described in the
  IANA considerations in RFC 3761 [1].


  This document also registers with the IANA the media type
  'application/cnam' per BCP 13/RFC 4288 [18]


10.1 IANA Enumservice Registration for PSTN Data "cnam"

  Enumservice Name: "cnam"

  Enumservice Type: "pstn"

  Enumservice Subtypes: "cnam"

  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

10.2 IANA Registration Template for Media Type 'application/cnam'



Shockey & Livingood      Expires Dec 2006                [Page 8]


Internet-Draft           CNAM Enumservice             August 2006


     To: ietf-types@iana.org

     Subject: Registration of media type application/cnam

     Type name: application

     Subtype name: cnam

     Required parameters: none

     Optional parameters:

  Two optional parameters are defined.

  a) Calling Name Privacy Indicator: 'unavailable=p'

  This parameter defined as the Calling Name information may be
  available but the Calling Party does not wish to have their Calling
  Name data displayed by Called Party User Agents.

  Intended usage:  'unavailable=p'

  b) Calling Name Status Indicator: 'unavailable=u'

  This parameter is defined as there is no Calling Name data for that
  E.164 number available.

  Intended usage:  'unavailable=u'

     Encoding considerations: ASCII

     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 or Jason Livingood


Shockey & Livingood      Expires Dec 2006                [Page 9]


Internet-Draft           CNAM Enumservice             August 2006


  [richard.shockey@neustar.biz or jason.livingood@cable.comcast.com]

     Intended usage: Common

     Restrictions on usage: This content type is designed to carry
  potentially personal information and as such, 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@ietf.org

    Other Information: none

    Security Considerations: none


11.   References

11.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 2005.

  [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.




Shockey & Livingood      Expires Dec 2006               [Page 10]


Internet-Draft           CNAM Enumservice             August 2006


  [9] American National Standards Institute (ANSI), Coded
  Character Set - 7-Bit American National Standard Code for Information
  Interchange, ANSI X3.4, 1986.

  [10] 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

  [11] American National Standards Institute (ANSI), Telecommunications
  - Integrated Services Digital Network (ISDN) _ Calling Line
  identification Presentation and Restriction Supplementary Services,
  ANSI T1.625-1993

  [12] American National Standards Institute (ANSI),Telecommunications
  - Calling Name Identification Presentation, ANSI T1.641-1995

  [13] Telcordia Technologies, "CLASS Feature: Calling Name Delivery
  Generic Requirements", GR-1188-CORE, Issue 2,December 2000

  [14] Telcordia Technologies, "CLASS Feature: Calling Number
  Delivery", GR-31-CORE, Issue 1, June 2000

  [15] Jennings, C., et.al "Private Extensions to the Session
  Initiation Protocol (SIP) for Asserted Identity within Trusted
  Networks", RFC 3325, November 2002

  [16] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998

  [17] Bradner, S., "Key words for use in RFC's to Indicate Requirement
  Levels", BCP 14, RFC 2119, March 1997.

  [18] Freed, N, et.al. "Media Type Specifications and Registration
  Procedures", BCP 13 RFC 4288, December 2005.

  [19] Crocker, D, "Augmented BNF for Syntax Specifications: ABNF",
  RFC 2234, November 1997.


11.2 Informative References

  [A] Arends, R. and et al., "Protocol Modifications for the DNS
  Security Extensions", RFC 4035, March 2005.

  [B] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name
  System (DNS)", RFC 3833, August 2004.



Shockey & Livingood      Expires Dec 2006               [Page 11]


Internet-Draft           CNAM Enumservice             August 2006




Author's Address

  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

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to


Shockey & Livingood      Expires Dec 2006               [Page 12]


Internet-Draft           CNAM Enumservice             August 2006


  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 Dec 2006               [Page 13]