RFC 9366

Multiple SIP Reason Header Field Values

📅 published March 2023, from ietf

RFC 9366: Multiple SIP Reason Header Field Values 🎀

Okay bestie, here's the quick facts before we dive in 💖

  • Internet Engineering Task Force (IETF), Request for Comments: 9366 ✨
  • Author: R. Sparks (Robert Sparks) 🫶
  • Date: March 2023 🌸
  • Category: Standards Track 👑
  • Updates: 3326 (aka RFC 3326) 🦋
  • ISSN: 2070-1721 💅

Abstract ✨

Okay so the SIP Reason header field from RFC 3326 only lets you have ONE Reason value per protocol value 😭 Like, one per protocol, period. But newer protocols have shown it's actually useful to allow multiple values with the same protocol value. So this doc updates RFC 3326 to allow multiple values for a registered protocol, but only when that protocol defines what having multiple values even means 🧚

Status of This Memo 📜

This is an Internet Standards Track document, so it's official-official 🔥

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 💜

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9366 🍓

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) as in effect on the date of publication. Please review these carefully, because they spell out your rights and restrictions for this document 🙈 Also, any Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 ✨

Okay so the SIP Reason header field from RFC 3326 only allows one Reason value per protocol value. Newer protocols have shown it's useful to allow multiple values with the same protocol value [STIRREASONS] 🦋 This document updates RFC 3326 so multiple values are allowed for an indicated registered protocol, but only when that protocol defines what the presence of multiple values means 💅

It does NOT change the RFC 3326 requirement that restricts header field contents to one value per protocol for protocols that don't define what multiple values mean. That rule stays put, bestie 🫶

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. This is the whole vibe check for the keywords 🔥

3. Update to RFC 3326 🦋

This part is the main event 👑 The last paragraph of Section 2 of [RFC3326] gets replaced with the text below. Here's the OLD version and the NEW version:

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 🔥

Okay, this one's serious, so listen up 😭 This document adds no security considerations to the use of SIP. However, the security considerations in [RFC3326] AND the ones in any registered protocols used in Reason header field values should be considered. Don't skip them, periodt 💀

5. IANA Considerations 🌸

This document has no IANA actions. Nothing to register here, bestie 🍓

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 gave suggestions that vastly improved the first attempts at putting these words together, no cap 😭 Christer Holmberg, Dale Worley, Brian Rosen, Chris Wendt, and Paul Kyzivat also gave constructive discussion during SIPCORE Working Group adoption. Iconic group of people 👑

Author's Address 💜

Robert Sparks
Email: rjsparks@nostrum.com
📦 where this page comes from