1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4769.txt b/doc/rfc/rfc4769.txt
new file mode 100644
index 0000000..348324d
--- /dev/null
+++ b/doc/rfc/rfc4769.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       J. Livingood
+Request for Comments: 4769                  Comcast Cable Communications
+Category: Standards Track                                     R. Shockey
+                                                                 NeuStar
+                                                           November 2006
+
+
+            IANA Registration for an Enumservice Containing
+    Public Switched Telephone Network (PSTN) Signaling Information
+
+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 IETF Trust (2006).
+
+Abstract
+
+   This document registers the Enumservice type "pstn" and subtype "tel"
+   using the URI scheme 'tel', as well as the subtype "sip" using the
+   URI scheme 'sip' as per the IANA registration process defined in the
+   ENUM specification, RFC 3761.  This Enumservice is used to facilitate
+   the routing of telephone calls in those countries where number
+   portability exists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 1]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Distribution of Data ............................................4
+   3. ENUM Service Registration for PSTN ..............................5
+      3.1. ENUM Service Registration for PSTN with Subtype "tel" ......5
+      3.2. ENUM Service Registration for PSTN with Subtype "sip" ......5
+   4. Examples ........................................................6
+      4.1. Example of a Ported Number, Using a 'tel' URI Scheme .......6
+      4.2. Example of a Ported Number, Using a 'sip' URI Scheme .......6
+      4.3. Example of a Non-Ported Number, Using a 'tel' URI Scheme ...7
+      4.4. Example of a Non-Ported Number, Using a 'sip' URI Scheme ...7
+      4.5. Example Using a Regular Expression .........................7
+   5. Implementation Recommendations ..................................7
+      5.1. Call Processing When Multiple Records Are Returned .........7
+      5.2. NAPTR Configuration issues .................................8
+   6. Examples of E2U+pstn in Call Processing .........................8
+      6.1. Dialed Number Not Available On-Net .........................8
+      6.2. Dialed Number Available On-Net and on the PSTN .............9
+   7. Security Considerations .........................................9
+   8. IANA Considerations ............................................10
+   9. Acknowledgements ...............................................10
+   10. References ....................................................10
+      10.1. Normative References .....................................10
+      10.2. Informative References ...................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 2]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+1.  Introduction
+
+   ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that
+   transforms E.164 numbers (The International Public Telecommunication
+   Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and
+   then uses DNS (Domain Name System, RFC 1034 [3]) delegation through
+   NS records and NAPTR records (Dynamic Delegation Discovery System
+   (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403
+   [4]) to look up what services are available for a specific domain
+   name.
+
+   This document registers Enumservices according to the guidelines
+   given in RFC 3761 [1] to be used for provisioning in the services
+   field of a NAPTR [4] resource record to indicate the types 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.
+
+   Number Portability allows telephone subscribers to keep their
+   telephone numbers when they change service providers, move to a new
+   location, or change the subscribed services [14].  In many countries,
+   such as the United States and Canada, the functions of naming and
+   addressing on the Public Switched Telephone Network (PSTN) have been
+   abstracted.  In the case of a ported number, the dialed number is not
+   directly routable on the PSTN and must be translated into a routing
+   number for call completion.  Other numbers, which are not ported, and
+   which can be routed directly on the PSTN based on the dialed number,
+   are typically assigned to carriers and other entities in large blocks
+   or pools.  Number Portability and other numbering information are
+   distributed in a variety of methods and formats around the world.
+
+   The Enumservices described here could enable service providers to
+   place ported numbers, pooled numbers, and blocks of numbers and their
+   associated PSTN contact information, into externally available or
+   highly locally cached ENUM databases.  This, in turn, could enable
+   such parties to consolidate all telephone number lookups in their
+   networks into a single ENUM lookup, thereby simplifying call routing
+   and network operations, which would then result in either an on-net
+   (IP-based) response or an off-net (PSTN-based) response.
+
+   The following Enumservice is registered with this document: "pstn" to
+   indicate PSTN routing data, including number portability data, non-
+   ported telephone number data (individually or in number blocks), and
+   other PSTN-oriented data that is associated with E.164 telephone
+   numbers.  The purpose of this Enumservice is to provide routing
+   information for telephone numbers that do not designate an endpoint
+   resident on the public Internet or a private/peered Internet Protocol
+
+
+
+Livingood & Shockey        Standards Track                      [Page 3]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   (IP) network.  Thus, these are numbers that are only routable via the
+   traditional PSTN, even if the call originates from an IP network.
+   The URIs returned in this service may use the TEL URI parameters
+   defined in RFC 4694 [10], and implementations must be prepared to
+   accept them.
+
+   The service parameters defined in RFC 3761 indicate that a "type" and
+   a "subtype" may be specified.  Within this set of specifications, the
+   convention is assumed that the "type" (being the more generic term)
+   defines the service and the "subtype" defines the URI scheme.
+
+   When only one URI scheme is associated with a given service, it
+   should be assumed that an additional URI scheme to be used with this
+   service may be added at a later time.  Thus, the subtype is needed to
+   identify the specific Enumservice intended.
+
+2.  Distribution of Data
+
+   The distribution of number portability data is often highly
+   restricted, either by contract or regulation of a National Regulatory
+   Authority (NRA); therefore, NAPTR records specified herein may or may
+   not be part of the e164.arpa DNS tree.
+
+   The authors believe that it is more likely that these records will be
+   distributed on a purely private basis.  Distribution of this NAPTR
+   data could 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), (b) openly available or, (c) distributed by
+   the relevant number portability organization or other industry
+   organization, but possibly on a national basis and subject to or in
+   accordance with national regulatory policy.
+
+   If such data were distributed nationally, the national telephone
+   numbering authority, or some other regulatory body or numbering
+   organization, may have jurisdiction.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 4]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+3.  ENUM Service Registration for PSTN
+
+3.1.  ENUM Service Registration for PSTN with Subtype "tel"
+
+   Enumservice Name: "pstn"
+
+   Enumservice Type: "pstn"
+
+   Enumservice Subtype: "tel"
+
+   URI Scheme: 'tel:'
+
+   Functional Specification:
+
+   These Enumservices indicate that the remote resource identified can
+   be addressed by the associated URI scheme in order to initiate a
+   telecommunication session, which may include two-way voice or other
+   communications, to the PSTN.  These URIs may contain number
+   portability data as specified in RFC 4694 [10].
+
+   Security Considerations: See Section 7.
+
+   Intended Usage: COMMON
+
+   Authors:
+
+   Jason Livingood (jason_livingood@cable.comcast.com)
+   Richard Shockey (richard.shockey@neustar.biz)
+
+   Any other information the author deems interesting:
+
+   A Number Portability Dip Indicator (npdi) should be used in practice
+   (see examples below in Section 4).
+
+3.2.  ENUM Service Registration for PSTN with Subtype "sip"
+
+   Enumservice Name: "pstn"
+
+   Enumservice Type: "pstn"
+
+   Enumservice Subtype: "sip"
+
+   URI Scheme: 'sip:'
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 5]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   Functional Specification:
+
+   These Enumservices indicate that the remote resource identified can
+   be addressed by the associated URI scheme in order to initiate a
+   telecommunication session, which may include two-way voice or other
+   communications, to the PSTN.
+
+   Security Considerations: See Section 7.
+
+   Intended Usage: COMMON
+
+   Authors:
+
+   Jason Livingood (jason_livingood@cable.comcast.com)
+   Richard Shockey (richard.shockey@neustar.biz)
+
+   Any other information the author deems interesting:
+
+   A Number Portability Dip Indicator (npdi) should be used in practice
+   (see examples below in Section 4).
+
+4.  Examples
+
+   The following sub-sections document several examples for illustrative
+   purposes.  These examples shall in no way limit the various forms
+   that this Enumservice may take.
+
+4.1.  Example of a Ported Number, Using a 'tel' URI Scheme
+
+   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+      NAPTR 10 100 "u" "E2U+pstn:tel"
+      "!^.*$!tel:+1-215-555-0123;npdi;rn=+1-215-555-0199!".
+
+   In this example, a Routing Number (rn) and a Number Portability Dip
+   Indicator (npdi) are used as shown in RFC 4694 [10].  The 'npdi'
+   field is included in order to prevent subsequent lookups in legacy-
+   style PSTN databases.
+
+4.2.  Example of a Ported Number, Using a 'sip' URI Scheme
+
+   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+      NAPTR 10 100 "u" "E2U+pstn:sip"
+      "!^.*$!sip:+1-215-555-0123;npdi;rn=+1-215-555-0199
+   @gw.example.com;user=phone!".
+
+   In this example, a Routing Number (rn) and a Number Portability Dip
+   Indicator (npdi) are used as shown in RFC 4694 [10].  The 'npdi'
+   field is included in order to prevent subsequent lookups in legacy-
+
+
+
+Livingood & Shockey        Standards Track                      [Page 6]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   style PSTN databases.  The method of conversion from a tel to a SIP
+   URI is as demonstrated in RFC 3261, Section 19.1.6 [11], as well as
+   in RFC 4694, Section 6 [10].
+
+4.3.  Example of a Non-Ported Number, Using a 'tel' URI Scheme
+
+   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+      NAPTR 10 100 "u" "E2U+pstn:tel"
+      "!^.*$!tel:+1-215-555-0123;npdi!".
+
+   In this example, a Number Portability Dip Indicator (npdi) is used
+   [10].  The 'npdi' field is included in order to prevent subsequent
+   lookups in legacy-style PSTN databases.
+
+4.4.  Example of a Non-Ported Number, Using a 'sip' URI Scheme
+
+   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+      NAPTR 10 100 "u" "E2U+pstn:sip"
+      "!^.*$!sip:+1-215-555-0123;npdi@gw.example.com;user=phone!".
+
+   In this example, a Number Portability Dip Indicator (npdi) is used
+   [10].  The 'npdi' field is included in order to prevent subsequent
+   lookups in legacy-style PSTN databases.  The method of conversion
+   from a tel to a SIP URI is as demonstrated in RFC 3261, Section
+   19.1.6 [11], as well as in RFC 4694, Section 6 [10].
+
+4.5.  Example Using a Regular Expression
+
+   $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+      NAPTR 10 100 "u" "E2U+pstn:tel"
+      "!(^.*)$!tel:\1;npdi!".
+
+   In this example, a regular expression replacement function is used to
+   reduce the size of the NAPTR record.  The tel URI uses "\1", which
+   would dynamically replace the expression with the TN plus the leading
+   "+" -- in this case, +1-215-555-0123.
+
+5.  Implementation Recommendations
+
+5.1.  Call Processing When Multiple Records Are Returned
+
+   It is likely that both E2U+sip and E2U+pstn Enumservice type records
+   will be returned for a given query.  In this case, this could result
+   in what is essentially an on-net and off-net pstn record.  Thus, one
+   record gives the associated address on an IP network, while the other
+   gives the associated address on the PSTN.  As with multiple records
+   resulting from a typical ENUM query of the e164.arpa tree, it is up
+   to the application using an ENUM resolver to determine which
+
+
+
+Livingood & Shockey        Standards Track                      [Page 7]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   record(s) to use and which record(s) to ignore.  Implementers should
+   take this into consideration and build logic into their applications
+   that can select appropriately from multiple records based on
+   business, network, or other rules.  For example, such a resolver
+   could be configured to grant preference to the on-net record, or
+   execute other logic, as required by the application.
+
+5.2.  NAPTR Configuration issues
+
+   It has been suggested that tel URIs may be easier and more efficient
+   to use in practice than SIP URIs.  In addition, the use of tel URIs
+   may result in somewhat smaller NAPTR records, which, when considering
+   adding hundreds of millions of these records to the DNS, could have a
+   substantial impact on the processing and storage requirements for
+   service providers or other entities making use of this Enumservice
+   type.
+
+   Implementers may wish to consider using regular expressions in order
+   to reduce the size of individual NAPTRs.  This will have a
+   significant effect on the overall size of the database involved.
+   Using the example in Section 4.5, above, this is 11 bytes per record.
+
+6. Examples of E2U+pstn in Call Processing
+
+   These are examples of how a switch, proxy, or other calling
+   application may make use of this Enumservice type during the call
+   initiation process.
+
+6.1.  Dialed Number Not Available On-Net
+
+   When the dialed number is not available on-net, the call processing
+   is as follows.
+
+   a) A user, which is connected to a calling application, dials an
+      E.164 telephone number: +1-215-555-0123.
+
+   b) The calling application uses the dialed number to form a NAPTR
+      record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+
+   c) The DNS finds an E2U+pstn:tel record and returns a tel URI for
+      processing by the calling application: tel:+1-215-555-0123;npdi.
+
+   d) The calling application uses routing logic to determine which
+      media gateway is the closest to this number and routes the call
+      appropriately.
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 8]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+6.2.  Dialed Number Available On-Net and on the PSTN
+
+   When the dialed number is available on-net and on the PSTN, the call
+   processing is as follows.
+
+   a) A user, which is connected to a calling application, dials an
+      E.164 telephone number: 1-215-555-0123.
+
+   b) The calling application uses the dialed number to form a NAPTR
+      record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.
+
+   c) The DNS finds both an E2U+pstn record, as well as an E2U+sip
+      record, since this number happens to be on the IP network of a
+      connected network.
+
+   d) The calling application prioritizes the on-net record first:
+      sip:+1-215-555-0123;npdi@gw.example.com;user=phone.
+
+   e) The calling application sets up the SIP call to gw.example.com.
+
+   f) Should the IP call route fail for whatever reason, the calling
+      application may be able to utilize the E2U+pstn record to invoke a
+      fallback route to a media gateway that is connected to the PSTN.
+
+7.  Security Considerations
+
+   DNS, as used by ENUM, is a global, distributed database.  Should
+   implementers of this specification use e164.arpa or any other
+   publicly available domain as the tree for maintaining PSTN
+   Enumservice data, this information would be 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
+   by whom it has been accessed.
+
+   Such data harvesting by third parties is often used to generate lists
+   of targets for unsolicited information.  Thus, a third party could
+   use this to generate a list that they can use to make unsolicited
+   "telemarketing" phone calls.  Many countries have do-not-call
+   registries or other legal or regulatory mechanisms in place to deal
+   with such abuses.
+
+   As noted earlier, carriers, service providers, and other users may
+   simply choose not to publish such information in the public e164.arpa
+   tree.  They may instead simply publish this in their internal ENUM
+   routing database that is only able to be queried by trusted elements
+
+
+
+
+
+Livingood & Shockey        Standards Track                      [Page 9]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   of their network, such as softswitches and SIP proxy servers.  They
+   may also choose to publish such information in a carrier-only branch
+   of the E164.ARPA tree, should one be created.
+
+   Although an E.164 telephone number does not appear to reveal as much
+   identity information about a user as a name in the format
+   sip:username@hostname or email:username@hostname, the information is
+   still publicly available; thus, there is still the risk of unwanted
+   communication.
+
+   An analysis of threats specific to the dependence of ENUM on the DNS
+   and the applicability of DNSSEC [12] to this is provided in RFC 3761
+   [1].  A thorough analysis of threats to the DNS itself is covered in
+   RFC 3833 [13].
+
+8.  IANA Considerations
+
+   This document registers the 'pstn' Enumservice type and the subtype
+   "tel" and "sip" under the Enumservice registry described in the IANA
+   considerations in RFC 3761.  Details of this registration are
+   provided in Section 3 of this document.
+
+9.  Acknowledgements
+
+   The authors wish to thank Lawrence Conroy, Tom Creighton, Jason
+   Gaedtke, Jaime Jimenez, Chris Kennedy, Alexander Mayrhofer, Doug
+   Ranalli, Jonathan Rosenberg, Bob Walter, and James Yu for their
+   helpful discussions of this topic, and detailed reviews of this
+   document.  The authors also wish to thank the IETF's ENUM Working
+   Group for helpful feedback in refining and developing this document.
+
+10. References
+
+10.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, February 2005.
+
+   [3]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+
+
+Livingood & Shockey        Standards Track                     [Page 10]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+   [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", BCP 65, RFC 3405, October
+        2002.
+
+   [9]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+        December 2004.
+
+   [10] Yu, J., "Number Portability Parameters for the "tel" Uniform
+        Resource Identifier", RFC 4694, October 2006.
+
+   [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+        Session Initiation Protocol", RFC 3261, June 2002.
+
+10.2.  Informative References
+
+   [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions", RFC
+        4035, March 2005.
+
+   [13] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+        System (DNS)", RFC 3833, August 2004.
+
+   [14] Foster, M., McGarry, T., and J. Yu, "Number Portability in the
+        Global Switched Telephone Network (GSTN): An Overview", RFC
+        3482, February 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                     [Page 11]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+Authors' Addresses
+
+   Jason Livingood
+   Comcast Cable Communications
+   1500 Market Street
+   Philadelphia, PA 19102
+   USA
+
+   Phone: +1-215-981-7813
+   EMail: jason_livingood@cable.comcast.com
+
+
+   Richard Shockey
+   NeuStar
+   46000 Center Oak Plaza
+   Sterling, VA 20166
+   USA
+
+   Phone: +1-571-434-5651
+   EMail: richard.shockey@neustar.biz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                     [Page 12]
+
+RFC 4769                    PSTN Enumservice               November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (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, 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 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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Livingood & Shockey        Standards Track                     [Page 13]
+