From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4415.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc4415.txt (limited to 'doc/rfc/rfc4415.txt') 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] + -- cgit v1.2.3