doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc4759.txt b/doc/rfc/rfc4759.txt
new file mode 100644
index 0000000..7c01af5
--- /dev/null
+++ b/doc/rfc/rfc4759.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         R. Stastny
+Request for Comments: 4759                                         Oefeg
+Category: Standards Track                                     R. Shockey
+                                                            Neustar Inc.
+                                                               L. Conroy
+                                                     Roke Manor Research
+                                                           November 2006
+
+
+           The ENUM Dip Indicator Parameter for the "tel" URI
+
+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 defines a new parameter "enumdi" for the "tel" Uniform
+   Resource Identifier (URI) to support the handling of ENUM queries in
+   Voice over Internet Protocol (VoIP) network elements.  A VoIP network
+   element may receive a URI containing an E.164 number, where that URI
+   contains an "enumdi" parameter.  The presence of the "enumdi"
+   parameter indicates that an ENUM query has already been performed on
+   the E.164 number by a previous VoIP network element.  Equally, if a
+   VoIP network element sends such a URI, it asserts that an ENUM query
+   has been carried out on this number.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 1]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Formal Syntax ...................................................3
+   4. Normative Rules .................................................3
+      4.1. Options for ENUM Domain Providers ..........................3
+      4.2. Client Behaviour for VoIP Network Elements .................3
+           4.2.1. Handling a URI with the "enumdi" Parameter ..........3
+           4.2.2. Adding the "enumdi" Parameter to URIs ...............4
+           4.2.3. Handling a URI Retrieved from ENUM ..................4
+   5. Examples ........................................................4
+   6. Security Considerations .........................................5
+   7. IANA Considerations .............................................5
+   8. Acknowledgements ................................................6
+   9. References ......................................................6
+      9.1. Normative References .......................................6
+      9.2. Informative References .....................................6
+
+1.  Introduction
+
+   VoIP network elements (including User Agent Servers and User Agent
+   Clients) may be set up in different ways to handle E.164 [3] numbers
+   during call setup, depending on the capabilities provided.  One
+   common approach is to query ENUM as defined in RFC 3761 [4], and to
+   use the set of NAPTR resource records that is returned.
+
+   If the ENUM query leads to a result, the call is set up accordingly.
+   If the ENUM query does not lead finally to a result, another database
+   may be queried and/or the call may finally be routed to the Public
+   Switched Telephone Network (PSTN).  In doing so, the call may be
+   routed to another VoIP network element.  To indicate in signalling to
+   this next VoIP element that an ENUM query has already been made for
+   the "tel" URI (specified in RFC 3966 [5]), the "enumdi" parameter is
+   used, to prevent the next VoIP network element from repeating
+   redundant queries.
+
+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
+   [1].
+
+
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 2]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+3.  Formal Syntax
+
+   The following syntax specification uses the Augmented Backus-Naur
+   Form (ABNF) as described in RFC 4234 [2] to extend the syntax of the
+   "par" production defined in the ABNF of RFC 3966 [5].
+
+   par =/ enum-dip-indicator
+
+   enum-dip-indicator = ";enumdi"
+
+   The enum-dip-indicator is an optional parameter for the "tel" URI.
+   Note also that enum-dip-indicator can appear at most once in any
+   "tel" URI.
+
+4.  Normative Rules
+
+4.1.  Options for ENUM Domain Providers
+
+   A domain provider can, at its choosing, populate a NAPTR record with
+   a "tel" URI that contains the enum dip indicator.  This would, as a
+   consequence of the rules stated below, inform the client that it
+   should not bother performing a query and pass the request on.
+
+4.2.  Client Behaviour for VoIP Network Elements
+
+   This section discusses how a VoIP network element handles a received
+   "tel" URI that contains the "enumdi" parameter or has queried ENUM in
+   e164.arpa. for a given E.164 number.
+
+4.2.1.  Handling a URI with the "enumdi" Parameter
+
+   If a VoIP network element receives a "tel" URI containing the
+   "enumdi" parameter, the VoIP network element SHOULD NOT retrieve the
+   related information for this number from ENUM in e164.arpa. even if
+   it would normally do so.
+
+   Note that the recipient network element may reasonably choose to
+   query ENUM if it does not have a trust relationship with the
+   immediate sender of the URI.
+
+   If the "tel" URI (received from a trusted entity) is to be passed to
+   the next network element, the VoIP network element MUST pass on the
+   received URI containing the "enumdi" parameter unchanged.
+
+   If, however, the URI has been received from an untrusted entity, then
+   the recipient entity may either strip it before sending the URI
+   onwards or instead carry out its own ENUM query and add the parameter
+   accordingly to the URI (see next).
+
+
+
+Stastny, et al.             Standards Track                     [Page 3]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+4.2.2.  Adding the "enumdi" Parameter to URIs
+
+   When a VoIP network element queries ENUM in e164.arpa. for a given
+   E.164 number and the result of the query is DNS error code 3
+   (commonly known as "NXDOMAIN"), then if that network element chooses
+   to pass the call to another network element by using a "tel" URI, the
+   "enumdi" parameter MUST be set.
+
+4.2.3.  Handling a URI Retrieved from ENUM
+
+   When a VoIP network element queries ENUM in e164.arpa. for a given
+   E.164 number and either:
+
+   o  the result of the query includes a NAPTR resource record
+      containing a "tel" URI that has the same E.164 number, or
+
+   o  the result of the query includes a NAPTR resource record
+      containing a "tel" URI with the "enumdi" parameter set,
+
+   then if that retrieved "tel" URI is chosen to be passed to another
+   network element, the sending VoIP network element MUST pass on the
+   retrieved URI with the "enumdi" parameter set.
+
+   When a VoIP network element queries ENUM in e164.arpa. for a given
+   E.164 number and the result is a "tel" URI with a different E.164
+   number that lacks the enum dip indicator, the client can either
+   perform another query against that number or pass the request on, as
+   a matter of local policy.
+
+5.  Examples
+
+
+   a.  A VoIP network element called server.example.com receives a "tel"
+       URI tel:+441632960038.  The VoIP network element queries the DNS
+       for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa.,
+       and gets an error response with code = 3 (commonly known as
+       "NXDOMAIN").  The VoIP network element decides to route the call
+       to the PSTN via another VoIP network element called
+       gw.example.com.
+
+          It therefore signals to the next VoIP network element with:
+             tel:+441632960038;enumdi
+          or (using the procedures of RFC 3261 [6] section 19.1.6):
+             sip:+441632960038;enumdi@gw.example.com;user=phone
+
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 4]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+   b.  A VoIP network element called server.example.com receives a "tel"
+       URI tel:+441632960038.  The VoIP network element queries the DNS
+       for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa.,
+       and receives the same "tel" URI in reply (i.e.,
+       tel:+441632960038).
+
+       The VoIP network element decides to route the call to the PSTN
+       via another VoIP network element called gw.example.com.
+
+          It therefore signals to this next VoIP network element with:
+             tel:+441632960038;enumdi
+          or (using the procedures of RFC 3261 [6] section 19.1.6):
+             sip:+441632960038;enumdi@gw.example.com;user=phone
+
+6.  Security Considerations
+
+   In addition to those security implications discussed in the "tel" URI
+   [5] specification, there are new security implications associated
+   with the defined parameter.
+
+   If the "enumdi" is illegally inserted into the "tel" URI when the
+   signalling message carrying the "tel" URI is en route to the
+   destination entity, the call may be routed to the PSTN network,
+   incurring unexpected charges or causing a downstream VoIP network
+   element to reject the call setup.  Many network elements that will
+   process URIs containing this parameter will maintain trust
+   relationships with others.  If such a URI is received from an entity
+   outside the trust boundary of the recipient, then that recipient
+   entity may reasonably ignore it and make an ENUM query itself.  In so
+   doing, it can avoid this potential attack.
+
+   It is less a problem if the "enumdi" is illegally removed.  An
+   additional ENUM query may be performed to retrieve the routing number
+   information and have the "enumdi" included again.
+
+   It is RECOMMENDED that protocols carrying the "tel" URI ensure
+   message integrity during the message transfer between the two
+   communicating network elements so as to detect any unauthorised
+   changes to the content of the "tel" URI and other information.
+
+7.  IANA Considerations
+
+   This document does not itself require any IANA actions.
+
+   It does define a parameter for the "tel" URI.  Further information on
+   a registry for such parameters is covered in the IANA "tel" URI
+   Parameter Registry [7].
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 5]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+8.  Acknowledgements
+
+   Many thanks for the thorough review provided by Alex Mayrhofer.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, BCP 14, March 1997.
+
+   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 4234, October 2005.
+
+   [3]  ITU-T, "The International Public Telecommunication Number Plan",
+        Recommendation E.164, February 2005.
+
+   [4]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
+        Identifiers (URI) Dynamic Delegation  Discovery System (DDDS)
+        Application (ENUM)", RFC 3761, April 2004.
+
+   [5]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+        December 2004.
+
+   [6]  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.
+
+9.2.  Informative References
+
+   [7]  Jennings, C. and V. Gurbani, "The Internet Assigned Number
+        Authority (IANA) tel Uniform Resource Identifier (URI) Parameter
+        Registry", Work in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 6]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    November 2006
+
+
+Authors' Addresses
+
+   Richard Stastny
+   Oefeg
+   Postbox 147
+   1103 Vienna
+   Austria
+
+   Phone: +43-664-420-4100
+   EMail: Richard.stastny@oefeg.at
+
+
+   Richard Shockey
+   Neustar Inc.
+   46000 Center Oak Plaza
+   Sterling, VA  20166
+   United States
+
+   Phone: +1-571-434-5651
+   EMail: richard.shockey@neustar.biz
+
+
+   Lawrence Conroy
+   Roke Manor Research
+   Roke Manor
+   Romsey
+   United Kingdom
+
+   Phone: +44-1794-833666
+   EMail: lconroy@insensate.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 7]
+
+RFC 4759         ENUM Dip Indicator "tel" URI parameter    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.
+
+
+
+
+
+
+Stastny, et al.             Standards Track                     [Page 8]
+