summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4415.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4415.txt')
-rw-r--r--doc/rfc/rfc4415.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc4415.txt b/doc/rfc/rfc4415.txt
new file mode 100644
index 0000000..7439ee0
--- /dev/null
+++ b/doc/rfc/rfc4415.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group R. Brandner
+Request for Comments: 4415 Siemens AG
+Category: Standards Track L. Conroy
+ Siemens Roke Manor Research
+ R. Stastny
+ Oefeg
+ February 2006
+
+
+ IANA Registration for Enumservice Voice
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document registers the Enumservice "voice" (which has a defined
+ subtype "tel"), as per the IANA registration process defined in the
+ ENUM specification RFC 3761. This service indicates that the contact
+ held in the generated Uniform Resource Identifier (URI) can be used
+ to initiate an interactive voice (audio) call.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Voice Service Registration . . . . . . . . . . . . . . . . . . 3
+ 4. Example of voice:tel Enumservice . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 1]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+1. Introduction
+
+ ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms
+ E.164 numbers [2] into domain names and then uses DNS (RFC 1034 [3])
+ features such as delegation through NS records, and the use of Naming
+ Authority Pointer (NAPTR) records, to look up the communication
+ services available for a specific domain name.
+
+ This document registers an Enumservice according to the guidelines
+ given in RFC 3761 to be used for provisioning in the services field
+ of a NAPTR [4] resource record to indicate what class of
+ functionality a given endpoint offers. The registration is defined
+ within the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7]
+ [8]) hierarchy, for use with the "E2U" DDDS application defined in
+ RFC 3761.
+
+ Enumservices have a type and subtype. This latter is optional, as it
+ may be implicit in the service type. The type defines the kind of
+ communication session that can be initiated using the contact
+ indicated by the URI generated by the enclosing NAPTR. In
+ telecommunications engineering terms, it reflects the "teleservice".
+
+ The subtype defines the subsystem that is to be used to initiate the
+ communication session. Note that the subtype definition is usually
+ associated with the URI scheme that is to be used.
+
+ Both the type and subtype (where present) must be supported for the
+ NAPTR to be used by a potential correspondent.
+
+ There are a number of DDDS applications in addition to ENUM (for
+ example, see [7] and [8]). However, an Enumservice indication
+ operates only within the context of the "E2U" (ENUM) DDDS
+ Application.
+
+ Whilst the protocol elements that make up ENUM are defined in the
+ above documents and in this one, further examples of the use to which
+ these may be put are given in other documents, for example, in ETSI
+ TS 102 172 [11].
+
+ This document registers the Enumservice "voice" (which has a defined
+ subtype "tel"), as per the IANA registration process defined in the
+ ENUM specification RFC 3761. This service indicates that the contact
+ held in the generated URI can be used to initiate an interactive
+ voice (audio) call.
+
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 2]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+2. 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 [9].
+
+3. Voice Service Registration
+
+ Enumservice Name: "voice"
+
+ Enumservice Type: "voice"
+
+ Enumservice Subtype: "tel"
+
+ URI Scheme: 'tel:'
+
+ Functional Specification:
+
+ The kind of communication indicated by this Enumservice is
+ "Interactive Voice". From a protocol perspective, this
+ communication is expected to involve bidirectional media streams
+ carrying audio data.
+
+ A client may imply that the person controlling population of a
+ NAPTR holding this Enumservice indicates his capability to engage
+ in an interactive voice session when contacted using the URI
+ generated by this NAPTR.
+
+ Security Considerations:
+
+ See Section 5.
+
+ Intended Usage: COMMON
+
+ Authors:
+
+ Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author
+ contact detail, see Authors' Addresses section)
+
+ Any other information the author deems interesting:
+
+ This Enumservice indicates that the person responsible for the
+ NAPTR is accessible via the Public Switched Telephone Network
+ (PSTN) or Public Land Mobile Network (PLMN) using the value of the
+ generated URI.
+
+ The kind of subsystem required to initiate a Voice Enumservice
+ with this subtype is a "Dialer". This is a subsystem that either
+
+
+
+Brandner, et al. Standards Track [Page 3]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+ provides a local connection to the PSTN or PLMN or provides an
+ indirect connection to those networks. The subsystem will use the
+ telephone number held in the generated URI to place a voice call.
+ The voice call is placed to a network that uses E.164 numbers to
+ route calls to an appropriate destination.
+
+ Note that the PSTN/PLMN connection may be indirect. The end user
+ receiving this NAPTR may have a relationship with a Communications
+ Service Provider that accepts call initiation requests from that
+ subsystem using an IP-based protocol such as SIP or H.323, and
+ places the call to the PSTN using a remote gateway service. In
+ this case, the provider either may accept requests using "tel:"
+ URIs or has a defined mechanism to convert "tel:" URI values into
+ a "protocol-native" form.
+
+ The "tel:" URI value SHOULD be fully qualified (using the "global
+ phone number" form of RFC 3966 [10]). A "local phone number" as
+ defined in that document SHOULD NOT be used unless the controller
+ of the zone in which the NAPTR appears is sure that it can be
+ distinguished unambiguously by all clients that can access the
+ resource record and that a call from their network access points
+ can be routed to that destination.
+
+4. Example of voice:tel Enumservice
+
+ The following is an example of the use of the Enumservice registered
+ by this document in a NAPTR resource record.
+
+ $ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.
+ 3.8.0 NAPTR 10 100 "u" "E2U+voice:tel"
+ "!^.*$!tel:+441414960000!" .
+
+5. Security Considerations
+
+ DNS, as used by ENUM, is a global, distributed database. Thus, any
+ information stored there is visible to anyone anonymously. Whilst
+ this is not qualitatively different from publication in a telephone
+ directory, it does open the data subjects to having "their"
+ information collected automatically without any indication that this
+ has been done or by whom.
+
+ Such data harvesting by third parties is often used to generate lists
+ of targets for unrequested information; in short, they are used to
+ address "spam". Anyone who uses a Web-archived mailing list is aware
+ that the volume of "spam" email sent increases when he or she posts
+ to the mailing list; publication of a telephone number in ENUM is no
+ different, and may be used for attempts to send "junk faxes" or "junk
+ SMS", for example.
+
+
+
+Brandner, et al. Standards Track [Page 4]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+ Many mailing list users have more than one email address and use
+ "sacrificial" email accounts when posting to such lists to help
+ filter out unrequested emails sent to them. This is not so easy with
+ published telephone numbers; the PSTN E.164 number assignment process
+ is much more involved and usually a single E.164 number (or a fixed
+ range of numbers) is associated with each PSTN access. Thus,
+ providing a "sacrificial" phone number in any publication is not
+ possible.
+
+ Due to the implications of publishing data on a globally accessible
+ database, as a principle the data subjects MUST give their explicit
+ informed consent to data being published in ENUM.
+
+ In addition, they should be made aware that, due to storage of such
+ data during harvesting by third parties, removal of the data from
+ publication will not remove any copies that have been taken; in
+ effect, any publication may be permanent.
+
+ However, regulations in many regions will require that the data
+ subjects can at any time request that the data be removed from
+ publication and that their consent for its publication be explicitly
+ confirmed at regular intervals.
+
+ When placing a voice call via the PSTN (or from the Public Land
+ Mobile Network), the sender may be charged for this action. In both
+ kinds of networks, calling some numbers is more expensive than
+ sending to others; both kinds of networks have "premium rate"
+ services that can be charged at a rate considerably more than a
+ "normal" call. As such, it is important that end users be asked to
+ confirm placing the call and that the destination number be presented
+ to them. It is the originating user's choice whether or not to place
+ a call to this destination number, but the originating user SHOULD be
+ shown the destination number so that he or she can make this
+ decision.
+
+ In addition to the specific security considerations given above, all
+ security considerations given in RFC 3761 apply, as well as the
+ DNS-specific threats covered in RFC 3833 [12].
+
+6. IANA Considerations
+
+ The IANA has registered the Enumservice "voice" with a single subtype
+ "tel" according to the framework defined in RFC 3761. The current
+ document defines this Enumservice and the expected behaviour of
+ clients.
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 5]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+7. References
+
+7.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 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, BCP 14, March 1997.
+
+ [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+ December 2004.
+
+7.2. Informative References
+
+ [11] ETSI, "Minimum Requirements for Interoperability of ENUM
+ Implementations", ETSI TS 102 172, January 2005.
+
+ [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+ System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 6]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+Authors' Addresses
+
+ Rudolf Brandner
+ Siemens AG
+ Hofmannstr. 51
+ 81359 Munich
+ Germany
+
+ Phone: +49-89-722-51003
+ EMail: rudolf.brandner@siemens.com
+
+
+ Lawrence Conroy
+ Siemens Roke Manor Research
+ Roke Manor
+ Romsey
+ United Kingdom
+
+ Phone: +44-1794-833666
+ EMail: lwc@roke.co.uk
+
+
+ Richard Stastny
+ Oefeg
+ Postbox 147
+ 1103 Vienna
+ Austria
+
+ Phone: +43-664-420-4100
+ EMail: Richard.stastny@oefeg.at
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 7]
+
+RFC 4415 IANA Voice Enumservice Registration February 2006
+
+
+Full 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.
+
+ 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.
+
+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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Brandner, et al. Standards Track [Page 8]
+