rfc9366.original.xml   rfc9366.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 (Ruby 3.0.
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 3.1. 2) -->
2) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9366"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft docName="draft-ietf-sipcore-multiple-reasons-01" category="std" consensus="true"
-ietf-sipcore-multiple-reasons-01" category="std" consensus="true" submissionTyp submissionType="IETF" updates="3326" xml:lang="en" tocInclude="true" sortRefs="
e="IETF" updates="3326" tocInclude="true" sortRefs="true" symRefs="true" version true" symRefs="true" version="3">
="3"> <!-- xml2rfc v2v3 conversion 3.16.0 -->
<!-- xml2rfc v2v3 conversion 3.14.0 -->
<front> <front>
<title abbrev="Multiple reasons">Multiple SIP Reason Header Field Values</ti <title abbrev="Multiple SIP Reason Header Field Values">Multiple SIP Reason
tle> Header Field Values</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-sipcore-multiple-reasons <seriesInfo name="RFC" value="9366" />
-01"/>
<author initials="R." surname="Sparks" fullname="Robert Sparks"> <author initials="R." surname="Sparks" fullname="Robert Sparks">
<organization/> <organization/>
<address> <address>
<email>rjsparks@nostrum.com</email> <email>rjsparks@nostrum.com</email>
</address> </address>
</author> </author>
<date year="2022" month="August" day="23"/> <date year="2023" month="March"/>
<area>ART</area> <area>ART</area>
<workgroup>SIPCORE Working Group</workgroup> <workgroup>SIPCORE</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>The SIP Reason Header Field as defined in RFC 3326 allows only one Reas on value per protocol value. Experience with more recently defined protocols sho ws it is useful to allow multiple values with the same protocol value. This upda te to RFC 3326 allows multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means.</t> <t>The SIP Reason header field as defined in RFC 3326 allows only one Reas on value per protocol value. Experience with more recently defined protocols sho ws it is useful to allow multiple values with the same protocol value. This docu ment updates RFC 3326 to allow multiple values for an indicated registered proto col when that protocol defines what the presence of multiple values means.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The SIP Reason Header Field as defined in RFC 3326 allows only one Reas on value per protocol value. Experience with more recently defined protocols sho ws it is useful to allow multiple values with the same protocol value <xref targ et="STIRREASONS"/>. This update to RFC 3326 allows multiple values for an indica ted registered protocol when that protocol defines what the presence of multiple values means. It does not change the requirement in RFC 3326 restricting the he ader field contents to one value per protocol for those protocols that do not de fine what multiple values mean.</t> <t>The SIP Reason header field as defined in RFC 3326 allows only one Reas on value per protocol value. Experience with more recently defined protocols sho ws it is useful to allow multiple values with the same protocol value <xref targ et="I-D.ietf-stir-identity-header-errors-handling"/>. This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that pro tocol 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> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions">
<name>Conventions and Definitions</name> <name>Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="update-to-rfc3326"> <section anchor="update-to-rfc-3326">
<name>Update to RFC3326</name> <name>Update to RFC 3326</name>
<t>The last paragraph of section 2 of <xref target="RFC3326"/> is replaced <t>The last paragraph of <xref section="2" sectionFormat="of" target="RFC3
as follows:</t> 326"/> is replaced as follows:</t>
<t>OLD:</t> <t>OLD:</t>
<blockquote>
<t>A SIP message <bcp14>MAY</bcp14> contain more than one Reason value (i. e., multiple <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 va lues Reason lines), but all of them <bcp14>MUST</bcp14> have different protocol va lues
(e.g., one SIP and another Q.850). An implementation is free to (e.g., one SIP and another Q.850). An implementation is free to
ignore Reason values that it does not understand.</t> ignore Reason values that it does not understand.</t>
</blockquote>
<t>NEW:</t> <t>NEW:</t>
<blockquote>
<t>A SIP message <bcp14>MAY</bcp14> contain more than one Reason value (i. e., multiple <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 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 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 <bcp1 4>MUST</bcp14> be only value for that protocol <bcp14>MAY</bcp14> be present. Otherwise, there <bcp1 4>MUST</bcp14> be only
one value per protocol provided (e.g., one SIP and another Q.850). An 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> implementation is free to ignore Reason values that it does not understand.</ t>
</section> </blockquote>
</section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document adds no security considerations to the use of SIP. The se curity considerations in <xref target="RFC3326"/> and those in any registered pr otocols used in Reason header field values should be considered.</t> <t>This document adds no security considerations to the use of SIP. The se curity considerations in <xref target="RFC3326"/> and those in any registered pr otocols used in Reason header field values should be considered.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-stir-identity-header-errors-handling" to="STI RREASONS"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC3326"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<front> C.3326.xml"/>
<title>The Reason Header Field for the Session Initiation Protocol ( <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
SIP)</title> C.2119.xml"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
"> C.8174.xml"/>
<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 Identifi
er (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally d
ynamic 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 d
oes not give us a mechanism to discover and record this sequence of proxies in t
he 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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="STIRREASONS"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-st
<front> ir-identity-header-errors-handling.xml"/>
<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 Ma
nagement
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-head
er-errors-handling-03"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgments"> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This text is based on discussions at a STIR working group interim meeti <t>This text is based on discussions at a STIR Working Group interim meeti
ng. Jean Mahoney and Russ Housley provided suggestions that vastly improved the ng. <contact fullname="Jean Mahoney"/> and <contact fullname="Russ Housley"/> pr
first attempts at assembling these words. Christer Holmberg, Dale Worley, Brian ovided suggestions that vastly improved the first attempts at assembling these w
Rosen, Chris Wendt, and Paul Kyzivat provided constructive discussion during SI ords. <contact fullname="Christer Holmberg"/>, <contact fullname="Dale Worley"/>
PCORE working group adoption.</t> , <contact fullname="Brian Rosen"/>, <contact fullname="Chris Wendt"/>, and <con
</section> tact fullname="Paul Kyzivat"/> provided constructive discussion during SIPCORE W
<section anchor="changelog"> orking Group adoption.</t>
<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="ST
IRREASONS"/></li>
</ul>
</section>
</section> </section>
</back> </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> </rfc>
 End of changes. 18 change blocks. 
193 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48.