doc: Add RFC documents

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]
+