doc: Add RFC documents

1 files changed, 156 insertions, 0 deletions

diff --git a/doc/rfc/rfc9366.txt b/doc/rfc/rfc9366.txt
new file mode 100644
index 0000000..252f4a1
--- /dev/null
+++ b/doc/rfc/rfc9366.txt
@@ -0,0 +1,156 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Sparks
+Request for Comments: 9366                                    March 2023
+Updates: 3326                                                           
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+                Multiple SIP Reason Header Field Values
+
+Abstract
+
+   The SIP Reason header field as defined in RFC 3326 allows only one
+   Reason value per protocol value.  Experience with more recently
+   defined protocols shows it is useful to allow multiple values with
+   the same protocol value.  This document updates RFC 3326 to allow
+   multiple values for an indicated registered protocol when that
+   protocol defines what the presence of multiple values means.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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
+   https://www.rfc-editor.org/info/rfc9366.
+
+Copyright Notice
+
+   Copyright (c) 2023 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
+   (https://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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions
+   3.  Update to RFC 3326
+   4.  Security Considerations
+   5.  IANA Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   The SIP Reason header field as defined in RFC 3326 allows only one
+   Reason value per protocol value.  Experience with more recently
+   defined protocols shows it is useful to allow multiple values with
+   the same protocol value [STIRREASONS].  This document updates RFC
+   3326 to allow multiple values for an indicated registered protocol
+   when that protocol defines what the presence of multiple values
+   means.  It does not change the requirement in RFC 3326 restricting
+   the header field contents to one value per protocol for those
+   protocols that do not define what multiple values mean.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Update to RFC 3326
+
+   The last paragraph of Section 2 of [RFC3326] is replaced as follows:
+
+   OLD:
+
+   |  A SIP message MAY contain more than one Reason value (i.e.,
+   |  multiple Reason lines), but all of them MUST have different
+   |  protocol values (e.g., one SIP and another Q.850).  An
+   |  implementation is free to ignore Reason values that it does not
+   |  understand.
+
+   NEW:
+
+   |  A SIP message MAY contain more than one Reason value (i.e.,
+   |  multiple Reason lines).  If the registered protocol for the Reason
+   |  value specifies what it means for multiple values to occur in one
+   |  message, more than one value for that protocol MAY be present.
+   |  Otherwise, there MUST be only one value per protocol provided
+   |  (e.g., one SIP and another Q.850).  An implementation is free to
+   |  ignore Reason values that it does not understand.
+
+4.  Security Considerations
+
+   This document adds no security considerations to the use of SIP.  The
+   security considerations in [RFC3326] and those in any registered
+   protocols used in Reason header field values should be considered.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
+              Header Field for the Session Initiation Protocol (SIP)",
+              RFC 3326, DOI 10.17487/RFC3326, December 2002,
+              <https://www.rfc-editor.org/info/rfc3326>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+6.2.  Informative References
+
+   [STIRREASONS]
+              Wendt, C., "Identity Header Errors Handling for STIR",
+              Work in Progress, Internet-Draft, draft-ietf-stir-
+              identity-header-errors-handling-08, 25 February 2023,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
+              identity-header-errors-handling-08>.
+
+Acknowledgments
+
+   This text is based on discussions at a STIR Working Group interim
+   meeting.  Jean Mahoney and Russ Housley provided suggestions that
+   vastly improved the first attempts at assembling these words.
+   Christer Holmberg, Dale Worley, Brian Rosen, Chris Wendt, and Paul
+   Kyzivat provided constructive discussion during SIPCORE Working Group
+   adoption.
+
+Author's Address
+
+   Robert Sparks
+   Email: rjsparks@nostrum.com