<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- generated by https://github.com/cabo/kramdown-rfc version1.6.161.6.22 (Ruby3.1.2)3.0.2) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9366" docName="draft-ietf-sipcore-multiple-reasons-01" category="std" consensus="true" submissionType="IETF" updates="3326" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion3.14.03.16.0 --> <front> <title abbrev="Multiplereasons">MultipleSIP Reason Header Field Values">Multiple SIP Reason Header Field Values</title> <seriesInfoname="Internet-Draft" value="draft-ietf-sipcore-multiple-reasons-01"/>name="RFC" value="9366" /> <author initials="R." surname="Sparks" fullname="Robert Sparks"> <organization/> <address> <email>rjsparks@nostrum.com</email> </address> </author> <dateyear="2022" month="August" day="23"/>year="2023" month="March"/> <area>ART</area><workgroup>SIPCORE Working Group</workgroup> <keyword>Internet-Draft</keyword><workgroup>SIPCORE</workgroup> <abstract> <t>The SIP ReasonHeader Fieldheader 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. Thisupdate todocument updates RFC 3326allowsto allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.</t> </abstract> </front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>The SIP ReasonHeader Fieldheader 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 <xreftarget="STIRREASONS"/>.target="I-D.ietf-stir-identity-header-errors-handling"/>. Thisupdate todocument updates RFC 3326allowsto 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.</t> </section> <sectionanchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>Theanchor="conventions"> <name>Conventions</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectionanchor="update-to-rfc3326">anchor="update-to-rfc-3326"> <name>Update toRFC3326</name>RFC 3326</name> <t>The last paragraph ofsection 2 of<xref section="2" sectionFormat="of" target="RFC3326"/> is replaced as follows:</t> <t>OLD:</t> <blockquote> <t>A SIP message <bcp14>MAY</bcp14> contain more than one Reason value (i.e., multiple Reason lines), but all of them <bcp14>MUST</bcp14> 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.</t> </blockquote> <t>NEW:</t> <blockquote> <t>A SIP message <bcp14>MAY</bcp14> 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 <bcp14>MAY</bcp14> be present. Otherwise, there <bcp14>MUST</bcp14> 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.</t> </blockquote> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document adds no security considerations to the use of SIP. The security considerations in <xref target="RFC3326"/> and those in any registered protocols used in Reason header field values should be considered.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-stir-identity-header-errors-handling" to="STIRREASONS"/> <references> <name>References</name> <references> <name>Normative References</name><reference anchor="RFC3326"> <front> <title>The Reason Header Field for the Session Initiation Protocol (SIP)</title> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"> <organization/> </author> <author fullname="D. Oran" initials="D." surname="Oran"> <organization/> </author> <author fullname="G. Camarillo" initials="G." surname="Camarillo"> <organization/> </author> <date month="December" year="2002"/> <abstract> <t>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3326"/> <seriesInfo name="DOI" value="10.17487/RFC3326"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"> <organization/> </author> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"> <organization/> </author> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references> <name>Informative References</name><reference anchor="STIRREASONS"> <front> <title>Identity Header Errors Handling</title> <author fullname="Chris Wendt"> <organization>Somos</organization> </author> <date day="19" month="August" year="2022"/> <abstract> <t> This document extends STIR and the Authenticated Identity Management in the Session Initiation Protocol (SIP) error handling procedures to include the mapping of verification failure reasons to STIR defined 4xx codes so the failure reason of an Identity header field can be conveyed to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure. This document also defines procedures that enable enable a failure reason to be mapped to a specific Identity header for scenarios that use multiple Identity header fields where some may have errors and others may not and the handling of those situations is defined. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-stir-identity-header-errors-handling-03"/> </reference><xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-stir-identity-header-errors-handling.xml"/> </references> </references> <sectionanchor="acknowledgments">anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>This text is based on discussions at a STIRworking groupWorking Group interim meeting.Jean Mahoney and Russ Housley<contact fullname="Jean Mahoney"/> and <contact fullname="Russ Housley"/> provided suggestions that vastly improved the first attempts at assembling these words.Christer Holmberg, Dale Worley, Brian Rosen, Chris Wendt,<contact fullname="Christer Holmberg"/>, <contact fullname="Dale Worley"/>, <contact fullname="Brian Rosen"/>, <contact fullname="Chris Wendt"/>, andPaul Kyzivat<contact fullname="Paul Kyzivat"/> provided constructive discussion during SIPCOREworking groupWorking Group adoption.</t> </section><section anchor="changelog"> <name>Changelog</name> <t>(This section to be removed by the RFC editor.)</t> <section anchor="changelog-00"> <name>00</name> <ul spacing="normal"> <li>rename draft-sparks to draft-ietf. Add changelog.</li> </ul> </section> <section anchor="changelog-01"> <name>01</name> <ul spacing="normal"> <li>expand a little on "Practice shows", referring to <xref target="STIRREASONS"/></li> </ul> </section> </section></back><!-- ##markdown-source: H4sIAAAAAAAAA91X224bNxB936+YKi9J4RUkN20ToS2qWE7t1rYcyWkQBEFA LSmJ9S65IblyFMP/0m/pl/UMKdmSL2hRoEDRPDhLajicOTNzZpjneRZ0KFWP WsdNGXRdKhofntJICW8NHSghlaOXWpWSfhVlo3wrE5OJU4vNEy5K4ydpCyMq aJNOTEOuVZjmXteFdSqvVtL5SjrvdLNCBDWzbtkjH2TW1BJr36Ovvtr9Jst0 7XoUXOPDbqfzvLObCZzsUX90ll1Ydz5ztql7bO3ecLRPb7ClzYx+4u3MB8hW PTrcP3uZnaslDkisTFDOqJAP2LwMUsLID6K0BiYvlc98JVz48LGx0Qxjs1r3 6F2wxQ5566Bz6vG1rPjjfZaJJsyt62WUZ4R/yfWRnSgXaFwLd+7jvnUzYfRn EbQ1vbijKqHLHrnffJT60VgY3FTtwlZZZqyrILtQLDt6ucdo9NYfgMVMNwXG Z4ej0X5/PDwZw8F80E6gB+1yLZVBdJf5PIYxV85Z5/M5nC4BVZbleU5igqtF ATTO5g/HXniSaqqNkqQN2xJjRKIs7YUna8ol/qj10QVnCtU4XTsL9GyZttq0 /wm7WplC0YUOc6qQGUifAoZCxfqK9SlPfs76dSDtqfFq2pQUbLqW1gmVdPuk MMAJjzjcuflszipihrGK2y7cVgaMSRg4KzUnqYSRM+2RPhvm0cVcGdwows1W cgHG8C4bUzvlo792eueSSgnj2ykOlZayVFn2iLPUWdkUnC7/76jQ5eVG+l5d /ZejRIeBpMXS2EAFamim4kmnPjbaqQpYbQUBCoPTCCI4ieVSDdI0Bq6wYCIT PPvIEbonNOwa2MWrDdyjE9JGE5ILyYP7LG5zKu1Zs2AOAN0CJ0kDPqTjOmUW qJGYGz3Y/PX4rLWT/qeTYfwe7b96fTjaH/D3+KB/dHT9ka0kxgfD10eDm6+b k3vD4+P9k0E6jF3a2spax/23+IWtag1Pzw6HJ/2jFiMYOAXQSJoIKTifQZoo /IS4Ik4cZuEzqXzh9CSl/ou90z9+7z5FPn2BAOx2u8+vrlaLZ91vn2LBSZBu i2WRlojLMhN1rYRjLUgyKkStgyhB8yLluUHknAKaX75jZN736LtJUXef/rDa YIe3NteYbW1GzO7u3DmcQLxn655rrtHc2r+F9La9/bdb6zXuG5ucNa836y81 Hc6VUniUkHBi5kQ950rxKpIU7fLi8nIlDbQRQafqUhQxVsjlWL69LBseDfAX HbAfSa1S3gsUEgyLNSEQhUg+yHRzl7se67Zq71ynO+tZ/V5yOT/ZoUkTYhhh D4JbUYzQXCwUST2dIpAm3OKg2KIfq/YMivlCNovTRKDIEHl61X72dedJGxaD ZyrcymkZWzl7OXWKgWIdembY8k2DVxWrN5ijMWCBOHcgpU723/yLaICypiuK ukuKiV5uafS1KjQYKmJysTI90l+Uv00zTF5F0cTaYetW9u9sG826kvp05yYP s6eTNfuGNg0Z8gvtVaxNKInxgwQXLSt6gCzxscC0I/9mIGO4HorlPwnkIxor AIFZiynXwxQnrll2i86k5ONcOUm82BLn6zkqaKqcwnCBW6J6UBzAb5Ydu5t6 BrOZWd4X+dix07yQHNxqTCtvQXwNVgB+faFKbh72T/p/4eJcRA+jpIj8wCNO nHEmojhnLf3i3NiLUskZn/BJQVCf4kAxEWwfDJPaF433qXkBujjqcreKc34c /1NT0BVST3GnbdPPyFY6FnNkwDLiMYIKOrCNL7FxnSe+mc3QoBPmHNoFyA19 AVkBESVjFKYaAcbVQVV1SDZ4r6pJuerpwDn2zjbtzV3EGReVFcb/2Q4NBAoF jxJcu0MvnIZZI0QGXSdJ0xtlZEgt6VRggvpl+VkvUnEkGxl6vAoKnvQ3wCCJ VIAB64fPNiBC2prdSu0/jimlnWWXPWEKvFW+bxXrvdZV9jgCv2bx1GYxykQA JsvED5hnlNTBuvYTqHxEnc59yvJOB/pynOZH0Or5lx43rPfmOdimvpR0fa6d dHbv19mNOtWnOtYxaC3gqcqp0TrlJ4vGvBZHUcwReJHheRMDY2+PldmfyA2l a+cOAAA= --></rfc>