diff options
Diffstat (limited to 'doc/rfc/rfc9366.txt')
| -rw-r--r-- | doc/rfc/rfc9366.txt | 156 |
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 |