ENUM Working Group R. Shockey - editor
Internet-Draft NeuStar
Expires: March 2008 September 2007
IANA Registration for an Enumservice Calling Name Delivery (CNAM)
Information and IANA Registration for URI type 'pstn'
draft-ietf-enum-cnam-06.txt
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 March 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
The Intended Status of this draft is Proposed Standard
Abstract
Shockey & Livingood Expires March 2008 [Page 1]
Internet-Draft CNAM Enumservice Sept 2007
This document registers the Enumservice 'pstn' and subtype 'cnam'
using the URI scheme 'pstn:' as per the IANA registration process
defined in the ENUM specification, RFC 3761[1] and registers a new
URI type 'pstn:' according to the URI registration procedure in RFC
4395 [15].
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). The pstn URI is created to facilitate this
transfer, however this URI may be used to transport other PSTN data
in the future.
Table of Contents
1. Terminology ............................................ 2
2. Introduction ........................................... 2
3. Protocol Design Considerations.......................... 3
4. Definition of PSTN CNAM Data ........................... 4
5. The PSTN URI ........................................... 4
5.1 Enumservice Privacy Responses and Parameters........ 4
6. Distribution of CNAM Data............................... 5
7. Enumservice CNAM Response Examples...................... 5
8. Usage Considerations.................................... 6
9. Privacy Considerations ................................. 6
10. Security Considerations ............................... 6
11. IANA Considerations ................................... 7
11.1 IANA Enumservice Registration for PSTN Data "cnam". 7
11.2 IANA Registration Template for URI "pstn:"......... 8
12. References ..................................... 10
12.1 Normative References ............................. 10
12.2 Informative References ........................... 12
13. Acknowledgements .................................... 12
14. Authors Address...................................... 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 [16].
2. Introduction
ENUM (E.164 Number Mapping), RFC 3761 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
Shockey & Livingood Expires March 2008 [Page 2]
Internet-Draft CNAM Enumservice Sept 2007
System (DDDS) RFC 3403 [4]) to query the services that are available
for a specific domain name.
This document registers an Enumservice 'cnam' according to the
guidelines given in RFC 3761, 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 URI type 'pstn' per the
requirements of RFC 4395.
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, 'pstn:'.
3. Protocol Design Considerations.
The design of this protocol was influenced by several factors:
RFC 3761 has become the defacto query-response protocol of choice for
a variety of data types associated with E.164 numbering and
addressing including data not necessarily associated with a SIP [18]
or other communications session. RFC 3761 is already being used by
service providers to query for data that has significant privacy or
security issues associated with it. RFC 4769 [17], for instance,
describes an Enumservice that associates an E.164 number with a PSTN
Local Routing Number. An Enumservice for CNAM data has similar design
requirements of being used in private and closed systems.
Communications service providers are concerned with the impact of
call setup up times on the overall user experience. There is a strong
desire to maintain a single query mechanism for data involving E.164
phone numbers and not complicate call processing applications with
multiple protocol mechanisms. Were the query for CNAM data to require
Shockey & Livingood Expires March 2008 [Page 3]
Internet-Draft CNAM Enumservice Sept 2007
a secondary protocol mechanism such as LDAP or IRIS to retrieve the
data, it could significantly impact call setup times.
4. 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.
5.
The PSTN URI
This document proposes a new URI scheme specifically to carry PSTN
data in general and CNAM data specifically.
pstnuri = "pstn:" datatype ["/" telephone-subscriber ] ";"
(content / reason)
datatype = "cnam"
; Other datatypes can be defined by adding alternative
; values.
content = [ mediatype ] [ ":base64" ] "," data
mediatype = [ type "/" subtype ] *( ";" parameter )
data = *urlchar
parameter = attribute "=" value
reason = "available=" ("p" / "u")
ANSI standards specify the use of ASCII in the response to TCAP
queries for Calling Name data. This specification does not preclude
the use of internationalized characters within the pstn URI, nor does
it preclude the use of more than 15 characters.
5.1 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 are
reserved.
Within the media type 'cnam' 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.
Shockey & Livingood Expires March 2008 [Page 4]
Internet-Draft CNAM Enumservice Sept 2007
Usage: pstn:cnam;unavailable=p
Calling Name Status Indicator
Definition: 'unavaiable=u'
This parameter is defined as there is no Calling Name data for that
E.164 number available.
Usage: pstn:cnam;unavailable=u
6. Distribution of CNAM Data
The distribution of CNAM data is often highly restricted.The NAPTR
records described herein should not be part of the e164.arpa DNS
tree. Distribution of this NAPTR data would be either within a
service providers internal network, or on a private basis between
one or more parties using a variety of security mechanisms to
prohibit general public access.
If such data was distributed in an open DNS system, 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 countrys national borders. How
Personally Identifying Information is collected, distributed and
subsequently regulated is out of the scope of this document.
7. Enumservice CNAM Response Examples
This section documents several examples of how this protocol is used
for illustrative purposes only.
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstn:cnam"
"!^.*$!pstn:cnam/+15052121111;charset=ascii,Francois%20Audet!".
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstn:cnam"
"!^.*$!pstn:cnam/+15052121111;charset=ascii,foo=bar,
Francois%20Audet!".
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstn:cnam"
"!^.*$!pstn:cnam/+15052121111;unavailable=u!".
Shockey & Livingood Expires March 2008 [Page 5]
Internet-Draft CNAM Enumservice Sept 2007
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstn:cnam"
"!^.*$!pstn:cnam/+15052121111;image/gif:base64,R0lGODlhDw
APAJEBAAAAAL+/v///AAAAACH5BAEAAAEALAAAAAAPAA8AAAIujA2Zx5EC
4WIgWnnqvQBJLTyhE4khaG5Wqn4tp4ErFnMY+Sll9naUfGpkFL5DAQA7!".
8. Usage Considerations
Typically, the Calling Name data in the PSTN is delivered to the
called party during the first silent interval after the first ring of
the phone. (see GR-1188 requirement R3-341 [13]). If the Called
party answers the call before this, Calling Name data may not be
delivered.
This protocol could be invoked, for example, when a user agent within
a service providers network receives an INVITE without a display
name present.
The exact mechanism or determination of when to issue an ENUM-CNAM
request, and the formatting of SIP [18] messages is beyond the scope
of this document.
9. Privacy Considerations
It is assumed that carriers, service providers, or other
organizations that originate Calling Name data will not publish such
information in a globally visible DNS tree, such as e164.arpa for
reasons of personal privacy protection unless such publication is
consistent with national regulatory policy.
Service providers and other organizations will probably privately
exchange and publish this data in their internally cached ENUM
databases, which is only able to be queried by trusted elements of
their network, such as soft switches and SIP [18] proxy servers.
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 system
where Calling Line Identification and Calling Name data are blocked
are prevented from establishing a session.
10. Security Considerations
Shockey & Livingood Expires March 2008 [Page 6]
Internet-Draft CNAM Enumservice Sept 2007
Use of the CNAM Enumservice shall either be within a service
provider's internal network, or on a private basis between one or
more parties using a variety of security mechanisms to prevent
general public access. It should be noted that this content type is
designed to carry potentially personal information and as such, may
be subject to restrictions within various national jurisdictions.
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 [A] 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.
11. 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. Details of this registration are
provided in sections 13 and 14 of this document.
This document also registers with the IANA the URI 'pstn:' per RFC
4395
11.1 IANA Enumservice Registration for PSTN Data "cnam"
Enumservice Name: "cnam"
Enumservice Type: "pstn"
Enumservice Subtypes: "cnam"
URI Schemes: "pstn:"
Functional Specification:
This Enumservice indicates that a resource record contains Calling
Name Delivery Information that can be addressed by the associated
'pstn:' URI scheme 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.
Shockey & Livingood Expires March 2008 [Page 7]
Internet-Draft CNAM Enumservice Sept 2007
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
11.2 IANA Registration Template for URI "pstn:"
URI scheme name.
The name of the URI is "pstn:".
Status.
The intended status is Permanent.
URI scheme syntax.
pstnuri = "pstn:" datatype ["/" telephone-subscriber ] ";"
(content / reason)
datatype = "cnam"
; Other datatypes can be defined by adding
alternative values.
content = [ mediatype ] [ ":base64" ] "," data
mediatype = [ type "/" subtype ] *( ";" parameter )
data = *urlchar
parameter = attribute "=" value
reason = "available=" ("p" / "u")
where "telephone-subscriber" is imported from RFC 3966 [19],
"urlchar" is imported from RFC 2396 [20], and "attribute" and "value"
are imported from RFC 2045 [21].
URI scheme semantics.
Two optional parameters are defined.
a) Calling Name Privacy Indicator: 'available=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.
Shockey & Livingood Expires March 2008 [Page 8]
Internet-Draft CNAM Enumservice Sept 2007
Intended usage: 'available=p'
b) Calling Name Status Indicator: 'available=u'
This parameter is defined as there is no Calling Name data for that
E.164 number available.
Intended usage: 'unavailable=u'
Encoding considerations.
The purpose of this URI is to enable service providers to place
Calling Name Delivery information (CNAM) into RFC 3761 [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 information stored in these databases can be encoded to
facilitate storage and retrieval operations. The type of encoding
used is identified using appropriate media type parameters. If not
otherwise identified, character data is presumed to be encoded using
US-ASCII [9].
Applications and/or protocols that use this URI scheme name.
This URI scheme is intended for use in RFC 3761 [ENUM] databases.
Interoperability considerations.
The URI is designed to be used specifically in conjunction with
systems that utilize the RFC 3761 [ENUM] databases.
Security considerations:
The distribution of CNAM data is often highly restricted.
Distribution of this data would typically be either within a service
providers internal network, or on a private basis between one or
more parties using a variety of security mechanisms to prohibit
general public access. It should be noted that this content type is
designed to carry potentially personal information and as such, may
be subject to restrictions within various national jurisdictions.
The pstn URI 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 [A] and sometimes by physically protecting
Shockey & Livingood Expires March 2008 [Page 9]
Internet-Draft CNAM Enumservice Sept 2007
the underlying network. In any case, it is presumed the environment
where the pstn URI will be used can ensure the integrity and the
confidentiality of the data.
Contacts.
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
Author/Change controller.
This specification is a work item of the IETF ENUM working group,
with the mailing list address enum@ietf.org
References.
[ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
12.
References
12.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.
Shockey & Livingood Expires March 2008 [Page 10]
Internet-Draft CNAM Enumservice Sept 2007
[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] 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] Hansen, T, et al., "The "Guidelines and Registration Procedures
for New URI Schemes", RFC 4395, February 2006
Shockey & Livingood Expires March 2008 [Page 11]
Internet-Draft CNAM Enumservice Sept 2007
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[17] Livingood, J and Shockey, R "IANA Registration for an
Enumservice Containing Public Switched Telephone Network (PSTN)
Signaling Information", RFC 4769, November 2006
[18] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
[19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[20] Berners-Lee, T., et al., " Uniform Resource
Identifiers (URI): Generic Syntax", RFC 3986, January 2005.
[21] Freed, N. and Borenstein, N.S. "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
12.2 Informative References
[A] Kent, S. et al, "Security Archichecture for the Internet Protocol", RFC 4301, December 2005
13. Acknowledgements
The authors wish to thank Larry Masinter and Paul Kyzivat for invaluable input to this document.
14.
Authors' Addresses
Richard Shockey
NeuStar
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1-571-434-5651
Email: richard.shockey@neustar.biz
Shockey & Livingood Expires March 2008 [Page 12]
Internet-Draft CNAM Enumservice Sept 2007
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
Scott Hollenbeck
Verisign
21345 Ridgetop Circle
Dulles VA 20166
Phone : +1 703-948-3257
Email : shollenbeck@verisign.com
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 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
Shockey & Livingood Expires March 2008 [Page 13]
Internet-Draft CNAM Enumservice Sept 2007
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.
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.
Shockey & Livingood Expires March 2008 [Page 14]
