doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7976.txt b/doc/rfc/rfc7976.txt
new file mode 100644
index 0000000..ef06c5d
--- /dev/null
+++ b/doc/rfc/rfc7976.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       C. Holmberg
+Request for Comments: 7976                                    N. Biondic
+Updates: 7315                                                   Ericsson
+Category: Informational                                     G. Salgueiro
+ISSN: 2070-1721                                                    Cisco
+                                                          September 2016
+
+
+          Updates to Private Header (P-Header) Extension Usage
+      in Session Initiation Protocol (SIP) Requests and Responses
+
+Abstract
+
+   The Third Generation Partnership Project (3GPP) has identified cases
+   where different SIP private header extensions referred to as "P-"
+   header fields, and defined in RFC 7315, need to be included in SIP
+   requests and responses currently not allowed according to RFC 7315.
+   This document updates RFC 7315, in order to allow inclusion of the
+   affected "P-" header fields in such requests and responses.
+
+   This document also makes updates for RFC 7315 in order to fix
+   misalignments that occurred when RFC 3455 was updated and obsoleted
+   by RFC 7315.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7976.
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al.              Informational                     [Page 1]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Misalignments and 3GPP Use Cases  . . . . . . . . . . . . . .   3
+     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  Misalignments . . . . . . . . . . . . . . . . . . . . . .   3
+     2.3.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . .   4
+       2.3.1.  General . . . . . . . . . . . . . . . . . . . . . . .   4
+       2.3.2.  P-Access-Network-Info . . . . . . . . . . . . . . . .   4
+       2.3.3.  P-Charging-Vector . . . . . . . . . . . . . . . . . .   5
+   3.  Updates to RFC 7315 . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   The Third Generation Partnership Project (3GPP) has identified cases
+   where different Session Initiation Protocol (SIP) [RFC3261] private
+   header extensions referred to as "P-" header fields, and defined in
+   [RFC7315], need to be included in SIP requests and responses
+   currently not allowed according to RFC 7315.  This document updates
+   RFC 7315, in order to allow inclusion of the affected "P-" header
+   fields in such requests and responses.
+
+   This document also makes updates for RFC 7315 in order to fix
+   misalignments that occurred when RFC 3455 [RFC3455] was updated and
+   obsoleted by RFC 7315.
+
+
+
+
+
+Holmberg, et al.              Informational                     [Page 2]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+   As the "P-" header fields are mainly used in (and in most cases, only
+   defined for) networks defined by the 3GPP, where the updates defined
+   in this document are already defined [TS.3GPP.24.229], the updates
+   are not seen to cause backward-compatibility concerns.
+
+2.  Misalignments and 3GPP Use Cases
+
+2.1.  General
+
+   RFC 7315 contains contradicting statements regarding the usage of SIP
+   "P-" header fields in SIP requests and responses, which leave the
+   presence of the SIP "P-" header fields in the SIP requests and
+   responses open to interpretation and different implementations.
+   Statements in Section 5.7 of that RFC are not aligned with the
+   definitions and usage of the SIP "P-" header fields specified in
+   Section 4.  This section describes the misalignments that occurred
+   when RFC 3455 was updated and obsoleted by RFC 7315, and how they are
+   fixed.
+
+   NOTE: In the case of the P-Called-Party-ID header field, allowing it
+   in PUBLISH requests was deliberately done in RFC 7315.  Therefore, it
+   is not considered a misalignment.
+
+   Since RFC 7315 was published, 3GPP defined new use cases that require
+   the RFC to be updated.  This section describes the 3GPP use cases
+   behind the updates, and the updates needed to RFC 7315 in order to
+   support the use cases.
+
+   Section 3 updates RFC 7315, based on the misalignments and 3GPP use
+   cases.
+
+2.2.  Misalignments
+
+   The following updates are needed in order to fix the misalignments
+   between RFCs 7315 and 3455:
+
+   o  P-Associated-URI: Remove the statement that the header field can
+      appear in the SIP REGISTER method.
+
+   o  P-Called-Party-ID: Delete the statement that the P-Called-Party-ID
+      header field can appear in SIP responses.  Add a statement that
+      the P-Called-Party-ID header field can appear in the SIP REFER
+      method.
+
+   o  P-Visited-Network-ID: Delete the statement that the P-Visited-
+      Network-ID header field can appear in SIP responses.  Add a
+      statement that the P-Visited-Network-ID header field cannot appear
+      in the SIP NOTIFY, PRACK, INFO, and UPDATE methods.
+
+
+
+Holmberg, et al.              Informational                     [Page 3]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+   o  P-Access-Network-Info: Add a statement that the P-Access-Network-
+      Info header field can appear in SIP responses.
+
+   o  P-Charging-Vector: Add a statement that the P-Charging-Vector
+      header field can appear in SIP responses.  Add a statement that
+      the P-Charging-Vector header field cannot appear in the SIP ACK
+      method.
+
+   o  P-Charging-Function-Addresses: Add a statement that the
+      P-Charging-Function-Addresses header field can appear in SIP
+      responses.
+
+2.3.  3GPP Use Cases
+
+2.3.1.  General
+
+   The following updates are needed in order to implement the 3GPP use
+   cases:
+
+   o  P-Access-Network-Info: Add statement that the P-Access-Network-
+      Info header field can appear in the SIP ACK method when triggered
+      by a SIP 2xx response.
+
+   o  P-Charging-Vector: Add statement that the P-Charging-Vector header
+      field can appear in the SIP ACK method when triggered by a SIP 2xx
+      response.
+
+   This following sections describe, for individual "P-" header fields,
+   the 3GPP use cases that are the basis for the updates.  The use cases
+   are based on the procedures defined in [TS.3GPP.24.229].
+
+2.3.2.  P-Access-Network-Info
+
+   The P-Access-Network-Info header field may contain the Network
+   Provided Location Information (NPLI).  The NPLI is described in
+   [TS.3GPP.23.228].
+
+   A proxy in possession of appropriate information about the access
+   technology might insert a P-Access-Network-Info header field with its
+   own values.  Such values are identified by the string "network-
+   provided" defined in RFC 7315.  Based on operator policy and/or
+   roaming agreement, the local time of the visited network may be
+   included.
+
+   The Call Data Records (CDRs) generated within the IP Multimedia
+   Subsystem (IMS) have to contain the NPLI in order to guarantee
+   correct billing.  When an IMS session is modified, the NPLI also
+   needs to be stored as the location of the user at the time when the
+
+
+
+Holmberg, et al.              Informational                     [Page 4]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+   session is modified may generate a charging event.  In case of a
+   session modification event at IMS, the NPLI needs to be provided:
+
+   o  when the bearer establishment is triggered, or
+
+   o  at session release when the bearer deactivation is triggered, or
+
+   o  when the bearer modification is triggered, e.g., a QoS
+      modification for the use of a newly negotiated codec.
+
+   In some scenarios, the bearer modification may be triggered by the
+   proxy upon reception of a Session Description Protocol (SDP) answer
+   within SIP 2xx response to the SIP INVITE request.  In such case, the
+   NPLI needs to be provided within the SIP ACK request.  However, RFC
+   7315 does not allow the usage of the P-Access-Network-Info header
+   field in SIP ACK request.
+
+   Upon reception of the SDP answer within SIP 2xx response on the SIP
+   INVITE request, a proxy may initiate procedures to obtain the NPLI
+   and may include the P-Access-Network-Info header field with the NPLI
+   in the SIP ACK request.
+
+   The P-Access-Network-Info header field shall not be included in SIP
+   ACK requests triggered by non-2xx responses.
+
+2.3.3.  P-Charging-Vector
+
+   RFC 7315 defines an Inter Operator Identifier (IOI) to enable
+   different operators involved in a SIP dialog or a transaction outside
+   a dialog to identify each other by exchanging operator identification
+   information within the P-Charging-Vector header field.
+
+   In the interconnection scenarios in multi-operator environments,
+   where one or more transit operators are between the originating and
+   terminating operator, the identities of the involved transit
+   operators are represented by a transit-ioi parameter of the
+   P-Charging-Vector header field.
+
+   Transit operators can be selected independently for each SIP method
+   and direction of request.  A transit network will only have knowledge
+   of an individual SIP request, and transit network selection will be
+   an independent decision for each request and could be made based on
+   load, cost, percentage, time of day, and other factors.  For this
+   reason, it is necessary that the P-Charging-Vector header field,
+   which carries the transit IOI information, is included in each SIP
+   request and response.  However, RFC 7315 does not allow the usage of
+   the P-Charging-Vector header field in the SIP ACK request.
+
+
+
+
+Holmberg, et al.              Informational                     [Page 5]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+   A SIP proxy that supports this extension and receives the SIP ACK
+   request may include a P-Charging-Vector header field in the SIP ACK
+   request.
+
+   The P-Charging-Vector header field shall not be included in SIP ACK
+   requests triggered by SIP non-2xx responses.
+
+3.  Updates to RFC 7315
+
+   This section implements the update to Section 5.7 of RFC 7315, in
+   order to implement the misalignment fixes and the 3GPP requirements
+   described in Section 2.
+
+   Old text:
+
+   The P-Associated-URI header field can appear in SIP REGISTER method
+   and 2xx resonses [sic].  The P-Called-Party-ID header field can
+   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
+   methods and all responses.  The P-Visited-Network-ID header field can
+   appear in all SIP methods except ACK, BYE, and CANCEL and all
+   responses.  The P-Access-Network-Info header field can appear in all
+   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
+   field can appear in all SIP methods except CANCEL.  The
+   P-Charging-Function-Addresses header field can appear in all SIP
+   methods except ACK and CANCEL.
+
+   New text:
+
+   The P-Associated-URI header field can appear in SIP REGISTER 2xx
+   responses.  The P-Called-Party-ID header field can appear in the SIP
+   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
+   P-Visited-Network-ID header field can appear in all SIP methods
+   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  The
+   P-Access-Network-Info header field can appear in all SIP methods and
+   non-100 responses, except in CANCEL methods, CANCEL responses, and
+   ACK methods triggered by non-2xx responses.  The P-Charging-Vector
+   header field can appear in all SIP methods and non-100 responses,
+   except in CANCEL methods, CANCEL responses, and ACK methods triggered
+   by non-2xx responses.  The P-Charging-Function-Addresses header field
+   can appear in all SIP methods and non-100 responses, except in CANCEL
+   methods, CANCEL responses, and ACK methods.
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al.              Informational                     [Page 6]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+4.  Security Considerations
+
+   The security considerations for these "P-" header fields are defined
+   in [RFC7315].  This specification allows some header fields to be
+   present in messages where they were previously not allowed, and the
+   security considerations and assumptions described in [RFC7315] (e.g.,
+   regarding only sending information to trusted entities) also apply to
+   those messages.  In addition, this specification also disallows some
+   header fields to be present in messages where they were previously
+   allowed.  That does not cause any security issues, but implementors
+   need to be aware that implementations may not have been updated
+   according to this document, and take proper actions if a header field
+   occurs, or does not occur, in a message where it should occur (or
+   occurs in a message where it should not occur).  This document adds
+   the ability to include P-Access-Network-Info in ACK requests.  As
+   documented in [RFC7315], P-Access-Network-Info may include privacy
+   sensitive information, including the user's location.  The security
+   and privacy considerations for P-Access-Network-Info in ACK requests
+   are similar to those for the other SIP requests discussed in
+   [RFC7315].
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC7315]  Jesske, R., Drage, K., and C. Holmberg, "Private Header
+              (P-Header) Extensions to the Session Initiation Protocol
+              (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July
+              2014, <http://www.rfc-editor.org/info/rfc7315>.
+
+   [TS.3GPP.23.228]
+              3GPP, "IP multimedia call control protocol based on
+              Session Initiation Protocol (SIP) and Session Description
+              Protocol (SDP); Stage 3", 3GPP TS 23.228 13.6.0, June
+              2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
+
+   [TS.3GPP.24.229]
+              3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
+              TS 24.229 13.6.0, June 2016,
+              <http://www.3gpp.org/ftp/Specs/html-info/24229.htm>.
+
+
+
+
+
+Holmberg, et al.              Informational                     [Page 7]
+
+RFC 7976                Updates to P-Header Usage         September 2016
+
+
+5.2.  Informative References
+
+   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
+              Header (P-Header) Extensions to the Session Initiation
+              Protocol (SIP) for the 3rd-Generation Partnership Project
+              (3GPP)", RFC 3455, DOI 10.17487/RFC3455, January 2003,
+              <http://www.rfc-editor.org/info/rfc3455>.
+
+Acknowledgments
+
+   Thanks to Paul Kyzivat, Jean Mahoney, Ben Campbell, and Adam Roach
+   for providing comments on the document.
+
+Authors' Addresses
+
+   Christer Holmberg
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   Email: christer.holmberg@ericsson.com
+
+
+   Nevenka Biondic
+   Ericsson
+   Krapinska 45
+   Zagreb  10002
+   Croatia
+
+   Email: nevenka.biondic@ericsson.com
+
+
+   Gonzalo Salgueiro
+   Cisco Systems, Inc.
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   United States of America
+
+   Email: gsalguei@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al.              Informational                     [Page 8]
+