One document matched: draft-ietf-enum-cnam-02.txt
Differences from draft-ietf-enum-cnam-01.txt
ENUM Working Group R. Shockey - editor
Internet-Draft NeuStar
Expires: December 2006 J. Livingood
Comcast Cable Communications
K. McCandless
M. Maharishi
Verisign
July 2006
IANA Registration for an Enumservice
Calling Name Delivery (CNAM) Information and IANA Registration for
Media type ‘application/cnam’
draft-ietf-enum-cnam-02
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 June 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document registers the Enumservice ‘pstn’ and the compound
subtype ‘cnam’ using the URI scheme ‘data:’, as per the IANA
Shockey & Livingood Expires Dec 2006 [Page 1]
Internet-Draft CNAM Enumservice June 2006
registration process defined in the ENUM specification, RFC 3761 and
creates 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 CNAM Data........................................3
4. Structure of CNAM data.........................................3
5. Distribution of CNAM Data......................................4
6. Enumservice CNAM Response Examples.............................5
Example Call Flow..............................................5
Dialed Number..................................................6
7. SIP considerations.............................................6
8. Security Considerations........................................7
9. Privacy Considerations.........................................7
10. Internationalized Character Set Considerations................7
11. IANA Considerations...........................................8
12.1 IANA Enumservice Registration for PSTN Data “cnam”........8
12.2 IANA Registration Template for Media Type ”application/cnam”
...............................................................9
12. References...................................................10
Normative References..........................................10
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
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
Domain Name System (DNS), RFC 1034 [3] and 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 June 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 of BCP 13/RFC 4288.
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 [17].
3.
Definition of CNAM Data
Caller Display Name is a data string of up to 15 ASCII [10]
characters of information associated with a specific calling party
number [11] [12] [13] [14][15]. 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.
Structure of CNAM data
RFC 2397 specifies the structure 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 June 2006
In order to distinguish the particular media type used within this
URL this document specifically registers with IANA the mediatype
‘application/cnam’.
All responses using this specification SHOULD specifically reference
the media type ‘application/cnam’
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 [14] , consequently the following responses to a query from a
well known database are reserved.
Within the media type ‘application/cnam’ an optional parameter
‘unavailable’ is supported as well as two options are defined.
Calling Name Privacy Indicator: ‘p’
This parameter is defined, as the Calling Party does not wish to have
their Display Name displayed.
Usage: data:application/cnam;unavailable=p,
Calling Name Status Indicator
Definition: ‘u’
This parameter is defined as the well known database has no data
available for that particular E.164 number
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
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
Shockey & Livingood Expires Dec 2006 [Page 4]
Internet-Draft CNAM Enumservice June 2006
nationally, a national regulatory body may have jurisdiction,
especially since CNAM information may contain Personally Identifying
Information [PII]. 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 PII data 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"
"!^.*$!data:application/cnam;unavailable=u,!".
Example Call Flow
Typically, the Caller Display Name in the PSTN is delivered to the
called party during the first long silence interval after the first
ringing [15] (see requirement R3-341). If the Called party answers
the call before this, Calling Name may not be delivered. .
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.
Shockey & Livingood Expires Dec 2006 [Page 5]
Internet-Draft CNAM Enumservice June 2006
Dialed Number
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 in the SIP INVITE’s 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 tel 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 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
In those cases where SIP proxies must carry CNAM data as P-asserted
identity fields as defined in RFC 3325 [16]
Shockey & Livingood Expires Dec 2006 [Page 6]
Internet-Draft CNAM Enumservice June 2006
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
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, and other users may simply choose not to
publish such information in a DNS tree, but may instead simply
privately exchange and publish this in their internal ENUM database,
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 [B] to this is provided in RFC 3761
[1]. A thorough analysis of threats to the DNS itself is covered in
RFC 3833 [C].
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 Caller Display 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 Caller
Display Name are blocked are prevented from establishing a session.
10.
Internationalized Character Set Considerations
ANSI standards specify the use of ASCII for in the response to TCAP
queries for Caller Display Name. This specification does not
Shockey & Livingood Expires Dec 2006 [Page 7]
Internet-Draft CNAM Enumservice June 2006
preclude the use of internationalized characters within the data URI,
nor does it preclude the use of more than 15 characters.
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 media type
‘application/cnam’ per BCP 13/RFC 2048
12.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
Shockey & Livingood Expires Dec 2006 [Page 8]
Internet-Draft CNAM Enumservice June 2006
12.2 IANA Registration Template for Media Type ”application/cnam”
To: ietf-types@iana.org
Subject: Registration of media type application/cnam
Type name: application
Subtype name: cnam
Required parameters: “unavailable”
Optional parameters:
Two optional parameters are defined.
Calling Name Privacy Indicator: ‘p’
This parameter defined as the Calling Party does not wish to have
their Display Name displayed.
Intended usage: ‘unavailable=p’
Calling Name Status Indicator: ‘u’
This parameter is defined as “not available/unavailable” defined as
data is available for that particular E.164 number.
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 [ richard.shockey@neustar.biz or richard@shockey.us ]
Shockey & Livingood Expires Dec 2006 [Page 9]
Internet-Draft CNAM Enumservice June 2006
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@ierf.org
Other Information:
Security Considerations:
12.
References
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.
[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 June 2006
[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.
[10] American National Standards Institute (ANSI), Coded
Character Set - 7-Bit American National Standard Code for Information
Interchange, ANSI X3.4, 1986.
[11] 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
[12] American National Standards Institute (ANSI), Telecommunications
- Integrated Services Digital Network (ISDN) _ Calling Line
identification Presentation and Restriction Supplementary Services,
ANSI T1.625-1993
[13] American National Standards Institute (ANSI),Telecommunications
- Calling Name Identification Presentation, ANSI T1.641-1995
[14] Telcordia Technologies, "CLASS Feature: Calling Name Delivery
Generic Requirements", GR-1188-CORE, Issue 2,December 2000
[15] Telcordia Technologies, "CLASS Feature: Calling Number
Delivery", GR-31-CORE, Issue 1, June 2000
[16] Jennings, C., et.al “Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within Trusted
Networks”, RFC 3325, November 2002
[17] Masinter, L., “The "data" URL scheme”, RFC 2397, August 1998
[18] Bradner, S., “Key words for use in RFC’s to Indicate Requirement
Levels”, BCP 14, RFC 2119, March 1997.
[19] Freed, N, et.al. “Media Type Specifications and Registration
Procedures”, BCP 13 RFC 4288, December 2005
Informative References
[A] Bradner, et al., "IANA Registration for Enumservices email, fax,
mms, ems and sms", draft-ietf-enum-msg-05.txt, May 2005.
[B] Arends, R. and et al., "Protocol Modifications for the DNS
Security Extensions", RFC 4035, March 2005.
Shockey & Livingood Expires Dec 2006 [Page 11]
Internet-Draft CNAM Enumservice June 2006
[C] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[D] Peterson, J., "enumservice Registration for Session Initiation
Protocol (SIP) Addresses-of-Record”, RFC 3764, April 2004.
Authors’ Addresses
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
Shockey & Livingood Expires Dec 2006 [Page 12]
Internet-Draft CNAM Enumservice June 2006
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
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:12:58 |