ENUM Working Group R. Shockey-editor
INTERNET-DRAFT NeuStar
Intended Status : Standards Track September 22, 2008
Expires: February 2009
IANA Registration for an Enumservice Calling Name Delivery
(CNAM) Information and IANA Registration for URI type
'pstndata'
draft-ietf-enum-cnam-08.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 on February 22, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
R. Shockey - editor Expires February 2009 [Page 1]
Internet-Draft CNAM Enumservice August 2008
Abstract
This document registers the Enumservice 'pstndata' and
subtype 'cnam' using the URI scheme 'pstndata:' as per the
IANA registration process defined in the ENUM specification,
RFC 3761 and registers a new URI type 'pstndata:'.
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
pstndata 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. Introduction ........................................ 3
2. Protocol Design Considerations. ..................... 4
3. Definition of PSTN CNAM Data ........................ 4
4. The PSTNDATA URI .................................... 4
5. Enumservice Privacy Responses and Parameters ........ 5
6. Distribution of CNAM Data ........................... 6
7. Enumservice CNAM Response Examples .................. 6
8. Usage Considerations ................................ 7
9. Privacy Considerations .............................. 7
10. Security Considerations ............................ 8
11. IANA Considerations ................................ 9
11.1 IANA Enumservice Registration for "pstndata" with
subtype "cnam"........................................ 9
11.2 IANA Registration Template for URI "pstndata:".. 10
11.3 Datatype Token Registry......................... 13
11.4 IANA Registration Template for datatype Token
"cnam"............................................... 13
12. Normative References .............................. 14
13. Informative References ............................ 15
14. Acknowledgements .................................. 16
15. Author's Address .................................. 16
16. Full Copyright Statement .......................... 17
Requirements notation
R. Shockey - editor Expires February 2009 [Page 2]
Internet-Draft CNAM Enumservice August 2008
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALLNOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [16].
1. Introduction
RFC 3761 (ENUM) [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.
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 URI type 'pstndata' per the requirements of
RFC 4395[15].
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 [1].
The service parameters defined in RFC 3761 [1] 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, 'pstndata' and one
subtype 'cnam' with the URI scheme specified, 'pstndata:'.
R. Shockey - editor Expires February 2009 [Page 3]
Internet-Draft CNAM Enumservice August 2008
2. Protocol Design Considerations.
The design of this protocol was influenced by several
factors. RFC 3761 [1] 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 [1] 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 a
secondary protocol mechanism such as LDAP or IRIS to retrieve
the data, it could significantly impact call setup times.
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 PSTNDATA URI
This document proposes a new URI scheme 'PSTNDATA:'
specifically to carry PSTN data in general and CNAM data
specifically.
pstndatauri = "pstndata:" datatype ["/" telephone-
subscriber ] ";" content
R. Shockey - editor Expires February 2009 [Page 4]
Internet-Draft CNAM Enumservice August 2008
datatype = "cnam"
; Other datatypes can be defined by adding
; alternative values.
content = [ mediatype ] [ ":base64" ] "," data
mediatype = [ type "/" subtype ] *( ";" parameter )
data = *urlchar
parameter = attribute "=" value
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 pstn URI, nor does it preclude the use of more
than 15 characters.
5.
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 datatype 'cnam' two special content cases with
mediatype parameters and data are defined:
Calling Name Privacy Indicator: 'unavailable=p,<reason>'
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.
In this case, the data element is populated with <reason>
rather than the Calling Name itself, such as "Private".
Usage: pstndata:cnam;;unavailable=p,<reason>
Calling Name Status Indicator
Definition: 'unavailable=u,<reason>'
R. Shockey - editor Expires February 2009 [Page 5]
Internet-Draft CNAM Enumservice August 2008
This parameter is defined as there is no Calling Name data
for that E.164 number available.
In this case, the data element is populated with <reason>
rather than the Calling Name itself, such as "Unavailable" or
"Out of Area".
Usage: pstndata:cnam;;unavailable=u,<reason>
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
country's 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+pstndata:cnam"
"!^.*$!pstndata:cnam/+15052121111;;charset=us-
ascii,Francois%20Audet!".
ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstndata:cnam"
"!^.*$!pstndata:cnam/+15052121111;;charset=us-
ascii,foo=bar,Francois%20Audet!".
R. Shockey - editor Expires February 2009 [Page 6]
Internet-Draft CNAM Enumservice August 2008
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstndata:cnam"
"!^.*$!pstndata:cnam/+15052121111;;unavailable=u,Out%20of%20A
rea!".
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstndata:cnam"
"!^.*$!pstndata:cnam;;unavailable=p,Private!".
$ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net.
NAPTR 10 100 "u" "E2U+pstndata:cnam"
"!^.*$!pstndata: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.
R. Shockey - editor Expires February 2009 [Page 7]
Internet-Draft CNAM Enumservice August 2008
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
Use of the CNAM Enumservice shall either be within a service
providers 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.
In many cases, the actual information that needs to be
protected is the combination of the Name associated with the
Telephone Number or the association of the name with the
telephone call. So, it will be necessary to protect the
response to the query that provides the association between
the two elements.
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
[15] and sometimes by physically protecting the underlying
network. In any case, the provider should ensure that
measures are taken to prevent both fraud and unauthorized
R. Shockey - editor Expires February 2009 [Page 8]
Internet-Draft CNAM Enumservice August 2008
disclosure by using a combination of authentication and
Encryption.
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 [1].
Details of this registration are provided in sections 13 and
14 of this document.
This document also registers with the IANA the URI
'pstndata:' per RFC 4395 [15]
11.1 IANA Enumservice Registration for "pstndata" with
subtype "cnam"
Enumservice Name: "cnam"
Enumservice Type: "pstndata"
Enumservice Subtype: "cnam"
URI Schemes: "pstndata:"
Functional Specification:
This Enumservice indicates that a resource record contains
Calling Name Delivery Information that can be addressed by
the associated 'pstndata:' 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.
Intended Usage: COMMON
Authors:
Richard Shockey and Jason Livingood, et. al. (for author
contact detail see Authors' Addresses section)
R. Shockey - editor Expires February 2009 [Page 9]
Internet-Draft CNAM Enumservice August 2008
11.2 IANA Registration Template for URI "pstndata:"
URI scheme name.
The name of the URI is "pstndata:".
Status.
The intended status is Permanent. NOTE: The distribution of
CNAM data is often highly restricted. Usage of this URI
should either be within a service providers internal network,
or on a private basis between one or more parties using a
variety of security mechanisms to prevent general public
access. The records described herein should not be part of
the e164.arpa or any other portion of the DNS tree.
Other datatypes can be defined by adding alternative values.
Tokens are registered with IANA.
URI scheme syntax.
pstndatauri = "pstndata:" datatype ["/" telephone-
subscriber ] ";" content
datatype = "cnam"
; Other datatypes can be defined by adding
; alternative values.
content = [ mediatype ] [ ":base64" ] "," data
mediatype = [ type "/" subtype ] *( ";" parameter )
data = *urlchar
parameter = attribute "=" value
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.
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
R. Shockey - editor Expires February 2009 [Page 10]
Internet-Draft CNAM Enumservice August 2008
"Reason for Absence of Name" in GR-1188 [13], consequently
the following responses to a query are reserved.
Within the datatype 'cnam' two special content cases with
mediatype parameters and data are defined:
Calling Name Privacy Indicator: 'unavailable=p,<reason>'
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.
In this case, the data element is populated with <reason>
rather than the Calling Name itself, such as "Private".
Usage: pstndata:cnam;;unavailable=p,<reason>
Calling Name Status Indicator
Definition: 'unavailable=u,<reason>'
This parameter is defined as there is no Calling Name data
for that E.164 number available.
In this case, the data element is populated with <reason>
rather than the Calling Name itself, such as "Unavailable" or
"Out of Area".
Usage: pstndata:cnam;;unavailable=u,<reason>
Encoding considerations.
The purpose of this URI is to enable service providers to
place Calling Name Delivery information (CNAM) into RFC
3761 [1] 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[1].
The information stored in these databases can be encoded to
facilitate storage and retrieval operations. The type of
R. Shockey - editor Expires February 2009 [Page 11]
Internet-Draft CNAM Enumservice August 2008
encoding used is identified using appropriate media type
parameters. If not otherwise identified, character data is
presumed to be encoded using US-ASCII.
Applications and/or protocols that use this URI scheme name.
This URI scheme is intended for use in ENUM RFC 3761 [1]
databases.
Interoperability considerations.
The URI is designed to be used specifically in conjunction
with trusted systems that utilize the RFC 3761 [1] 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. In
many cases, the actual information that needs to be protected
is the combination of the Name associated with the Telephone
Number or the association of the name with the telephone
call. So, it will be necessary to protect the response to
the query that provides the association between the two
elements.
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 [15]
and sometimes by physically protecting the underlying
network. In any case, the provider should ensure that
measures are taken to prevent both fraud and unauthorized
disclosure by using a combination of authentication and
Encryption.
R. Shockey - editor Expires February 2009 [Page 12]
Internet-Draft CNAM Enumservice August 2008
11.3 Datatype Token Registry
IANA is requested to create a registry for datatype tokens
described in section 11.2. Values shall be registered using
the Standards Action policy described in BCP 26 [22].
Specifications presented to the IESG for standards action
MUST include both the requested token and a syntax
specification for the token.
Registry Name: "pstndata: URI datatype Token Registry"
Registration Template:
Datatype name: <token name>
Datatype specification: <name of IESG-approved standard>
11.4 IANA Registration Template for datatype Token "cnam"
Datatype name: cnam
Datatype specification: Section 11.2 of this document.
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
R. Shockey - editor Expires February 2009 [Page 13]
Internet-Draft CNAM Enumservice August 2008
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.
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, October2002.
[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.
R. Shockey - editor Expires February 2009 [Page 14]
Internet-Draft CNAM Enumservice August 2008
[8] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Five: URI.ARPA Assignment Procedures", RFC
3405, October 2002.
[15] Hansen, T, et al., "The "Guidelines and Registration
Procedures for New URI Schemes", RFC 4395, February 2006
[16] Bradner, S., "Key words for use in RFC's 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.
[22] Narten, T. and Alvestrand, H. "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, October
1998
13.
Informative References
[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
R. Shockey - editor Expires February 2009 [Page 15]
Internet-Draft CNAM Enumservice August 2008
Interfaces - Analog Voice grade 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] Kent, S. et al, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005
14.
Acknowledgements
The authors wish to thank Larry Masinter, Paul Kyzivat,
Hadriel Kaplan and Don Troshynski for invaluable input to
this document.
15.
Author's Address
Richard Shockey - editor
NeuStar
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1-571-434-5651
Email: richard.shockey@neustar.biz
Jason Livingood
Comcast Cable Communications
R. Shockey - editor Expires February 2009 [Page 16]
Internet-Draft CNAM Enumservice August 2008
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
16.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 PRESENTS 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
R. Shockey - editor Expires February 2009 [Page 17]
Internet-Draft CNAM Enumservice August 2008
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
R. Shockey - editor Expires February 2009 [Page 18]