<?xmlversion="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.22 (Ruby 3.4.1) -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-sipcore-callinfo-rcd-19" number="9796" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true"symRefs="true">symRefs="true" version="3" xml:lang="en"> <front> <title abbrev="Call-Info Rich Call Data">SIP Call-Info Parameters for Rich Call Data</title> <seriesInfo name="RFC" value="9796"/> <author initials="C." surname="Wendt" fullname="Chris Wendt"> <organization>Somos</organization> <address> <postal><country>US</country><country>United States of America</country> </postal> <email>chris@appliedbits.com</email> </address> </author> <author initials="J." surname="Peterson" fullname="Jon Peterson"> <organization>TransUnion</organization> <address> <postal><country>US</country><country>United States of America</country> </postal> <email>Jon.Peterson@transunion.com</email> </address> </author> <date year="2025"month="April" day="21"/> <area>art</area>month="May"/> <area>ART</area> <workgroup>sipcore</workgroup> <keyword>Identity</keyword> <abstract><?line 75?><t>This document specifies a usage of the SIP Call-Info header field that incorporates Rich Call Data (RCD) associated with the identity of the originating party in order to provide to the terminating party a description of the caller (including details about the reason for the session). RCD includes information about the caller beyond the telephone numbersuch(such as a calling name,alogo, photo, or jCard object representing thecaller,caller), which can help the called party decide how to handle the session request.</t> <t>This document defines three new parameters 'call-reason', 'verified', and 'integrity' for the SIP Call-Info header field and also a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. It also provides guidance on the use of the Call-Info 'purpose' parameter token, "icon".</t> </abstract> </front> <middle> <?line 81?> <sectionanchor="introduction"><name>Introduction</name>anchor="introduction"> <name>Introduction</name> <t>Signaling protocols in telephone networks have long supported the delivery of a 'calling name' from the originating side to the terminatingside, thoughside; however, in practice, the terminating side is often left to derive a name from the calling-party number by consulting a local address book or an external database. SIP <xref target="RFC3261"/> similarly can carry a 'display-name' in the From header field value from the originating to terminating side, though it is a field that is not commonly trusted and is often replaced or ignored. The same can be considered true of information in the Call-Info header field in SIP.</t> <!-- [rfced] Is "For this document" needed? Original: For this document and depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. Perhaps: Depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. Alternatively, perhaps: As defined in this document, depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. --> <t>This document defines usage of the SIP Call-Info header field <xref target="RFC3261"/>allowingthat allows called parties to receive a more comprehensive and extensible set of Rich Call Data (RCD) for incoming calls. Itspecificallydefines specific usage of the Call-Info header field, a new parameter('call-reason')('call-reason'), and a new token ("jcard") for the 'purpose' parameter of the Call-Info header field. For this document and depending on the policies of the communications system, a calling party could be either the end user device (e.g., a SIP user agent (UA)) or a network service as part of a telephone service provider. Similarly, a called party could be an end user device or the network telephone service provider acting on behalf of the recipient of the call.</t> <t>In order to properly protect and communicate some of the authenticated and trusted properties of'rcd'"rcd" claims defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>,target="RFC9795"/>, this document defines two additional new parameters, 'verified' and 'integrity'. These parameters help protect RCD information that had been sent via a SIP network to, for example, a SIP entity on the edge of the network-to-network interface (NNI) that contains a verification service as defined in <xref target="RFC8224"/> and further defined specific to RCD information in <xreftarget="I-D.ietf-stir-passport-rcd"/>.target="RFC9795"/>. The verification procedures include the successful verification of the "rcd" claims and can be correspondingly represented in the Call-Info header field via these new parameters.</t> <t>Used on its own, this specification assumes that the called party UA can trust the SIP network to assign, deliver, and protect the correct RCD information as an end-to-end security policy. However, as is true in many interconnected communications services, this end-to-end trust cannot be guaranteed. Therefore, the recommended approach is that the entity inserting the Call-Info header field should also sign the caller information viaSTIR-definedprotocol tools defined by Secure Telephone Identity Revisited (STIR) <xref target="RFC7340"/> for SIP <xref target="RFC8224"/> and specifically through the use of RCD or the "rcd" PASSporT defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>.</t>target="RFC9795"/>.</t> <!-- [rfced] FYI - We have added expansions for abbreviations upon first use per the RFC Style Guide (see https://www.rfc-editor.org/rfc/rfc7322.html#section-3.6). Please review each expansion in the document carefully to ensure correctness. UNI -> User-Network Interface (UNI) STIR -> Secure Telephone Identity Revisited (STIR) --> <t>Alternatively, this specification can be utilized in conjunction with the protocols defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/> as part of the communications signaling path, specifically in the trustedUNIUser-Network Interface (UNI) device interface at the terminating side as part of an authenticated, network-to-device, trusted signaling where a device may not have the ability to verify the "rcd" PASSporT, but it can receive the RCD information from the Call-Info header field as defined in this specification.</t> <t>This specification provides an approach for the delivery of jCard data that utilizes the same mechanism as <xref target="RFC7852"/> which defined a means of carrying additional data about callers for the purposes of emergency services (especially Section <xref target="RFC7852" section="4.4" sectionFormat="bare">Owner/Subscriber Information</xref> of <xref target="RFC7852"/>). This document defines a 'purpose' parameter value 'jcard' for the more generic delivery of information via jCard <xref target="RFC7095"/>. This document borrows from <xref target="RFC7852"/> the capability to carry a data structure as a body, through the use of the "cid" URI scheme <xref target="RFC2392"/>.</t> </section> <sectionanchor="terminology"><name>Terminology</name> <t>Theanchor="terminology"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<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="overview"><name>Overview</name>anchor="overview"> <name>Overview</name> <t>This document provides a framework for the use of Call-Info header field to carry RCD in SIP <xref target="RFC3261"/>. The Call-Info header field (defined in <xref section="20.9" sectionFormat="comma" target="RFC3261"/>) defines a 'purpose' parameter. In addition to providing guidance on calling name practices and the use of the existing 'purpose' parameter token, "icon", this document expands on other types of RCD by defining a new 'purpose' token, "jcard", and three new parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info header field to align with RCD as defined in the STIR framework <xref target="RFC8224"/> and with "rcd" PASSporTs defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>.</t>target="RFC9795"/>.</t> <t>The 'purpose' parameter token "jcard" is used to associate RCD related to the identity of the calling party in the form of a jCard <xref target="RFC7095"/>. While there is a "card" token defined in <xref target="RFC3261"/> which could be considered to have an overlapping purpose, the "jcard" token is intended to denote the jCard profile defined in this document for use in the Call-Info header field for RCD. The choice of jCard in this specification is guided by two aspects. jCard represents an extensible method of providing information about a person or business associated with acall andcall, has been defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/>, and has been adopted by PASSporT <xref target="RFC8225"/> because of the usage of JSON Web Tokens (JWT) <xref target="RFC7519"/>.</t> <t>The new Call-Info header field parameter 'call-reason' conveys the caller's intent or reason for calling to help the called party understand the context and intent of the call and why they may want to answer the call.</t> <t>The new Call-Info header field parameter 'verified' provides an indication, with the value "true", to represent the results of the verification procedures that were performed by the sender of the Call-Info header field. The new Call-Info header field parameter 'integrity' provides a mechanism to associate an integrity hash string, as defined inSection 8.2 of<xreftarget="I-D.ietf-stir-passport-rcd"/>,section="8.2" target="RFC9795"/>, that is associated with the content of the resource referenced by the URI represented in the Call-Info header field.</t> </section> <sectionanchor="a-call-info-framework-for-carrying-rich-call-data"><name>Aanchor="a-call-info-framework-for-carrying-rich-call-data"> <name>A Call-Info Framework for Carrying Rich Call Data</name> <t>This specification extends the Call-Info header field to be compatible and complementary to the RCD framework defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>.target="RFC9795"/>. Typically, a SIP-based session involves multiple hops through different trusted and untrusted networks. The STIR framework <xref target="RFC7340"/> addresses the protection of the carriage of call information and identities over untrusted networks, which wasn't addressed in the core SIP specifications. <xref section="20.9" sectionFormat="comma" target="RFC3261"/> defines the Call-Info header field as the mechanism for carrying call- and caller-related information and also provides procedures for defining new 'purpose' parameter tokens. This document discusses the use of existing tokens and defines a new 'purpose' token to correspond to the RCD framework.</t> <!-- [rfced] Are logo and icons an example of calling name info? Original: The STIR RCD specification [I-D.ietf-stir-passport-rcd] defines calling name, a logo or icon associated with the caller, and a call reason string. Perhaps: The STIR RCD specification [RFC9795] defines calling name (e.g., a logo or icon associated with the caller) and a call reason string. --> <t>There are a number of RCD information types that can be transmitted in the Call-Info header field of a SIP request. The STIR RCD specification <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/> defines calling name, a logo or icon associated with the caller, and a call reason string. It also discusses an extensible wayof carryingto carry caller information using jCard <xref target="RFC7095"/>.</t> <!-- [rfced] For readability, please consider the possible update below. Also, is the information not to be "considered" modifiable, or should it be not modifiable? Original: The insertion of the RCD Call-Info header field should be considered a trusted action based on trusted information, and the information MUST NOT be considered modifiable representing the best practice of determining the final representation of the caller RCD to the user. Perhaps: The best way to determine the final representation of the caller RCD to the user is to consider the insertion of the RCD Call-Info header field a trusted action based on trusted information, whereby the information MUST NOT be considered modifiable. --> <t>The RCD framework defined both in this document as well as in <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/> carries call-specific information. The insertion of RCD is intended to be singular in that the receiving party should not be required to make any call-specific decisions based on redundant, duplicate, or conflicting RCD. The RCD information is either intended to be added by a party that is authoritative over that information or to have been translated from a verified STIR RCD PASSporT and unmodified once in a trusted domain. Any additional parties involved in the call pathMUST NOT<bcp14>MUST NOT</bcp14> modify the Call-Info header field or add additional Call-Info header fields related to RCD. The insertion of the RCD Call-Info header field should be considered a trusted action based on trusted information, and the informationMUST NOT<bcp14>MUST NOT</bcp14> be considered modifiable representing the best practice of determining the final representation of the caller RCD to the user. This specification acknowledges that without the use ofstirSTIR or other mechanisms, detection of any modifications is not possible, sothusguidance for the use of this specification in a trusted UNI part of the network is important.</t> <!-- [rfced] It's unclear which section this sentence is referring to, as this document does not have a Section 8.2. Perhaps Section 10.2 is intended? Current: Section 8.2 provides high-level guidance on image formatting and related information. --> <t>As discussed in <xreftarget="I-D.ietf-stir-passport-rcd"/>,target="RFC9795"/>, the calling name uses the display-name value of the From header field <xref target="RFC3261"/> of the request. Alternatively, for some calls, the calling name may come from the P-Asserted-ID header field <xref target="RFC3325"/>. While this is out of scope for the Call-Info header field in terms of the representation of the display-name value, this document does discuss the representation of the verification of this value using the 'verified' parameter.</t> <t>For logos or icons that can represent the calling party, the 'purpose' token "icon" <xref target="RFC3261"/> is used to indicate a URI for an image resource that can be displayed to the user receiving the SIP request. For the purpose of this document and the transmission of RCD, the "icon" 'purpose' token should be used as defined. Section 8.2 provides high-level guidance on image formatting and related information.</t> <t>This document defines 'call-reason' as a new parameter for the Call-Info header field. This parameter carries a string indicating the reason for the call.</t> <t>jCard is a comprehensive and extensible mechanism utilized as part of the STIR RCD framework. While <xref target="RFC3261"/> specifies a "card" 'purpose' token, the intent of defining a new "jcard" 'purpose' token is to use the JSON jCard format <xref target="RFC7095"/> and to provide guidance for the use and non-use of jCard attributes to describe the calling party in a communications session as well to provide some security considerations around that information. These topics are covered in the next sections.</t> </section> <sectionanchor="jcard-call-info-purpose-token"><name>"jcard"anchor="jcard-call-info-purpose-token"> <name>"jcard" Call-Info 'purpose' Token</name> <t>The Call-Info 'purpose' token "jcard" indicates support of RCD associated with the identity of a calling party in a SIP call <xref section="20.9" sectionFormat="comma" target="RFC3261"/>. The format of a Call-Info header field when using the "jcard" token is as follows.</t> <t>The Call-Info header field is defined to include a URI that points to a resource that is a jCard JSON object <xref target="RFC7095"/>. The media type for the JSON textMUST<bcp14>MUST</bcp14> be set as application/json with an encoding of UTF-8 <xref target="RFC8259"/>. ThisMAY<bcp14>MAY</bcp14> be carried directly in the Call-Info header field URI using the "data" URI scheme. A jCard alsoMAY<bcp14>MAY</bcp14> be carried in the body of the SIP request bearing this Call-Info header field via the "cid" URI scheme <xref target="RFC2392"/>. Alternatively, the Call-Info header field URIMUST<bcp14>MUST</bcp14> use a transport that can validate the integrity of the source of the resource(e.g(e.g., HTTPS tied to a specific validated domain). If, in the specific deployment environment of SIP, the source or integrity of the RCD information cannot be trusted, then the use of the STIR RCD framework defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/> should be considered.</t> <t>Because the use and purpose of this specification is to provide a single presentation of rich call data information, a call and its corresponding single RCD-related Call-Info header fieldMUST<bcp14>MUST</bcp14> only contain a single jCard object represented by an array with two elements. The arrayMUST<bcp14>MUST</bcp14> only include a single first element with the string "vcard", and the second element is an array of jCard properties corresponding to the single entity jCard object.</t><t>The<!-- [rfced] We are having trouble parsing this sentence. a) Are "fn", "photo", and "logo" fields AND properties, or should the text refer to the properties (e.g., 'If "fn", "photo", or "logo" are used...')? b) What MUST match? c) Should single quotes be used as follows, as it appears token names usually appear in single quote? purpose token -> 'purpose' token Original: The fields like "fn", "photo", or "logo" if used with the use of "icon" or calling name in From or P-Asserted-ID header field or purpose token, as described in the previous section, MUST match if present to allow the called party to clearly determine the intended calling name or icon. --> <t>The fields like "fn", "photo", or "logo" if used with the use of "icon" or calling name in From or P-Asserted-ID header field or purpose token, as described in the previous section, <bcp14>MUST</bcp14> match if present to allow the called party to clearly determine the intended calling name or icon.</t> <t>An example of a Call-Info header field is:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Call-Info: <https://example.com/qbranch.json>;purpose=jcard]]></artwork></figure>]]></artwork> <t>An example of the contents of a URL-linked jCard JSON file is shown as follows:</t><figure><artwork><![CDATA[<artwork><![CDATA[ ["vcard", [ ["version",{},"text","4.0"], ["fn",{},"text","Q Branch"], ["org",{},"text","MI6;Q Branch Spy Gadgets"], ["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] ] ]]]></artwork></figure>]]></artwork> <t>An example SIP INVITE using the "data" URI scheme is as follows:</t><figure><artwork><![CDATA[<artwork><![CDATA[ INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Alice <sip:alice@example.com> From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774> Call-ID: a84b4c76e66710 Call-Info: <data:application/json,["vcard",[["version",{},"text", "4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart ermaster-256x256.png"],["logo",{},"uri","https://example.com/log os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/ mi6-64x64.jpg"]]]\>;purpose=jcard;call-reason="Rendezvous for Little Nellie" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2025 19:12:25 GMT Contact: <sip:12155551000@gateway.example.com> Content-Type: application/sdp v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000]]></artwork></figure>]]></artwork> <t>An example SIP INVITE using the "cid" URI scheme is as follows:</t><figure><artwork><![CDATA[<artwork><![CDATA[ INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Alice <sip:alice@example.com> From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774> Call-ID: a84b4c76e66710 Call-Info: <cid:12155551000@example.com>;purpose=jcard; call-reason="Rendezvous for Little Nellie" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2025 19:12:25 GMT Contact: <sip:12155551000@gateway.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary1 Content-Type: application/json Content-ID: <12155551000@example.com> ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri"," https://example.com/photos/quartermaster-256x256.png"],["logo", {},"uri","https://example.com/logos/mi6-256x256.jpg"],["logo",{}, "uri","https://example.com/logos/mi6-64x64.jpg"]]]]]></artwork></figure>]]></artwork> </section> <sectionanchor="call-reason-call-info-parameter"><name>'call-reason'anchor="call-reason-call-info-parameter"> <name>'call-reason' Call-Info Parameter</name> <t>This parameter is intended to be separate and distinct from the other URI and 'purpose' tokens that mayproceedprecede these parameters.</t> <t>This new parameter of the Call-Info header field is called 'call-reason'. The 'call-reason' parameter is intended to convey a short textual message suitable for display to anend-userend user during call alerting. As a general guideline, this messageSHOULD<bcp14>SHOULD</bcp14> be no longer than 64 characters; displays that support this specification may be forced to truncate messages that cannot fit onto a screen. This message conveys the caller's intention in contacting the callee. It is an optional parameter, and the sender of a SIP request cannot guarantee that its display will be supported by the terminating endpoint. The manner in which this reason is set by the caller is outside the scope of this specification. In general, use of strings that could be forms of URIs or other potential strings that could be used or interpreted as a 'clickable' action is discouraged.</t> <t>An alternative approach would have been to use the value of Subject header field <xref target="RFC3261"/> to convey the reason for the call. However, because the Subject header field has seen little historical use in SIP implementations and its specification describes its potential use in filtering, it seemed prudent to define a new means of carrying acall reasoncall-reason indication.</t> <t>An example of a Call-Info header field value with the "call-reason" parameter follows:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Call-Info: <https://example.com/jbond.json>;purpose=jcard; call-reason="For your ears only"]]></artwork></figure>]]></artwork> <!-- [rfced] We are having trouble understanding how "or any future parameters that may be defined" relates to the text. "only" seems to limit the parameters that may be used, but "any future parameters" seems open ended (i.e., any parameter). Please review and consider whether the text can be clarified. Original: In the case that there is only a 'call-reason' or 'verified' parameter or any future parameters that may be defined and no need for a purpose parameter with no associated URI the null data URI, "data:" is used as the URI. --> <t>In the case that there is only a 'call-reason' or 'verified' parameter or any future parameters that may be defined and no need for a purpose parameter with no associated URI the null data URI, "data:" is used as the URI. The purpose parameter "jcard", defined in this document, is used to avoid any conflicts or confusion with existing implementations and previously defined purpose parameters. As an example:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Call-Info: <data:>;purpose=jcard; call-reason="For your ears only"]]></artwork></figure>]]></artwork> </section> <sectionanchor="verified-call-info-parameter"><name>'verified'anchor="verified-call-info-parameter"> <name>'verified' Call-Info Parameter</name> <t>The 'verified' parameter extends and complements the content conveyed by the RCD-related Call-Info header field. This parameter indicates to the recipient that the information contained in the Call-Info header field has been verified by verification procedures for claims defined inSection 8 of<xreftarget="I-D.ietf-stir-passport-rcd"/>.section="8" target="RFC9795"/>. The presence of a 'verified' parameter on a Call-Info header field should be considered specific to the information for that Call-Info header field only. If there is a Call-Info header field corresponding to information defined in this specification that doesn't contain a 'verified' parameter, the recipient should assume that information was not received and verified corresponding to the verification procedures defined inSection 8 of<xreftarget="I-D.ietf-stir-passport-rcd"/>.</t>section="8" target="RFC9795"/>.</t> <t>There is a single valid value associated with the 'verified' parameter of 'true'. The value 'true' indicates to the recipient that the party that included the Call-Info header field performed a successful verification of the information represented. As a general principle of Call-Info header field information, therecipientsrecipients' ability to trust the 'verified' parameter is based on the trusted relationship of whom they are receiving the SIP request.</t><t>Example<!--[rfced] May this be rephrased to clarify "of whom"? Seemingly this is about the trusted relationship with the party from whom they receive the SIP request. Original: As a general principle of Call-Info header field information, the recipients ability to trust the 'verified' parameter is based on the trusted relationship of whom they are receiving the SIP request. Perhaps: As a general principle of Call-Info header field information, the recipients' ability to trust the 'verified' parameter is based on the trusted relationship with the party from whom they are receiving the SIP request. --> <!-- [rfced] 'icon' vs. "icon" This term appears in single quotes (2 instances) and double quotes (6 instances); should it be consistent? Original: Example where the parameter verified="true" is used to represent that a verification procedure has been performed within a trust domain to indicate the 'icon' URL has been successfully verified: --> <t>The following is an example where the parameter verified="true" is used to represent that a verification procedure has been performed within a trusted domain to indicate the 'icon' URL has been successfully verified:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Call-Info: <https://example.com/jbond.png>;purpose=icon; verified="true"]]></artwork></figure>]]></artwork> <t>In addition to the use of the indication of successful verification of RCD information, an important usage of the 'verified' parameter isfor the indicationto indicate verification ofverified "display-name"display-name information, sometimes referred to as calling name or CNAM.</t> <t>In the following example, a call was delivered via an NNI to a terminating provider with the following STIR RCD PASSporT.</t><figure><artwork><![CDATA[<artwork><![CDATA[ Protected Header { "alg":"ES256", "typ":"passport", "ppt":"rcd", "x5u":"https://cert.example.org/passport.pem" } Payload { "dest":{"tn":["12025551001"]}, "iat":1443208345, "orig":{"tn":"12025551000"}, "rcd":{"nam":"James Bond","icn":"https://example.com/jbond.png"} }]]></artwork></figure>]]></artwork> <t>The terminating provider receives a SIP INVITE with an identity header containing the STIR RCD PASSporT that is verified through a verification service. The provider then wants to deliver the call to an end device in the trusted and authenticated UNI network. The provider uses local policies to determine the informationdesiredto present to the end device. The following example SIP INVITE could be used to represent the RCD information using two Call-Info header fields. Becausethe verification ofboth the icon and calling namepassed,have passed verification, a Call-Info header for the 'icon' is added with a verified="true" parameter, and the use of Call-Info with a null data URI is used, as discussed in the "call-reason" section above. <!-- [rfced] This sentence is difficult to parse. Please clarify. Original: This document defines the convention that when a Call-Info header field with a null data URI, "data:", a default purpose of "jcard" and adding a verified="true" indicates that the display-name information in either the From and/or P-Asserted-ID header field has been verified via RCD verification procedures. Perhaps: This document defines that the display-name information in either the From and/or P-Asserted-ID header field has been verified via RCD verification procedures when the following are present: * a Call-Info header field with a null data URI, "data:", * a default purpose of "jcard", and * verified="true". --> This document defines the convention that when a Call-Info header field with a null data URI, "data:", a default purpose of "jcard" and adding a verified="true" indicates that the display-name information in either the From and/or P-Asserted-ID header field has been verified via RCD verification procedures.</t> <t>Example SIP INVITE described above:</t><figure><artwork><![CDATA[<artwork><![CDATA[ INVITE sip:qbranch@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: "QBranch" <sip:qbranch@example.com> From: "James Bond" <sip:12155551000@example.com;user=phone>; tag=1928> Call-ID: a84b4c76e66710 Call-Info: <https://example.com/jbond.png>;purpose=icon; verified="true" Call-Info: <data:>;purpose=jcard;verified="true" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2025 19:12:25 GMT Contact: <sip:12155551000@gateway.example.com> Content-Type: application/sdp v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000]]></artwork></figure>]]></artwork> </section> <sectionanchor="integrity-call-info-parameter"><name>'integrity'anchor="integrity-call-info-parameter"> <name>'integrity' Call-Info Parameter</name> <t>The 'integrity' parameter extends and complements the integrity information conveyed specifically by the'rcdi'"rcdi" claim in the RCD-related Call-Info header field. This parameter is used to indicate, for a URI represented in the Call-Info header field, that the resource referenced by that URI has an associated integrity hash value, based conceptually on <xref target="W3C-SRI"/>.Section 6 of<xreftarget="I-D.ietf-stir-passport-rcd"/>section="6" target="RFC9795"/> describes the procedures for the creation of the digest value including the hash algorithm indicator a '-' separator and the hash value as a string. The JSON pointer object container described as the container of the 'rcdi' hashes is not necessarysincebecause each hash value should only correspond to a single URI. Corresponding to guidance defined inSection 6 of<xreftarget="I-D.ietf-stir-passport-rcd"/>,section="6" target="RFC9795"/>, implementations of this specificationMUST<bcp14>MUST</bcp14> support the hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are identified by "sha256", "sha384", and "sha512", respectively.</t> <!-- [rfced] This sentence starts with "this hash value" and switches to "the integrity value", but the connection between these is unclear. Please review. Original: Typically, this hash value, assuming the URI and the resource pointed to the URI don't change between the STIR RCD PASSporT and the Call- Info URI value, the integrity value can be directly used as the same corresponding string in both the 'rcdi' claim and the 'integrity' parameter string value. Perhaps: Assuming the URI and the resource pointing to the URI don't change between the STIR RCD PASSporT and the Call- Info URI value, the integrity value can typically be used as the same corresponding string in both the "rcdi" claim and the 'integrity' parameter. --> <t>Typically, this hash value, assuming the URI and the resource pointed to the URI don't change between the STIR RCD PASSporT and the Call-Info URI value, the integrity value can be directly used as the same corresponding string in both the'rcdi'"rcdi" claim and the 'integrity' parameter string value.</t><t>Note:<!-- [rfced] We are having trouble parsing this sentence. Please clarify. Original: Note: the inclusion of both the 'verified' and 'integrity' when an 'rcdi' claim is included and the identity header field and included PASSporT is verified successfully is the suggested outcome. Perhaps: Note: The ideal outcome is to include the 'verified' and 'integrity' parameters in an "rcdi" claim and the identity header field, and to have the PASSporT verified successfully. --> <t>Note: The inclusion of both the 'verified' and 'integrity' when an "rcdi" claim is included and the identity header field and included PASSporT is verified successfully is the suggested outcome. Creation of a Call-Info header field based on an identity header field that carries Rich Call Data claims that does not pass verification procedures is not suggested (i.e., the inclusion of an 'integrity' parameter without a properly included 'verified' parameter)</t> <t>Example STIR RCD PASSporT:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Protected Header { "alg":"ES256", "typ":"passport", "ppt":"rcd", "x5u":"https://cert.example.org/passport.pem" } Payload { "crn": "Rendezvous for Little Nellie", "dest": {"tn": ["12155551001"]}, "iat": 1443208345, "orig": {"tn": "12025551000"}, "rcd": { "nam": "Q Branch Spy Gadgets", "icn": "https://example.com/photos/q-256x256.png" }, "rcdi": { "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" } }]]></artwork></figure>]]></artwork> <t>Example corresponding SIP INVITE with Call-Info information derived from RCD information above:</t><figure><artwork><![CDATA[<artwork><![CDATA[ INVITE sip:qbranch@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: "James Bond" <sip:12155551001@example.com;user=phone> From: "Q Branch Spy Gadgets" <sip:12025551000@example.com; user=phone>;tag=1928> Call-ID: a84b4c76e66710 Call-Info: <https://example.com/photos/q-256x256.png>;purpose= icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm 1JKbm7+663bMvzymhkl4" Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for Little Nellie";verified="true" Call-Info: <data:>;purpose=jcard;verified="true" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2025 19:12:25 GMT Contact: <sip:12155551000@gateway.example.com> Content-Type: application/sdp v=0 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com s=Session SDP c=IN IP4 pc33.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000]]></artwork></figure>]]></artwork> </section> <sectionanchor="usage-and-an-example-of-call-info-for-rcd"><name>Usageanchor="usage-and-an-example-of-call-info-for-rcd"> <name>Usage and an Example of Call-Info for RCD</name> <!-- [rfced] We are unsure what "is a general anticipated process" means. Perhaps the text should refer to an "expected process" or an "accepted process"? Also, is the process a "general process" or is the process "generally anticipated"? Original: Because the 'rcd' Call-Info header field is inserted as part of the receiving part of the transition from NNI to UNI, the information populated in a received stir ‘rcd’ PASSporT that is verified is a general anticipated process for translating information into the 'rcd' Call-Info header field to transport the rich call data into the UNI toward the end user device. --> <t>The procedures for the usage of URIs and 'purpose' parameter tokens should follow the procedures defined in <xref target="RFC3261"/>. The general management and provisioning of Rich Call Data for an initiating partydoes requirerequires a lot of validation of information regarding that specific initiatingpartyparty, which is out of scope of this document. Because the 'rcd' Call-Info header field is inserted as part of the receiving part of the transition from NNI to UNI, the information populated in a receivedstir ‘rcd’STIR 'rcd' PASSporT that is verified is a general anticipated process for translating information into the 'rcd' Call-Info header field to transport the rich call data into the UNI toward theend userend-user device.</t><t>The<!-- [rfced] Should the text refer to the "jcard" and "icon" parameters here (i.e., lowercase and doublequotes)? Original: The following example provides both the STIR RCD PASSporT and the corresponding set of Call-Info header fields shows the use of multiple 'purpose' parameters to indicate a jCard and an icon and also a 'call-reason' parameter: --> <t>The following example provides both the STIR RCD PASSporT and the corresponding set of Call-Info header fields showing the use of multiple 'purpose' parameters to indicate a jCard and an icon and also a 'call-reason' parameter:</t> <t>Example STIR RCD PASSporT:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Protected Header { "alg":"ES256", "typ":"passport", "ppt":"rcd", "x5u":"https://cert.example.org/passport.pem" } Payload { "crn":"For your ears only", "dest":{"tn":["12025551001"]}, "iat":1443208345, "orig":{"tn":"12025551000"}, "rcd":{ "jcl":"https://example.com/qbranch.json", "icn":"https://example.com/jbond.png" }, "rcdi": { "/jcl": "sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82+kHP" "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" } }]]></artwork></figure>]]></artwork> <t>Example Call-Info header fields:</t><figure><artwork><![CDATA[<artwork><![CDATA[ Call-Info: <data:>;purpose=jcard;verified="true" Call-Info: <https://example.com/jbond.json>;purpose=jcard;verified =true;integrity="sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82 +kHP" Call-Info: <https://example.com/jbond.png>;purpose=icon; call-reason="For your ears only";verified=true;integrity= "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"]]></artwork></figure>]]></artwork> </section> <sectionanchor="usage-of-jcard-and-property-specific-usage"><name>Usageanchor="usage-of-jcard-and-property-specific-usage"> <name>Usage of jCard and Property-Specific Usage</name> <t>Beyond the definition of the specific properties or JSON arrays associated with each property, this specification defines a few rulesabove andbeyond those defined in <xref target="RFC7095"/> that are specific to the use of jCard for Call-Info and RCD to ensure there is a minimum level of supported properties to which every implementation of this specification should adhere. This includes support for interpreting the value of these properties and the ability to render in some appropriate form the display capabilities of common telephone devices as well as applications, and also includes requirements specific to textual and graphics-capable displays.</t> <sectionanchor="usage-of-uris-in-jcard"><name>Usageanchor="usage-of-uris-in-jcard"> <name>Usage of URIs in jCard</name><t>When<!-- [rfced] The last sentence below is dense and hard to follow. Please review. Original (the sentence prior is provided for context): When one or more URIs are used in a jCard, it is important to note that any URI-referenced data, with the exception of the top-level usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI references. In other words, the jCard can have URI references as defined in the jCard specification and this document, but the content referenced by those URIs MUST NOT have any URIs, and therefore MUST be enforced by the client to not follow those URI references or not render that content to the user if any URI are present in that specific URI linked content. Perhaps: In other words, the jCard can have URI references as defined in the jCard specification and this document, but the content referenced by those URIs MUST NOT have any URIs; therefore, the client MUST ensure that those URI references are not followed, and any URIs that are present in that specific URI-linked content are not rendered. --> <t>When one or more URIs are used in a jCard, it is important to note that any URI-referenced data, with the exception of the top-level usage of "jcl" as a URI to the jCard itself <bcp14>MUST NOT</bcp14> contain any URI references. In other words, the jCard can have URI references as defined in the jCard specification and this document, but the content referenced by those URIs <bcp14>MUST NOT</bcp14> have any URIs, and therefore <bcp14>MUST</bcp14> be enforced by the client to not follow those URI references or not render that content to the user if any URI are present in that specific URI linked content. The purpose of this is to control the security and more specifically to align with the content-integrity mechanism defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>.target="RFC9795"/>. There is not anticipated to be need for which deeper URI references would be required or even supported by the typical use of current jCard properties. However, because jCard is extensible, this rule is set to restrict further extension without the proper consideration of security and integrity properties of both Call-Info usage as well as the RCD and STIR signing of the data <xreftarget="I-D.ietf-stir-passport-rcd"/>target="RFC9795"/> <xref target="RFC8224"/>.</t> </section> <sectionanchor="multimedia-data"><name>Usageanchor="multimedia-data"> <!-- [rfced] It appears as though tokens appear in double quotes. Should the section title be updated to reflect "icon"? Original: 10.2. Usage of Multimedia Data in jCard or with Icon Perhaps: 10.2. Usage of Multimedia Data in jCard or with the "icon" Token --> <name>Usage of Multimedia Data in jCard or with Icon</name> <t>For the use of the 'purpose' token "icon" or for the cases where the jCard either incorporates URIs or includes digital images and sounds directly via Base64 encoding(Section 4 of <xref(<xref section="4" target="RFC4648"/>), this document provides guidance at the time of writing that can be adopted to facilitate the successful decoding and rendering of these images and mediaformats, notingformats. Note that media formatsisare likely something implementers need to consider for their specific application.</t> <t>For images, such as for the "photo" and "logo" properties, the default image formatsSHOULD<bcp14>SHOULD</bcp14> be PNG <xref target="ISOPNG"/> or JPEG <xref target="ITUJPEG"/>, as these files are commonly used to support 24-bit RGB images. Supporting older telephone devices that only support bitmap (BMP) images <xref target="RFC7903"/> with a lower bit range (e.g., 16-bit, 8-bit, or 1-bit), or grayscale, or 1-bit black and white color displays, should be considered optional or even not recommended because, at the time of writing, they are becoming increasingly rare (i.e., typically, devices either have color or color-aware graphical displays that support PNG or JPEG formats or they are exclusively textual displays).</t> <t>In addition, vector images are increasingly popular to useforas icons because they support scalable images without having to send multiple resolutions. The SVG format has gained wide support as of this writing as a common format for vector images. At a minimum, the SVG Tiny 1.2 specification <xref target="W3C-SVGTiny1.2"/>SHOULD<bcp14>SHOULD</bcp14> be supported as an additional default format for devices.</t> <t>For the cases where image files are referenced by URIs as file resources, this document defines a character string thatSHOULD<bcp14>SHOULD</bcp14> be concatenated onto the end of a file name, but before the file extension, that signals the height and width of the image to the end device for the convenience of determining the appropriate resolution to retrieve files without the need to retrieve all the image files. It is also recommended that images have a square aspect ratio with equal height and width and with apower of twopower-of-two value for the number of pixels (e.g., 32x32, 128x128, 512x512). The format of the string should be "filename-HxW", where "filename" is a unique string representing the file, "H" represents the height in pixels, and "W" represents the width in pixels.</t> <t>It is appropriate and useful to include multiple versions of images or sounds so that endpoints that cannot support all formats or resolutions can select the format they do support. The <bcp14>RECOMMENDED</bcp14> conventionthatisRECOMMENDED is thatfor files that refer to the same contentshouldto use the same filename portion. If the image format has a specific resolution, the HxW portion of the filename should correspond to the pixel resolution. The file extension should reference the file type (e.g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32x32.png, filename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64.jpg).</t> <t>Because this is a complex and often debated topic that has evolved over the many years of advances in image coding and display technologies, this specification suggests relying on either future specifications or industry forum specifications that might correspond to supporting particular classes of devices to further define how URIs can reference appropriate image formats and files.</t> <t>For audio files, the recommendation is to provide mp3, m4a or mp4, or wav files <xref target="RFC2361"/>, although the usage of sound (for example, a special ring tone for a particular caller) is not well defined in this specification. Future documents should consider both usage and potential security risks of playing sounds that are not specifically authorized by a device user.</t> </section> <sectionanchor="cardinality"><name>Cardinality</name>anchor="cardinality"> <name>Cardinality</name> <t>Property cardinalities are indicated, for convenience, using the following notation and follow the guidance of jCard <xref target="RFC7095"/> and vCard <xref target="RFC6350"/>, which is based on ABNF (see <xref section="3.6" sectionFormat="comma" target="RFC5234"/>):</t><figure><artwork><![CDATA[ +-------------+--------------------------------------------------+ | Cardinality | Meaning | +-------------+--------------------------------------------------+ | 1 | Exactly<table> <thead><tr><th>Cardinality</th><th>Meaning</th></tr></thead> <tbody> <tr><td>1</td><td>Exactly one instance per jCardMUST<bcp14>MUST</bcp14> bepresent. | | *1 | Exactlypresent.</td></tr> <tr><td>*1</td><td>Exactly one instance per jCardMAY<bcp14>MAY</bcp14> bepresent. | | 1* | Onepresent.</td></tr> <tr><td>1*</td><td>One or more instances per jCardMUST<bcp14>MUST</bcp14> bepresent. | | * | Onepresent.</td></tr> <tr><td>*</td><td>One or more instances per jCardMAY<bcp14>MAY</bcp14> bepresent. | +-------------+--------------------------------------------------+ ]]></artwork></figure>present.</td></tr> </tbody> </table> </section> <sectionanchor="identification-properties"><name>Identificationanchor="identification-properties"> <name>Identification Properties</name> <t>The following properties, initially defined in <xref target="RFC6350"/>, hold the identity information of the entity associated with the jCard. This subset of properties selected for this document are relevant to telephone and messaging applications.</t> <sectionanchor="fn-property"><name>"fn"anchor="fn-property"> <name>"fn" Property</name> <t>The "fn" property providesaformatted text corresponding to the name of the object the jCard represents. Reference: <xref section="6.2.1" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: 1*</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>1*</dd> </dl> <artwork><![CDATA[ Example: ["fn", {}, "text", "Mr. John Q. Public\, Esq."]]]></artwork></figure>]]></artwork> </section> <sectionanchor="n-property"><name>"n"anchor="n-property"> <name>"n" Property</name> <t>The "n" property provides the components of the name of the object the jCard represents. Reference: <xref section="6.2.2" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single structured text value. Each component can have multiplevalues.</t> <t>Cardinality: *1</t> <figure><artwork><![CDATA[values.</dd> <dt>Cardinality:</dt><dd>*1</dd> </dl> <artwork><![CDATA[ Example: ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]]]></artwork></figure>]]></artwork> </section> <sectionanchor="nickname-property"><name>"nickname"anchor="nickname-property"> <name>"nickname" Property</name> <t>The "nickname" property provides the text corresponding to the nickname of the object the jCard represents. Reference: <xref section="6.2.3" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: One<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>One or more text values separated by a COMMA character(U+002C).</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[(U+002C).</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["nickname", {}, "text", "Robbie"] ["nickname", {}, "text", "Jim,Jimmie"] ["nickname", {}, "text", "TYPE=work:Boss"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="photo-property"><name>"photo"anchor="photo-property"> <name>"photo" Property</name> <t>The "photo" property provides image or photograph information that annotates some aspect of the object the jCard represents. Reference: <xref section="6.2.4" sectionFormat="comma" target="RFC6350"/>.</t> <t>In addition to the definition of jCard, and to promote interoperability and proper formatting and rendering of images, the photoSHOULD<bcp14>SHOULD</bcp14> correspond to a square image with the size of 128x128, 256x256, 512x512, or 1024x1024 pixels.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A singleURI.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[URI.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="delivery-addressing-properties"><name>Deliveryanchor="delivery-addressing-properties"> <name>Delivery Addressing Properties</name> <t>This property is concerned with information related to the delivery address of the jCard object.</t> <sectionanchor="adr-property"><name>"adr"anchor="adr-property"> <name>"adr" Property</name> <t>The "adr" property provides the delivery address of the object the jCard represents. Reference: <xref section="6.3.1" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single structured text value separated by the SEMICOLON character(U+003B).</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[(U+003B).</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["adr",{“type”:”work"},{"type":"work"}, "text", ["", "", "3100 Massachusetts Avenue NW", "Washington",“DC”,"DC", "20008",“U.S.A."]"U.S.A."] ]]]></artwork></figure>]]></artwork> <t>"adr" also allows a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. The following example shows alternate values for the address string.</t><figure><artwork><![CDATA[<artwork><![CDATA[ Example: ["adr",{“type”:”work"},{"type":"work"}, "text", ["", "", ["3100 Massachusetts AvenueNW”,"EmbassyNW","Embassy of the United Kingdom"], "Washington",“DC”,"DC", "20008",“U.S.A."]"U.S.A."] ]]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="communications-properties"><name>Communicationsanchor="communications-properties"> <name>Communications Properties</name> <t>These properties describe how to communicate with the object the jCard represents.</t> <sectionanchor="tel-property"><name>"tel"anchor="tel-property"> <name>"tel" Property</name> <t>The "tel" property provides the telephone number for the object the jCard represents. Reference: <xref section="6.4.1" sectionFormat="comma" target="RFC6350"/>.</t> <t>Relative to the SIP From header field value, this information may provide an alternate telephone number or other related telephone numbers for other uses.</t> <!-- [rfced] Is it accurate to refer to the 'potential instances of the "tel" property', as opposed to 'instances of the "tel" property'? Original: It is important to note that any of the potential instances of the "tel" property should not be considered part of the authentication or verification part of STIR [RFC8224] or required to match the "orig" claim in the PASSporT [RFC8225]. Similarly, is "has the intent" correct in the following (instead of "provides" and "specifies")? Original: The "title" property has the intent of providing the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.1. The "role" property has the intent of providing the position or job of the object the jCard represents. Reference [RFC6350], Section 6.6.2. The "logo" property has the intent of specifying a graphic image of a logo associated with the object the jCard represents. Reference [RFC6350], Section 6.6.3. The "org" property has the intent of specifying the organizational name and units of the object the jCard represents. Reference [RFC6350], Section 6.6.4. The "version" property MUST be included and is intended to specify the version of the vCard specification used to format this vCard. --> <t>It is important to note that any of the potential instances of the "tel" property should not be considered part of the authentication or verification part of STIR <xref target="RFC8224"/> or required to match the "orig" claim in the PASSporT <xref target="RFC8225"/>. These telephone numbers can be for contact, fax, or other purposes aligned with the general usage of jCard and vCard, but the potential confusion of the callee when provided with multiple telephone numbersversusinstead of the actual, verified telephone number should be considered from a general policy point of view.</t><t>Value type: By<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>By default, it is a single free-form text value (for backward compatibility with vCard 3), but itSHOULD<bcp14>SHOULD</bcp14> be reset to a URI value. It is expected that the URI scheme will be "tel", as specified in <xref target="RFC3966"/>, but other schemesMAY<bcp14>MAY</bcp14> beused.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[used.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", "tel:+1-202-555-1000"] ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="email-property"><name>"email"anchor="email-property"> <name>"email" Property</name> <t>The "email" property provides the electronic mail address of the object the jCard represents. Reference: <xref section="6.4.2" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] ["email", {"pref":"1"}, "text", "jane_doe@example.com"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="lang-property"><name>"lang"anchor="lang-property"> <name>"lang" Property</name> <t>The "lang" propertyprovidesindicates the language(s) that may be used for communicating with the object the jCard represents. Reference: <xref section="6.4.4" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single language-tagvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] ["lang", {"type":"home"}, "language-tag", "fr"]]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="geographical-properties"><name>Geographicalanchor="geographical-properties"> <name>Geographical Properties</name> <t>These properties provide geographical information associated with the object the jCard represents.</t> <sectionanchor="tz-property"><name>"tz"anchor="tz-property"> <name>"tz" Property</name> <t>The "tz" property provides the time zone of the object the jCard represents. Reference: <xref section="6.5.1" sectionFormat="comma" target="RFC6350"/>.</t> <t>Note:theThe reference for time-zone names ishttps://www.iana.org/time-zones.</t> <t>Value type: The<eref brackets="angle" target="https://www.iana.org/time-zones"/>.</t> <dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>The default is a single text value. It can also be reset to a single URI or a UTC-offsetvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["tz", {}, "text", "America/New_York"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="geo-property"><name>"geo"anchor="geo-property"> <name>"geo" Property</name> <t>The "geo" property provides the global positioning of the object the jCard represents. Reference: <xref section="6.5.2" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A singleURI.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[URI.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["geo", {}, "uri", "geo:37.386013,-122.082932"]]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="organizational-properties"><name>Organizationalanchor="organizational-properties"> <name>Organizational Properties</name> <t>These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the jCard represents.</t> <sectionanchor="title-property"><name>"title"anchor="title-property"> <name>"title" Property</name> <t>The "title" property has the intent of providing the position or job of the object the jCard represents. Reference <xref section="6.6.1" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["title", {}, "text", "Research Scientist"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="role-property"><name>"role"anchor="role-property"> <name>"role" Property</name> <t>The "role" property has the intent of providing the position or job of the object the jCard represents. Reference <xref section="6.6.2" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["role", {}, "text", "Project Leader"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="logo-property"><name>"logo"anchor="logo-property"> <name>"logo" Property</name> <t>The "logo" property has the intent of specifying a graphic image of a logo associated with the object the jCard represents. Reference <xref section="6.6.3" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A singleURI.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[URI.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"] ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 <...the remainder of base64-encoded data...>"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="org-property"><name>"org"anchor="org-property"> <name>"org" Property</name> <t>The "org" property has the intent of specifying the organizational name and units of the object the jCard represents. Reference <xref section="6.6.4" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single structured text value consisting of components separated by the SEMICOLON character(U+003B).</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[(U+003B).</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]]]></artwork></figure>]]></artwork> </section> </section> <sectionanchor="explanatory-properties"><name>Explanatoryanchor="explanatory-properties"> <name>Explanatory Properties</name> <t>These properties provide additional information such as notes or revisions specific to the jCard.</t> <sectionanchor="categories-property"><name>"categories"anchor="categories-property"> <name>"categories" Property</name> <t>The "categories" property specifies application category information about the object the jCard represents. Reference: <xref section="6.7.1" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: One<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>One or more text values separated by a COMMA character(U+002C).</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[(U+002C).</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["categories", {}, "text", "TRAVEL AGENT"] ["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="note-property"><name>"note"anchor="note-property"> <name>"note" Property</name> <t>The "note" property specifies supplemental information or a comment about the object the jCard represents. Reference: <xref section="6.7.2" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["note", {}, "text", "This fax number is operational 0800 to 1715 EST\, Mon-Fri."]]]></artwork></figure>]]></artwork> </section> <sectionanchor="sound-property"><name>"sound"anchor="sound-property"> <name>"sound" Property</name> <t>The "sound" property specifies digital sound content information that annotates some aspect of the object the jCard represents. This property is often used to specify the proper pronunciation of the name property value of the jCard. Reference: <xref section="6.7.5" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A singleURI.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[URI.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["sound", {}, "uri", "https://www.example.com/pub/logos /abccorp.mp3"] ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBA gICBEAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvb W11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiB <...the remainder of base64-encoded data...>"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="uid-property"><name>"uid"anchor="uid-property"> <name>"uid" Property</name> <t>The "uid" property specifies a globally unique identifier corresponding to the object the jCard represents. Reference: <xref section="6.7.6" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single URI value. ItMAY<bcp14>MAY</bcp14> also be reset to free-formtext.</t> <t>Cardinality: *1</t> <figure><artwork><![CDATA[text.</dd> <dt>Cardinality:</dt><dd>*1</dd> </dl> <artwork><![CDATA[ Example: ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="url-property"><name>"url"anchor="url-property"> <name>"url" Property</name> <t>The "url" property specifies a uniform resource locator associated with the object the jCard represents. Reference: <xref section="6.7.8" sectionFormat="comma" target="RFC6350"/>.</t> <!-- [rfced] For clarity, we suggest the update below. Please review and let us know if this acceptable. Original: The end client receiving a jCard with a "url" property MUST only display the URL and not automatically follow the URL or provide automatic preview of the URL, and generally provide good practices in making it clear to the user it is their choice to follow the URL in a browser context consistent with all of the common browser security and privacy practices available on most consumer OS environments. Perhaps: The end client receiving a jCard with a "url" property MUST only display the URL and not automatically follow the URL or provide an automatic preview of the URL. In addition, it MUST generally adhere to good practice to make it clear to the user that it is their choice whether to follow the URL in a browser context consistent with all of the common browser security and privacy practices available on most consumer OS environments. --> <t>There are potential security and privacy implications of providing URLs with telephone calls. The end client receiving a jCard with a "url" propertyMUST<bcp14>MUST</bcp14> only display the URL and not automatically follow the URL or provide an automatic preview of the URL, and generally provide good practices in making it clear to the user it is their choice to follow the URL in a browser context consistent with all of the common browser security and privacy practices available on most consumer OS environments.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single urivalue.</t> <t>Cardinality: *</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>*</dd> </dl> <artwork><![CDATA[ Example: ["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]]]></artwork></figure>]]></artwork> </section> <sectionanchor="version-property"><name>"version"anchor="version-property"> <name>"version" Property</name> <t>The "version" propertyMUST<bcp14>MUST</bcp14> be included and is intended to specify the version of the vCard specification used to format this vCard. Reference: <xref section="6.7.9" sectionFormat="comma" target="RFC6350"/>.</t><t>Value type: A<dl spacing="compact" newline="false"> <dt>Value type:</dt><dd>A single textvalue.</t> <t>Cardinality: 1</t> <figure><artwork><![CDATA[value.</dd> <dt>Cardinality:</dt><dd>1</dd> </dl> <artwork><![CDATA[ Example: ["version", {}, "text", "4.0"]]]></artwork></figure>]]></artwork> </section> </section> </section> <sectionanchor="extension-of-jcard"><name>Extensionanchor="extension-of-jcard"> <name>Extension of jCard</name> <t>Part of the intent of using jCard is to leverage its extensibility to define new properties to relay new information related to a caller. This capability is inherently supported as part of standard extensibility. However, usage of those new properties should be published and registered following <xref section="3.6" sectionFormat="comma" target="RFC7095"/> ornewas defined in future specifications.</t> </section> <sectionanchor="IANA"><name>IANAanchor="IANA"> <name>IANA Considerations</name> <sectionanchor="jcard-purpose-parameter-value"><name>'jcard'anchor="jcard-purpose-parameter-value"> <name>'jcard' Purpose Parameter Value</name> <t>This document defines the 'jcard' value for the 'purpose' parameter of the Call-Info header field <xref target="RFC3261"/>. IANA has added this document to the list of references for the 'purpose' value of Call-Info in the "Header Field Parameters and Parameter Values"sub-registry ofregistry within the "Session Initiation Protocol (SIP) Parameters"registry.</t>registry group.</t> </section> <sectionanchor="sip-call-info-header-field-call-reason-parameter"><name>SIPanchor="sip-call-info-header-field-call-reason-parameter"> <name>SIP Call-Info Header Field 'call-reason' Parameter</name> <t>This document defines the 'call-reason' generic parameter for useas a new parameterin the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by <xref target="RFC3968"/>. The parameter's token is "call-reason", and it takes the value of a quoted string.</t><figure><artwork><![CDATA[ +--------------+----------------+-------------------+------------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+------------+ | Call-Info | call-reason | No | [this RFC] | +--------------+----------------+-------------------+------------+ ]]></artwork></figure><table> <thead><tr><th>Header Field</th><th>Parameter Name</th><th>Predefined Values</th><th>Reference</th></tr></thead> <tbody><tr><td>Call-Info</td><td>call-reason</td><td>No</td><td>RFC 9796</td></tr></tbody> </table> </section> <sectionanchor="sip-call-info-header-field-verified-parameter"><name>SIPanchor="sip-call-info-header-field-verified-parameter"> <name>SIP Call-Info Header Field 'verified' Parameter</name> <t>This document defines the 'verified' generic parameter for useas a new parameterin the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by <xref target="RFC3968"/>. The parameter's token is "verified", and it takes the value of a quoted string that can only be "true".</t><figure><artwork><![CDATA[ +--------------+----------------+-------------------+------------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+------------+ | Call-Info | verified | Yes | [this RFC] | +--------------+----------------+-------------------+------------+ ]]></artwork></figure><table> <thead><tr><th>Header Field</th><th>Parameter Name</th><th>Predefined Values</th><th>Reference</th></tr></thead> <tbody><tr><td>Call-Info</td><td>verified</td><td>Yes</td><td>RFC 9796</td></tr></tbody> </table> </section> <sectionanchor="sip-call-info-header-field-integrity-parameter"><name>SIPanchor="sip-call-info-header-field-integrity-parameter"> <name>SIP Call-Info Header Field 'integrity' Parameter</name> <t>This document defines the 'integrity' generic parameter for use as a new parameter in the Call-Info header field in the "Header Field Parameters and Parameter Values" registry defined by <xref target="RFC3968"/>. The parameter's token is "integrity", and it takes the value of a quoted string.</t><figure><artwork><![CDATA[ +--------------+----------------+-------------------+------------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+------------+ | Call-Info | integrity | No | [this RFC] | +--------------+----------------+-------------------+------------+ ]]></artwork></figure><table> <thead><tr><th>Header Field</th><th>Parameter Name</th><th>Predefined Values</th><th>Reference</th></tr></thead> <tbody><tr><td>Call-Info</td><td>integrity</td><td>No</td><td>RFC 9796</td></tr></tbody> </table> </section> </section> <sectionanchor="Security"><name>Securityanchor="Security"> <name>Security Considerations</name> <t>Revealing information such as the name, location, and affiliation of a person necessarily entails certain privacy risks. The SIP Call-Info header field has no particular confidentiality requirement, as the information sent in SIP is in the clear anyway. Transport-level security can be used to hide information from eavesdroppers, and the same confidentiality mechanisms would protect any Call-Info or jCard information carried or referred to in SIP.</t> <t>The use of the Call-Info header for transporting Rich Call Data ('rcd') is intended primarily for providing verified information at the termination of a call, where a verification service has a trusted UNI relationship with the user agent. To ensure the integrity and authenticity of this data, the security framework established by STIR, including the use of the 'rcd'PASSporT as defined in <xreftarget="I-D.ietf-stir-passport-rcd"/>,target="RFC9795"/>, should be followed. This framework enables digital signatures to verify the issuer of assertions related to the calling party's identity, distinguishing persistent identity attributes from transient, per-call details. Implementers should also consider certificate-based constraints to ensure proper binding between caller identity assertions and call-specific metadata while maintaining the integrity of the information throughout transmission. Since Call-Info serves as a means to convey verified caller information to the end user, mechanisms should be in place to validate the authenticity of the assertion, enforce appropriate certificate associations, and preserve the trustworthiness of Rich Call Data from origination to termination.</t> <!-- [rfced] "since its existence" is awkward; may we update the text as follows? Current: The SIP framework, defined in [RFC3261] and the various extensions to SIP, which includes STIR [RFC8224] and rich call data [RFC9795], since its existence has provided mechanisms to assert information about the person or entity behind the call. Perhaps: The SIP framework, defined in [RFC3261] and the various extensions to SIP, which includes STIR [RFC8224] and rich call data [RFC9795], has always provided mechanisms to assert information about the person or entity behind the call. --> <!-- [rfced] What does "weigh this responsibility" refer to? Is it the core security consideration, the risk of impersonation, or both? Original (earlier sentences included for context): It can also enable the ability for actors to impersonate a calling party they are not authorized to represent. The core security consideration that either explicitly or implicitly have been acknowledged with any of the SIP and STIR specifications is that there is a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers and identity related information. The use of this specification should weigh this responsibility and make the appropriate considerations to validate the proper participation and use of these tools follow these larger security, impersonation prevention, and privacy considerations. Perhaps: Users should assess this [risk / core consideration / both the risk and core consideration] and make the appropriate adjustments to validate proper participation while following these larger security, impersonation prevention, and privacy considerations. --> <t>The SIP framework, defined in <xref target="RFC3261"/> and the various extensions toSIP,SIP whichstirincludes STIR <xref target="RFC8224"/> and rich call data <xreftarget="I-D.ietf-stir-passport-rcd"/> are included,target="RFC9795"/>, since its existence has provided mechanisms to assert information about the person or entity behind the call. Thiscan be afeature that can be a benefit to the SIP network that allows users to help identify the calling party behind an abstract telephone number. It can also enable the ability for actors to impersonate a calling party they are not authorized to represent. The core security consideration that has either explicitly or implicitlyhavebeen acknowledged with any of the SIP andstirSTIR specifications is that thereisbe a management and policy layer that validates the participants in the ecosystem and their use of a SIP network with telephone number identifiers andidentity relatedidentity-related information. The use of this specification should weigh this responsibility and make the appropriate considerations to validate the proper participation and use of these toolsfollowfollowing these larger security, impersonation prevention, and privacy considerations.</t> <t>The use of this specification with the insertion ofmeta datametadata related to a caller or the purpose of the call should recognize the risk that this information can be viewed by those network elements and participants in the delivery of the SIP call. The insertion of media directly or via Base64 encoding or using a remote URI that query network resources should be considered as a potential threat vector to the user or user agent that could potentially allow the parsing of documents crafted to trigger a bug or install a virus. Remote access to URI content should additionally be considered as potentially exposing information about that user or user agent. Some sensitive users may desire the ability to control or disable these mechanismsentirelyentirely, and methods to restrict or disablethesethe potentialconcernsexposure should be considered to mitigate these concerns. Largely, any information that is included in rich call data should be consideredpublicpublic, and this specification does not define any mechanism to protect this information beyond the security and privacy associated with the SIP signalling itself. This is a property that is consistent with SIP moregenerallygenerally, and this specification follows a similar pattern for its use.</t> <!--[rfced] May this be rephrased for readability? If so, who should do the considering? Original: A network specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem should be considered. Perhaps: Network administrators should consider a network-specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem. --> <t>This specification contains the ability to include media resources and URI and URL resource references to media resources that could pose a threat when referencing or decoding the content of these mediaresourcesresources, which is similar to threats that web browsers and other media decoding applications must be concerned about. Anetwork specificnetwork-specific set of policies or best practices for the use and hosting of media content that is agreed to contain validated media resources that have been evaluated to not pose a security threat to the participants or the devices supported in the ecosystem should be considered.</t> </section> </middle> <back> <referencestitle='References'anchor="sec-combined-references"> <name>References</name> <referencestitle='Normative References'anchor="sec-normative-references"> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2392.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3966.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3968.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6350.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7095.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7852.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7903.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <!-- companion: RFC 9795 - draft-ietf-stir-passport-rcd-26 --> <referenceanchor="RFC2392"> <front> <title>Content-ID and Message-ID Uniform Resource Locators</title> <author fullname="E. Levinson" initials="E." surname="Levinson"/> <date month="August" year="1998"/> <abstract> <t>The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2392"/> <seriesInfo name="DOI" value="10.17487/RFC2392"/> </reference> <reference anchor="RFC3261">anchor="RFC9795" target="https://www.rfc-editor.org/info/rfc9795"> <front><title>SIP: Session Initiation Protocol</title> <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author fullname="G. Camarillo" initials="G." surname="Camarillo"/><title>Personal Assertion Token (PASSporT) Extension for Rich Call Data</title> <authorfullname="A. Johnston" initials="A." surname="Johnston"/>initials="C." surname="Wendt" fullname="Chris Wendt"> <organization>Somos Inc.</organization> </author> <authorfullname="J. Peterson"initials="J."surname="Peterson"/> <author fullname="R. Sparks" initials="R." surname="Sparks"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <author fullname="E. Schooler" initials="E." surname="Schooler"/> <date month="June" year="2002"/> <abstract> <t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3261"/> <seriesInfo name="DOI" value="10.17487/RFC3261"/> </reference> <reference anchor="RFC3966"> <front> <title>The tel URI for Telephone Numbers</title> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>surname="Peterson" fullname="Jon Peterson"> <organization>Neustar Inc.</organization> </author> <datemonth="December" year="2004"/> <abstract> <t>This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]</t> </abstract>month="May" year='2025'/> </front> <seriesInfo name="RFC"value="3966"/>value="9795"/> <seriesInfo name="DOI"value="10.17487/RFC3966"/>value="10.17487/RFC9795"/> </reference><reference anchor="RFC3968"> <front> <title>The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for<!-- [rfced] Regarding [W3C-SRI], theSession Initiation Protocol (SIP)</title> <author fullname="G. Camarillo" initials="G." surname="Camarillo"/> <date month="December" year="2004"/> <abstract> <t>This document creates an Internet Assigned Number Authority (IANA) registryoriginal URL for this reference directed theSession Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter valuesreader tobe used asa W3C First Public Working Draft with a date of 22 April 2025. However, theinitial entriesoriginal date provided for thisregistry. 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="98"/> <seriesInfo name="RFC" value="3968"/> <seriesInfo name="DOI" value="10.17487/RFC3968"/> </reference> <reference anchor="RFC4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <date month="October" year="2006"/> <abstract> <t>This document describesreference was 23 June 2016, which matches that of thecommonly used base 64, base 32, and base 16 encoding schemes. It also discussesW3C Recommendation titled "Subresource Integrity" (https://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this reference to that. However, please let us know if you intended to point to theuse of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfo name="DOI" value="10.17487/RFC4648"/> </reference>First Public Working Draft (https://www.w3.org/TR/2025/WD-sri-2-20250422/) or otherwise. Original: [W3C-SRI] W3C, "Subresource Integrity", 23 July 2016, <https://www.w3.org/TR/SRI/>. Current: [W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. Weinberger, Ed., "Subresource Integrity", W3C Recommendation, 23 June 2016, <https://www.w3.org/TR/2016/REC-SRI-20160623/>. --> <referenceanchor="RFC5234">anchor="W3C-SRI" target="https://www.w3.org/TR/2016/REC-SRI-20160623/"> <front><title>Augmented BNF for Syntax Specifications: ABNF</title><title>Subresource Integrity</title> <author fullname="Devdatta Akhawe" role="editor" /> <authorfullname="D. Crocker" initials="D."fullname="Frederik Braun" role="editor"surname="Crocker"/>/> <authorfullname="P. Overell" initials="P." surname="Overell"/>fullname="Francois Marier" role="editor" /> <author fullname="Joel Weinberger" role="editor" /> <datemonth="January" year="2008"/> <abstract> <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t> </abstract>year="2016" month="June" day="23"/> </front><seriesInfo name="STD" value="68"/> <seriesInfo name="RFC" value="5234"/> <seriesInfo name="DOI" value="10.17487/RFC5234"/><refcontent>W3C Recommendation</refcontent> </reference><reference anchor="RFC6350"> <front> <title>vCard Format Specification</title> <author fullname="S. Perreault" initials="S." surname="Perreault"/> <date month="August" year="2011"/> <abstract> <t>This document defines the vCard data format<!-- XML forrepresenting and exchanging a varietythe W3C Public Working Draft Version ofinformation about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6350"/> <seriesInfo name="DOI" value="10.17487/RFC6350"/> </reference>[W3C-SubresourceIntegrity] <referenceanchor="RFC7095">anchor="W3C-SRI" target="https://www.w3.org/TR/2025/WD-sri-2-20250422/"> <front><title>jCard: The JSON Format for vCard</title><title>Subresource Integrity</title> <authorfullname="P. Kewisch" initials="P." surname="Kewisch"/>fullname="Frederik Braun" role="editor" /> <datemonth="January" year="2014"/> <abstract> <t>This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.</t> </abstract>year="2025" month="April" day="25"/> </front><seriesInfo name="RFC" value="7095"/> <seriesInfo name="DOI" value="10.17487/RFC7095"/><refcontent>W3C First Public Working Draft</refcontent> </reference> --> <referenceanchor="RFC7519">anchor="W3C-SVGTiny1.2" target="https://www.w3.org/TR/2008/REC-SVGTiny12-20081222/"> <front><title>JSON Web Token (JWT)</title><title>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</title> <authorfullname="M. Jones" initials="M." surname="Jones"/>fullname="Ola Anderssone" role="editor" /> <authorfullname="J. Bradley" initials="J." surname="Bradley"/>fullname="Robin Berjon" role="editor" /> <authorfullname="N. Sakimura" initials="N." surname="Sakimura"/> <date month="May" year="2015"/> <abstract> <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t> </abstract> </front> <seriesInfo name="RFC" value="7519"/> <seriesInfo name="DOI" value="10.17487/RFC7519"/> </reference> <reference anchor="RFC7852"> <front> <title>Additional Data Related to an Emergency Call</title>fullname="Erik Dahlström" role="editor" /> <authorfullname="R. Gellens" initials="R." surname="Gellens"/>fullname="Andrew Emmons" role="editor" /> <authorfullname="B. Rosen" initials="B." surname="Rosen"/>fullname="Jon Ferraiolo" role="editor" /> <authorfullname="H. Tschofenig" initials="H." surname="Tschofenig"/>fullname="Anthony Grasso" role="editor" /> <authorfullname="R. Marshall" initials="R." surname="Marshall"/>fullname="Vincent Hardy" role="editor" /> <authorfullname="J. Winterbottom" initials="J." surname="Winterbottom"/> <date month="July" year="2016"/> <abstract> <t>When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.</t> <t>The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.</t> </abstract> </front> <seriesInfo name="RFC" value="7852"/> <seriesInfo name="DOI" value="10.17487/RFC7852"/> </reference> <reference anchor="RFC7903"> <front> <title>Windows Image Media Types</title>fullname="Scott Hayman" role="editor" /> <authorfullname="S. Leonard" initials="S." surname="Leonard"/> <date month="September" year="2016"/> <abstract> <t>This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.</t> </abstract> </front> <seriesInfo name="RFC" value="7903"/> <seriesInfo name="DOI" value="10.17487/RFC7903"/> </reference> <reference anchor="RFC8224"> <front> <title>Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>fullname="Dean Jackson" role="editor" /> <authorfullname="J. Peterson" initials="J." surname="Peterson"/>fullname="Chris Lilley" role="editor" /> <authorfullname="C. Jennings" initials="C." surname="Jennings"/>fullname="Cameron McCormack" role="editor" /> <authorfullname="E. Rescorla" initials="E." surname="Rescorla"/>fullname="Andreas Neumann" role="editor" /> <authorfullname="C. Wendt" initials="C." surname="Wendt"/> <date month="February" year="2018"/> <abstract> <t>The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.</t> <t>This document obsoletes RFC 4474.</t> </abstract> </front> <seriesInfo name="RFC" value="8224"/> <seriesInfo name="DOI" value="10.17487/RFC8224"/> </reference> <reference anchor="RFC8225"> <front> <title>PASSporT: Personal Assertion Token</title>fullname="Craig Northway" role="editor" /> <authorfullname="C. Wendt" initials="C." surname="Wendt"/>fullname="Antoine Quint" role="editor" /> <authorfullname="J. Peterson" initials="J." surname="Peterson"/> <date month="February" year="2018"/> <abstract> <t>This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.</t> </abstract> </front> <seriesInfo name="RFC" value="8225"/> <seriesInfo name="DOI" value="10.17487/RFC8225"/> </reference> <reference anchor="RFC8259"> <front> <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>fullname="Nandini Ramani" role="editor" /> <author fullname="Doug Schepers" role="editor" /> <authorfullname="T. Bray" initials="T."fullname="Andrew Shellshear" role="editor"surname="Bray"/>/> <date year="2008" month="December"year="2017"/> <abstract> <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t> </abstract>day="22"/> </front><seriesInfo name="STD" value="90"/> <seriesInfo name="RFC" value="8259"/> <seriesInfo name="DOI" value="10.17487/RFC8259"/><refcontent>W3C Recommendation</refcontent> </reference><reference anchor="I-D.ietf-stir-passport-rcd"> <front> <title>PASSporT Extension for Rich Call Data</title> <author fullname="Chris Wendt" initials="C." surname="Wendt"> <organization>Somos Inc.</organization> </author> <author fullname="Jon Peterson" initials="J." surname="Peterson"> <organization>Neustar Inc.</organization> </author> <date day="5" month="June" year="2023"/> <abstract> <t><!-- [rfced] Regarding [ITUJPEG]: Thisdocument extends PASSporT, a tokenreference uses the date forconveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered tothecalled party. This framework is intendedISO/IEC Standard ISO/IEC 10918-5 (May 2013), but points toinclude and extend caller and call specific information beyond human-readable display name comparablethe ITU-T Recommendation which was published in May 2011 (https://www.itu.int/rec/T-REC-T.871-201105-I/en). We have updated this reference to use the"Caller ID" function common ondate for thetelephone networkITU-T Recommendation andis also enhanced withadded aintegrity mechanism that is designedURL pointing toprotect the authoring and transport of this information for different authoritative use-cases. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-stir-passport-rcd-26"/> </reference> <reference anchor="W3C-SRI" target="https://www.w3.org/TR/SRI/"> <front> <title>Subresource Integrity</title> <author > <organization>W3C</organization> </author> <date year="2016" month="July" day="23"/> </front> </reference> <reference anchor="W3C-SVGTiny1.2" target="https://www.w3.org/TR/SVGMobile/"> <front> <title>Scalable Vector Graphics (SVG) Tiny 1.2</title> <author > <organization>W3C</organization> </author> <date year="2008" month="December" day="22"/> </front> </reference>that specification. Please let us know if you have any concerns. --> <reference anchor="ITUJPEG">target="https://www.itu.int/rec/T-REC-T.871-201105-I/en"> <front> <title>Information technology - Digital compression and coding of continuous-tone stillimages,images: JPEG File Interchange Format(JFIF) ITU-T Recommendation T.871, ISO/IEC 10918-5</title> <author >(JFIF)</title> <author> <organization>ITU-T</organization> </author> <date year="2013" month="May"/> </front> <seriesInfo name="ITU-T Recommendation" value="T.871"/> <seriesInfo name="ISO/IEC" value="10918-5"/> </reference> <!-- [rfced] We have added a URL to the [ISOPNG] reference. Please let us know if you have any concerns. Current: [ISOPNG] ISO/IEC, "Information technology - Computer graphics and image processing - Portable Network Graphics (PNG), Functional specification", ISO/IEC 15948:2004, March 2004, <https://www.iso.org/standard/29581.html>. --> <reference anchor="ISOPNG">target="https://www.iso.org/standard/29581.html"> <front> <title>Information technology -- Computer graphics and image processing -- Portable Network Graphics (PNG), Functionalspecification, ISO/IEC 15948:2004</title> <author >specification</title> <author> <organization>ISO/IEC</organization> </author> <date year="2004" month="March"/> </front></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"/> <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"/><seriesInfoname="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"/> <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"/>name="ISO/IEC" value="15948:2004"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <referencestitle='Informative References'anchor="sec-informative-references"><reference anchor="RFC2361"> <front> <title>WAVE and AVI Codec Registries</title> <author fullname="E. Fleischman" initials="E." surname="Fleischman"/> <date month="June" year="1998"/> <abstract> <t>The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="2361"/> <seriesInfo name="DOI" value="10.17487/RFC2361"/> </reference> <reference anchor="RFC3325"> <front> <title>Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks</title> <author fullname="C. Jennings" initials="C." surname="Jennings"/> <author fullname="J. Peterson" initials="J." surname="Peterson"/> <author fullname="M. Watson" initials="M." surname="Watson"/> <date month="November" year="2002"/> </front> <seriesInfo name="RFC" value="3325"/> <seriesInfo name="DOI" value="10.17487/RFC3325"/> </reference> <reference anchor="RFC7340"> <front> <title>Secure Telephone Identity Problem Statement and Requirements</title> <author fullname="J. Peterson" initials="J." surname="Peterson"/> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="September" year="2014"/> <abstract> <t>Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.</t> </abstract> </front> <seriesInfo name="RFC" value="7340"/> <seriesInfo name="DOI" value="10.17487/RFC7340"/> </reference><name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2361.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3325.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7340.xml"/> </references> </references><?line 852?><section numbered="false"anchor="Acknowledgements"><name>Acknowledgements</name>anchor="Acknowledgements"> <name>Acknowledgements</name> <t>We would like to thankDavid Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing<contact fullname="David Hancock"/>, <contact fullname="Alec Fenichel"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Yi Jing"/> and other members of the SIPCORE and STIR working groups and ATIS/SIP Forum IPNNI for their helpful suggestions and comments during the creation of this document.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+1923IbV5LgO7/iLPwgsRuACN5EUa2OpihKplqiaJGyx+tx TBSAAlESUAVXFQhCGm30Z+xG7P5cf8nm9VyqCiAla2K6d8cRtkGg6lwy8+Q9 83Q6nY0yKSfxobk4PTfH0WTSOU1HmTmP8mgal3FemFGWm7fJYEy/mmdRGW1E /X4eXx96z1ceGGaDFN4/NMM8GpWdJC5HnSKZDbI87gzgqQTe6eSDYaf3aKOY 96dJUSRZWi5n8MrpyeXzjUFUxldZvjw0RTnc2Ehm+aEp83lRbm9tPdra3ojy ODo0UV5ufIiXiywfwoM8vvsCduT+OB3GKex0ubFRlFE6/LdokqUw2TIuNmbJ ofmlzAZtU2R5mcejAj4tp/jh142NaF6Os/xwo7NhTJIWsOmu+SlOhyX8zXs8 HudJYb/L8iuYOptmBfwRT6NkcmgG+MRfotlsksTDflIW3UE2hZ8H2TwtcZPv Ltz4L7vmnCCfpXaKl1nqf0lzXOZRWrxLE/pGJoLnuvrcX0p8YI4PNEy3kWb5 NCqT6/gQfnn7/Hh759G2fNzZ3u/px0f7++7jgXzc3d/Vj3vbO7vycX9nb0s+ Ptx6tKcf93qP9OPBnk7x8NHWjnw82N7edR/37Mc9eu2086zL5FMmeWcWFcUM kIS0g7/+tHPcuXh7ih+NUUKeA3EW2TwfxOY0BTLKEe30QJRfxeWhaY3LclYc PniwWCy6i50ugPPB5dsHMNCDFj0oODf0B4E7SpOPAK0sPcQ56fshkOih2d7q 7Xe2Hna2d3Q5P764TNJlr7sdrgrIPupPYvNjPCjhRL3Io9k4GRTmPrywafAV A++YOy30xxevs34yib9muVsHnd52Z3sbYXv57uX5yYtgnS08zkQZQHJlPBin 2SS7WpqOeZZcJWU0ASqazgDAeGANnCT4e5ikVyYbwSc4Yuk8mxedEk4XHN0E GEIyja5iOFI4lXkOqyas5INxlF7F5jlNZu6/fH76fBNX1Lk0b2OYYwrniVdx 2T142Gub04s3D05Pjk1v61HvoLPXMrfvnYYLkbXT2drDrV+8OT97Ia/dtvWO OYY9z2HR5krRhjunnZlZng0QHAADePIcqJPwfBaXwHk+eIiGCTfb5vk8HeAM AMliFg+SUTKgGb0N7j2C4wWY2r0DeuWlEMW7na0dYJq6He+Mu4O9Y4/aw51d OLcbHVh91C+AawzKjY3LMfA0YONzwEOpK41h32Ze4K4B3eU4rkiNcRwNAUjw 4GQIPwNekxR4MpxYWFlRERLm/tvjZ5sGTnQ2SOD3oVkk5ZhGTYRZ6yxZDrSX wk4AxjNg+ksYF77EucoMEXANb+BHfBjQNA0fjswwLgZ5MiPMypgohuD9+7DC yZwoeBiXwERhi/1sXtIzIGSAkZIExD8LpvrNroGVG34RtpV4ZOPelfH78TJL h7KwSTwb48FI59M+/FbMAR4RwpRl4hVx+zb8DXSXtQ08XML/YPb3x1E+NFn/ PTAPWBWeP4QQvOGmapvFGAE8iFJAxGTmfhoKHIaARIDTOFsgrOD8DYFOvY3B yL/N46LsVtE/jEdJCjstx3kMq48XOKDqB/dwjg6D6l7b3LuOcySVIXzGQ3Iv UR58zwJyDdXgK9GkyAAIOE+ZfYhTc7/1fgAAaG3aEe7N5kBWRXzPrUQR2zxw 15yWPLCQS2Gu5skwSkFK4HGHF+dFXB+jaSJaVNu0EmB4rS6fnGkyBGhubHyH 3C3PhnM65BsbF8kVHHWixRywOcgmSDA+LTCfKAAf1zEgHp4s5jMUcjGTzTCe wAnO6TBEDG0lFYBonk1rR6RYcRrw+zZ8m82vxriIGR71ZEDf1Z80QAHZqATw T+JRieMBMGEliBmY200tK+owkQlt95coDor5hMZDiobHTDQcougw/Sz7gHQN pBrfwMTIDYF7Rf2oiLtEHp8+iSLy+TOsZppMonyyJNoGSsjxTN8bJsVsEi07 DImEkfgcVxVQ1HU0mcfNgEIYrYRPiQCIAmZWmDQrUQBOsxRWQwppzDRrgQWn cxIN4FvYHuAeNFKgvUs8ZAg03EA/JtDAZDmiOJ8T2flcRPay4ojArwChlYf0 rvzZhzA8kS0QBB6/QG4PAMrjQcxYn8JeRPqPY1g/fgk7RwTCXyjzirjEiRv5 PJ5clAZTnaagI2ll4GSytFvQL8O9NO+jLZzCHc/7AUfaZJbyrbnJc3rVhz9O M4xnoLaQOsQonGWTZICQVKkDtAMqOYt82OgSCGja9iQAHyLQ1AFDQCgxiMSY FwkDI4vKYZJrOLTmfty96uKriGP6AWAF67j/7mhzkw6X8hbAS06vgKzB8ZmT OBakPwtnzOEE6onTpVkZYleGR7eyIoGmzrp6AoN8h4HUj8fRZKTgAWJLZgnu wpPSQOmnobifxcgMkKGiPGQlVOEKs2VTSzOoO6GkHER6UPXQ8jCl4OYeGBT3 zGASJdNCyJAO2qdPqw2Qz5/bFRKwcnKRIatLRM8LBaYvIqsSkjgFiCFPvJIo 162y3uFpqciWxhEiBAgbdQJznURCExYPoEMgpcc30XQ2iZVkVMViQo2H7qDJ i6DEd3QMXGI+ipDszs5ON3li1PcjsFlhQN4Rk7VPbgEoxdhDfgPbHs1zom19 xB56wHF1n7digllssArSy4fznDQ0UtVY15kPUF0fzSfh47L3FgzXUkIgylKO ncNIs4xONxCfVcJ4c2vYNSKkJKyGdNA1GxvvChQUsL8SqHCRCj0FdgEqyEBd BYO8ptO9O6IVElVbju8wj2+DFGqrFsE6mZITcyTYWANpoV5KRxzJAE96EQ/m SKTM05Zd8322iHnIAsUfCTIAxTRKl0wvQB8pDB0Pa2yPCaSQ/XqT8D5gRyho AexXc4AXjCVCNI9hgaKv5Gol4sGewZYikDqJBychcCBQPOeiK69AUjEmvkYK IgLMV+F9qCAyLy5P33aUalWrA1ijakdEjgYVEDmeOavKeIQfiDxQqUnd8BRQ xISwUqbG86OLCyD1y7szJmCZRxPSq9D6QzbeQFhC2XOw0pOPPCpg7L3Yp84a c4rrnef3JU2T2HNKcVSO2yFE5DQpn353dqryxTEhwXBNZfUFXBoy/7bP1njA tp3ELWiBREYWI005jZak85FyTgKlD9ACqoKjRexj2YCntumDEZgQHVv9CR+r njGrlK4yhgKQ11GoOmCIV2vgIAj0YKiq41sTbFWi3s2HRiihYD6J6uo0RjdN UkxxKUzbB3vbgF82NXVxoBvGUUqClLRzUvmd/KMZ2DLmI1XY5YjiRa/G0zgH DWawtPwBdBzaGtHFp08XMVPmbnfX3H+zSOP8wcW8j5Y9Whye92aTjpEudhNZ R5OYjhoVP7YX7pGO6ExWUn5hdYDzQQDEKndgoDKsth7tsWjyZ+8Dw80WBSPf hymznJlHYWrqEAALINZBOc9jdhn0syEd6xr7IHoEQ79l3r09NcVgDHDledDF S7zhO3NJJ4f9W5++K91fn5GkYvMhXhp0nBem9frdxWWrzf83Z2/o89uTH96d vj15hp8vvj969cp+0Ccuvn/z7tUz98m9efzm9euTs2f8MnxrKl+9Pvq5xWKq 9eb88vTN2dGrliV/p23nZOL2hSuAMCYFrxBXT5+PzNPjc9Pbhd3/N9x+r/cI wMx/HPQe7hIdoyWPk5FFx38CBJd4cuIImT8aR4gXdH4WJOxAWCzQx5LHBMs3 10iu8aJqkLlzCLgG4iKRrPQkyFrlO1PcM8eoWsSs7ax4935V58J32kYPz/ZW F6Cwuf4QgGmW2hPsfGx4rn2vie+LsN4EVpsqBBnfJAWx6Vv9KVWdOr6ZwXgF TpexLbScMb9A2PTFaGQnAypYbgIdlq29tiyr7sFqf40LazXiQI5cifTEFVZ5 eEz6g0cRVfWA3gwFyhdI3i6f35VgVnCgpjRH7ZN1RHbB0oLzeELGkjiQqr7Y 0FCVLSELZKuygf39NE7Yz5jH7FJp8Qp4PU3UagWMtTZ9h0nG0hikWwaImsBB pfXwhlk31E3yFElBTII0RXJjgURngcyrBeIe4RKrstbSICIdiXm9ok+B0uNn fDgH44xMYpWyjfIbV4bnCeYEQiarEX8vwTbgt6yVUairTDwtgNFxNsTh3cms +6EjM6NQIKqT/XmB572oOdzZwCfSGwOxkiX5BYqe/1o0zGYlb8bqrEreQArw 0CDymIL17ry8eHNmfor75hLxBWL/5U+Xm0JEe8i0harx3K4AviPz4DAj4VzH y8LT5+8JNZQIFc/Dr4SN9NXoPp8DAeUUPRadFka5YfeDDuiOCB/l8ZKFCaqR C7Bj6LSlxUJcOuLduPvWnOPAV/ISMEo1iGS1dlZjWmiVIU/NHC2J9YS+WeuX WmU5k164wJMLlITkJaRKQQOEx21+srvvzWOynuR0GmjAqGjX8jzS3xjVI8Be u8JvVeoddLdxpbe7c9jN2xSUInw7JNsYM9ikAJ904CCDeted/QOkQhx5Pz4P dIVj1acrGRZNij/xh2Fxi3zqsxMXXkFGIs6z2SRGThflS+X7KAqckLq7/DGX yxlbcuJo6qBTf2hjTEl6nU2uAbdTjA3AvGaczQqryA6TEYGzDLzrmLfAf2m4 hCmrSZSK9S2hBrFmxOMRxP/yPBH+Qwc2YJ94plnwkYMQjkfDGjTitoiK9F5p Z7QIx3QUUt0CNMHSV6plXqRtnVFIBok9GMy8hEyI+YnjCrldR8V5dXthLMw7 8jic1alCjaqiSxQ1wyopBnMLc+H0VvXjd8RPrspng8pG2q91tzXSIzNNNIXI WJeYk+iEgYOUlEX2VrK7g7Jipkl5u+OO9BlEn4ZFHcnhNOHZu0VM6oabAr0U KRqwp6/OdSS2y0EMIlSRWczwXFzTAT9UFRbRMjDMG7xac8peqKtuLJqaOUEf tPEGs6wAaYHSr7iD7kBHUIDSse5fb2EMcXHg8dElBIf6HCAV1z+fsLlm/X/s eXG6qvj4xLOISE1En5xGH5ATLisrwXh5QQ4rZmEUIR+CGgCSvG2G89mEXEsU oQf8jeBPInSrBNbc2IUGdCrrB9bB4iOStVpBRLkfYHqiH4/5kORVuFGz3OrE pIURhfOhJx+Deufhb0u8Vj1j7jrNhvxAlpKfDcNDwuyG2TRKABNHAB7Pp6MR QmHnjuchhaJXz6i/wNDgy7UnLceh/eGbHyx848RCOaAPZRXr/byhReE2GzEz tujW7z1wt6156+PAbjYcmeFK+UC1rI0+sBRrNOPShzH7YfQBOGfRxL0XhdKL DjHuVPgjBuK6xjSoBdHgQ5otJhjhUYUuwSB36XNpPJ+IB7axrXAp2rQsKznx kPCm1JcrQXHg38RuMIkSxp176RUVl0eTGeQTHDp8fd+xDUHBXFPkHnD60L9d WI53x0hdHPor5iqn/DwCUZtl6noygW+iWkVQpEPF447bplAkBbsbFoBGwSDz MynOO0cF0nI87Jw+a5p4ZzuwqBMCP2ISMTjIZrHojKvyBpDACrfwJsqqQ6MW 5cxiC/s1A9WjazAIg5flDUXePYvGOp82NjC6jqKxUNnoyfDQjgncEQzkqjrB fqUAdZ7zQ4wnVCNQbx9xVgqn9lkd31cgBEDOQ0IhcCdsNAhn6eJ56Ou2sAgy BzjkQaoJ68ks68SdwTuobswxM9qMs3y6gd1jlbxxcjXuTGIgz8CLx3tlXsbZ OunQNKiNKzNOQos7UrXOaYvrnWaiRbrHVS+IRMexBq5At5KWJ1a0+FkonW5d kopTnG3kqxKtslLS6Zty5IKsJC8nUjxaNd8jiwk1GyueSnVSVdGaUN4Nckt8 nXwjvDfGhK+hMem4FMhGnovPpFnaEf7LYwGq86Q/LznJR53mzR6+qB6/lfRf 0fa8FRDHs6FiFYXyXgQ2XmozQ0M1D7ebzSi1ltKMrkmAilaRoqOlYJouyGJW 4DVl6pEXiXXXpp8rflA5/4Wm3amWeVtiajVnhwCFB59UoJUmHussgkoaZgW7 xliExylrLs0ITTXM2yq61b2GbN85RIjdcSoEczvCxCxL0MGI/pUKx6PDxPRC ZCgJqJXgFh6pISY5LGeO8Oh58o+RatTn5DDkDTNWmwEiD94XGmemVAOXSf7u 8nnnQF2He49sEO310c+kYRGDAN00wdQFFzNeAQHcqQdIjKb5wTGQ3Hoo0I6q zCFDY7jNT6oT7g5PRjmPDMtbnwGyPipXVR9u2Q9BlU43iw2iXCumQMwmmA1u GRA7ymT9guKqIwsTysz3l5fnF6ZMJDLgsnJ0SLUINsHyHLUVPJ7NNJtkS47c pNdJnqVT4X4AtXYwfV5fWdVgcokgoh3SCLV03TrD/gIPdpNJACfqqfiqfS5a leA1Z77HCCMySifoegp1o5yTtCcSFw9NC+c7xpSgIOlIx4N9WqfOCgIh4qCA pqRoudU0Z5KL8QnP5Tm6qonfLTITs1tQvG38oxvc8RIZfJTkcCTkJcc1RYq3 roNAHIkJdPDo80nhVmDllJemF0JDlC+ZWdiyvzvhimI4ThIw8VsjjC+2KK++ RWZ7C7VMEAIjVqHskoW4RPHyogOkFgNAyTSA79eo7PCrEoyoA9XwNHsm4+sk mxcq3toMYKAITGcaGavsZpylW49LoLtsElN+tJqQ7uCTkyFYvGjUaEKlmhO4 VhAlxeHGxv/w/tmwDx6aP2mJkoyEpWYPfusDSxqMu8jf//xYgPCEBFg4UGUJ npu94CW9e/uqA0v/AJvw5BBF6xINxDtBWF3nL0pyG8b8QiUy8E2co+7San/6 3G6hgGq1W7vdrdavbXlgFP72g3lKm3EPZPlV8MTr0/3H+pS5mC3NiwhM7bJw bwjB4TugF8ErTUCjh4oHv3W29/Zv4N/uLL1yQxCd3jICWUwPpsm+HeL97KuH 2N+92d/lAeD9Xzd+XY05lIenZz+eXp6sE7OhzlJFFaxQhiiS2SHImkH8F29h OMeD7e4WPvdjEh3q3w8uX12Y2WBnpxuVkwh4Xdd76TGT4ZOPj8Yvdvt/TaNi PCwOcIhLoNwjnMP8qXG6P+NDeMQPzdOszw/1tnt78E9va2vLf/Qxmn9PKM/5 z4/L6OpJ79H2wc5W7+HDXRqFz8qzQxMd7PZ3Bw/34/39h70t9xMfI4TWYVU3 alsC/qWRcAmxQr3rCHc9zdIoId1+IcnOsRAXRwHmE4GYzis0fGfao0EaafhL yJdGqdDwr7/+a4UTPfas1iett8gpP14jIwZ5TCO8SsqSCvmAecZUind8Ef92 aHZ6u729R0Ku+PXr6KYDRv4CBi0OzUPC7TOqxXueJ22zvQcmwAzUf/jQewR0 dAgfXrymwsRjlM+D8rBOYlcwwCJadqtUecz8sXNJxdI+xRTD2QYVCV4/oSVk T94BaR6Z7YNHWwe7u3vb+/7H0zNzer678uzgAMWTCzH0Lp6d4xeDJ3d4q3yy ZWj+6ZNoPkwys/uo93DbvL08f3D04zn/FD3Jy9k0mh1umfPj1+8eHMCOv5S/ VJXp/2Iva9gLAGvVDNVjQbS/5mz8U5wLDi4DWwJWchMPH4P9hnGbfPlEP/T8 l17F6VU5PjTdLqhF8H2n4x67/dD9E5+5L9vse24/YJ9AuvvTKrKisW4RYHeQ XV+udDUILxrkNgl2i/CiMb5OAfOEF4vsL1TAfq0qX99VfK4NjTvEWeu8qg1R 0xh/Ldm2HVKUHoxCVylJoSDksJQEGfrPxCGPMQzKHeBi1aB0Sf3FoS94bb4Q LlJsm2CDbH+Ge165M075Qqt0TE4RIJh5NDFTOFfo6C7mCVfoU6IDO/M5L4sK UbigbZ5rqBysLi4f6ZojdIdRDnjEHvQYTBMNj+jwku4M4E0zKuflkG1q9nfN YBxhvA9g81hnFjiq77HBrYAg7tNqBxJzyOcpRSxkShcbQV/JKCnBOmffzSCP 41RcZ7q+NQlxEoobMO8NqstjyjNgCz2buRgwY8A36TUpLEid0MXZch7xL5aF xcACe0UgUdriZ8mm8os8YHTyVorbEQalWLrk4RDwJDiAYIxLHUNzHihYxuXR uFiKmDU6cygBWlDddjFSpAoFt3qN0H1D1iqclMKFUGcZgRTbPDS+Rv4G8YF5 6etY4Q389gNS6D2NRyccb8vmOWBwyJZ75NyFrspjQaN7qQAujmADmxdzdv6s jGu6I7Qq2OJKv/qel6xxYMwNLXApE9YaANJllmOCmGbUIpkkNgFNAgXiAAtP gvpOCvrNAVgGGiUIEkoCTDBaEE+pPms+FPcJuwQl+NJQsBJk17icyrs7ShjE 1ofU8thVK4iGNaioVYWtSTa872fpsMmp0qCzYdBxCQRj4igvyF3XCqbDklrG ZxHblBlO0CbfXlThtlneGKvlIv6lGc2pMsWrW7Xioe8SqzkSBfCPOVs6sg4y NyCBL8388AtHKrBthjpN4Zs2exgOXSa7JMbBb8we6mPbUoBVmd7tIC3+OkuG nBYkyT2FZvrMC1shZ9PbmmhYnXu2tn1YX1XRNSRZLI2tJwza9DfA/3c+Plfo D83xeZtnGuaOFr77TjiI4+K3e61rYWAXmRNfr6sOtzleQbCAfd235vXZdHWb FgVrXJUATcmVtbJwG16/PalYaJG8uAPhH80nKV3NWRrTlvyC6SosmF0DkFZl XAFBYADHnfqVc9fc7v48a8sTeQWYLoLpsS4U0bT9dgXDWpBLxc/1nLdFxGlH Ul3JrMXiszFSsArDX4lWzUAl0EkUgmJkIgaawsfNeB+Ze5ilL0qulB/SN3c6 An7CIAdkhuuo3+XxR7fVwvsA90JFFUV4BiJ3kIhsXJl65AW5gn0UfkWtq2Jv hFTiJWJyvgxnjBFfQZ47Tma4iMWYLZglpRKszszZ2DgRqc5VvwJNrQOVFTzh GgpfMvgpSFFZbX9gactxGgd0pAWX7iax1CAPibaPEZp7GP1wYzhkTZZ2cYfm K7UIsG2dEMHZWIZUNl1TGfyawEoQ1mlMpCuvJq1KkLfN+VaS2Re2fFlFBqqN hnPa89/yk9ha4WSYoFIm2FCBCjdyLYGrBcmOz45ed62exEob2SCujQYpjAuK 6lFBcMyxftjP2dkpx8+DbmTa/sQyBDdqLTO3W/dgnnMRA8zyPR0u/O4Td4Vr RZOr1mHr5GJ7b19cFaZVLmfwnfIt+/VsVsLXWGCo39zszeEbJZYB2LvWwYQt B3WE7iyekivlM60mWk6yaOgvAhR0GPpTq0xbh7+0eujZI8dQr/XrZ50LWGLr sLe7u7O9dbCzu6dfY1smfdV7c6tlX8QFwwOAHnjiZYQYfAqU3Gq3kkHqLb+R 1lufed2hG+WyYl5aBIlYKcSKFdexZqrYLCDhcSLZLIupJVlj4qPSpha6NPdM UW1B1kHJDlg4JllaRGXWDnNeC9chIWCMVDQQdMDB5FpJqK1MRemw3KXLNi2i OcOIsi/6C82f92LU+JRbkCY7Vc6OD9TQIK7VqVUzQiQAsMhWpYiDNu2nblSZ D5Ut0FYG2r8yKGKOMJ+43agNabMo5s0o9ylrX4ooq+KiwTlSq/mWVwO7RuUM Zwv4Gc51m1JSBrDa8zpe1eVAtPJrcfBwAjjS1erMs4ZlWXOrTc0xRtF8Uvr5 MJqeRiQ3HLJBXROhTp1R7SVIN660/PGaX1G6BYz9YH3KRV21R36MNLRC+/N0 AI8mXZIGQXZ9MEmSHf6Dw0mtH8QjzhGRhkm9oJLPHu8eXZLWsxxi+pLg0u/W Mu5i4ja98w8Xdvp/KDJUCzh49bmr3QV+Ee+d/AUuBbBiyrP3IOgMJK4E7NWW SLM25Ytf416o1wC0xSv1RQW8atCsKAcGPofDjbmflmcVVuqXpdSCDZwB1mHN MGwxoQ5tnz5Jp2v0J6iVun+7leq5TDnXLPBrkGQAWRKWf1yhv56tUNcbF3+i ZYKeifVo46kCjQB2r3NPo0nkEBy6F9Qattn8rBNQHhf58tEEZsexOnBynwE7 txL/pJYBEwFOEdsipDRGmwOLmEFLAFzE6BP3ViFOBcmM9CtMrQlP3sPjqv/A 5tU3OAvugIZ2zTnYnEFKmX8uFFQFeWEuvj/C0GKbPuwc7LJugX/s9bap+gtD cNW30ApmnVW9Xa1iHJGlQJ9gIO24A3/BSPBXTp2XOBkZfR2uqJvW7ZMs+WiU SDRcGJwJxrMtmMFnhhn5hLgJeB800jj2uqPUShTD44cD2NIkn4cwmm2hjmSH +95h7sIa5tVqkYlTDgMWo/M3Mzd5m2YGQJ1lKGh4VXB4iqraubr3oyhlaYW/ Fc6rYwsPK/aH65xsH200PQIPQiLwmF/hgUenyrzEajSgomOPJ6xUEq0npsEg 8nrmai1PpSesuFStg5BrCIGSVvdw5Gfceu8n3bjbroMaIdiIKa16jFwLUQuv JkfDpvGUwypVNuiE//Dm+SAHO9msT+fROdmUN2yQGzTmVReqGfNmlTWvb6+x 53Vt8DcZ9qbVmNTRtk+RrW/unkDLL/qTJsGsD2RAZoidt9n7q58W7/Zv3pWn u78dbP/xw/fny++nvZd/7U8f/nF/f6f/+vrjcjr+MNnVoZscC0o2IaOpuhLc yQrt6pw82pSHUevK+Q9jj6wxMXqrTAzPQmlEsw5kqSUYiODdlA73e22VJsJx 5gdNS7ZLxQR5bLnMk1vIh4ZYSUO3mj7rkvEaMlUbTaX/Mq/+sc2rd+T2Ju9J ak5csoHjEdJejA2tBk3eOs4pDyVM2ao2blFNmD1zVduguSUb6+0a9ZlGKUxn y5fJjYjQkwK+irjXquo0KRP/Zg4S/dKJg7qhUKWYlJqJPA+jUFdAdqxrRq55 fH1gTgiqFsdXK68rvkJuAr46M40bTdTrhcNGI/otleUlrs+rhATenZ2q0uL2 Nctmc623pipMiWpSV4a//+1/wsL+/rf/5bQ6rc60ql3iR+QidPcms0janKPO x1QijUGqzeKSVBTztQCg+JyrNIzrhWyq3tNGkT9Yb7DXJV7Lsmo+YVumbnXl 1aZARYHnawdW9QzBKqGgI5HtPNVwQIpKTwApDOVzaX3GckPJioTEw2+mNzYq jqs0xwbV8ZvpjqI8NqWV2KnuEP1ZFf65Q/xHA0CquaHHebIi7OPXnznd0dwp UCRPB9MGKiPojDSz1RlX6IdNukDLG+T3Kp7rNc8Vh+Ercotu0Sa+LFFNB6Mt PMEBG7SoOwKUxrBQ/V0O6dtSpxwQKkvmdO6vwWGANasAuP4MwGXOufZ12blQ OUcPYW2yvVSKe0r4HjwrFP0bLnJ2uFFxbb29IfnJ5PHmXvGuYdsoXph8PokL tkVooXLJld+YghMj8riWpRR0oQi71eBQ0tEIdJR5HjSNxcZI0/nUcP8SyjDQ RGFvo/Aqi/6Y+nOHbrcVXjdNNRpSR2d2E9vLvdQbN/JTddXZ5TcLKmJ/HSqo vOSWnFOjQcBTjwzK2Z3l1M2S2ud60TDXBlyuJ+Erh7wbVViWFn6/NU85LtpO StmdiJrFrvcAK5Igj6/o/XYdWsHEroiabnhESjombIXQuLHxE7qucF0AJeqU zjpoLlFdUmro0bbcq+TyPWAB0o4XCSZd4qsdz4mOPMlraxrfoGPcI/cym0lP G6sAk2RglzOljjLhSX+YsognI9evy2al8czOfV9QCjjnclMn9LY3Ct2xhlnW 4SsNzZ75+UpDLiKOIO20r7fGSfpkNYqAUVaCqV249ECmVRc2xswXZNieG3Eq ZQOaBz9JYgtzp/3L6P5OAJGcX5cOteecrs1ve5SMLOQQ2xq51zZ8lszwAanj lmHCHF09mdxDAR/J8U6NsddLBndItBXenxE03PZA2HFeYdfx50vamCrrQTD4 GjXXztgcZr0JIZ5JsYwHxIXmNthmg3gNzzUlc1WrHNjBruwR9kxNUKtNEBpS 723fI9fjSFg4smkthCAGhL5qrPCRm3fkBclk1oZwPFnYuof4rY8IB9zwHiXS 3R1H5yPpMSlN6aCwBerGePOG2IzEANGSuCWm5TVMr3Cl16jYczOaZ2ySaEcI ybk6RQX+03dT+1wHJ/zMDccq+Wwr2ohluVcLgTkzLneQ57IdHr2bL7U0xDLj oVymypej8rUwWIRXuKgFZi48hRn2d11rnPv2CgwOOsldvJ8/b1abtNVvOdQ7 UxK+HWsB2LOGtERMtH83EMsoGqD80YREL51vGMtiuE0Y8geHQKzEcFtiVLCh CTwKTpKdMfgJiRQbdMCuKT1vHOTTo1FGx405A1Gl4gDMY8tjPAEoLeT06lm9 aFMRJwWCHPLiDiCOjNuqV1GKi98crfCKu87PXiCd0jWy2Asw5/tt4Su+VBeD fkzvRUz9KrSvldwdqKFn1S+2dzt9EI1vXzyVVXeNueDfCLoTYsM1+U+wpAF1 IBhlGs3M/aevzzcVF6yYPdrawcb6nNwDjB8GxClzCsHJbXK9fVxG2xzw/2Bb Pfy0SR+vUHkEJhW7H0x/Eg0+SLPzpMQNTlxZHYK+KXPdVpApO5RUbnufk/C2 9gqi1Ss6cgwdypWCcLRQgZfbufAnDRC50KVCTY4oiVBeMNV1wIdOtMBXRQ3C u2say/QQ+4pypQ2mLV4VaCkYkMLgqVWvdKTNbpBJ2zbXfCO0nps8DvfCvqFc a7lGtiOiV3vl0I/4IcVNhlPODnuVWDaW6DkXCMZoJ3PpS40S+eJH3RLlLFxx RcWCervJHJGLXysXiaTt3pRrD/BtXGiwta45Kp0iz8cMZ7N3X1c7KofXaQPt uuPn5KfkVXi3DcnJ9ZYheO86Pu+zbjni9oyGuhdrsgX3nNGIdlHriWntI1vj qZFhIhy3ckztAK6aki6RpV7KJEVbaRruDo06YZ/1OcoVxl+syJZe9XxxFctV 4IZX41LuEBnCKdfEbNpfLTfTiTFKDky0PKXahtY3VBy1sEIBO4TzG6gPyqnt j5SoOg7AbItJ0UDxzz37NZlyWcE1BdZmx3IxhiF1RIzW3/BU1TZtr1CJ4OQs JGFkkek1sHpHpe0YPktu4kmh/G9n+2ZnG9jg9sEN/Ns2e73tG/h3s9q1j2Qi 49dxuBZuDnHX+f7mp1ZbyMt+22JDdp4mv83t27W2wPh027S+b/mXf3joxXt7 acmSsfFT7UGGg30O2Q1D20NkxE5ZlOdeU0DLFaRUn865oIO62ZKGQg1+o9IW 44b1x5ZJANo91ujxGdI2wArTGwgFqsTGhlYicjZLLXMV9uHdF2Xv++PTSx/p +Nr2YJzuwYaLYErd/fSbIseQpMXCX6mKCiQ/p285VcPthtkY4FsHUOqwA8us 9Y72hB5vKKGx4Jjr25YnOVZA7RaFbHUy9G95fxXXVySq7RfvZ1d0NWzltQ6R ffiy9B9oGLDyFowZTOIaF2wGbfTYuoskA/CGL92iK5OHcV8sqxl6JMYC71g6 i2ea8043Sy7ZKwe8cngdkZWVaAtbTy+1df1g+tHFZonl2RXnD+eTUGfxpdxJ K+qB1LSGlzewFj+cw/FdInHMp9UHWL2lsxrivHDqHHVPH5BYH0yiQi7As0pd Vrkcla5sJ0HEDZCVFvwTHSqqdMEqsVqWeRycpG8qt2c29S6cznbaZrobkTtn tkvoXUTXcsqkayXGBNtYhj72bqATQ4w4hblfuXVW7vIzLBZRjZUiYA8aVKi/ qXY3mY3rr0A0zxlNKooLd+DEVCCbdG7jq15hvlq0eVJ8IAwgzRBPZ05nnZjE 2Hy3g/Tl/yiNE1WkUhN2skmPKU4ZofNvY0MduZgNJd8mVtUb6v2UIy4uVlnc 9poduWgZrMQ5kbzwrWvoPKpf5MDVke7b/Z29LUSejZLaZK6jp2fPzf0ilt6k e9s7u66B7U53HyzNWgjhjx3/n/CvO/3zRxjk332IwV+v44g0kDv/8+/fbiX0 T0+GxWA82eNIr0mK9z8N6DYkAbO62kQEd3klMsgfencchHvOujH8QXp/kEHe eA5WHaRYtxR/Jeaug1SX8o0AG+Y7fGdOJSFV+PC5tb8r4WHfMOcw/8SrptcU BaXocTap5EgGN2XIZYT8S1OFLsFAYgDFvC+RZc/HxXqL+P7qV1KCFImvxa3t rHX2hWD/FZJPnqMeL4H+DqCBDZBsvIcj5PSVBmWCyyS5UzsKTOyv3FjszEWM vF3JrnYeKqcvAnrfqjQ5dJB0R36/u93tkZ/tR9KfS8rDOdJsaVqApr56B/gQ iLYS6D7R5gbaYxN7KRlp52Rar/OueZmNU/ND15zP+wCgf22bk+K3bqvW+wjB VYdWI7DYvJkCcLSl6BcB53bYbK+Gjb2vdeiDyZxEdK+hrMlFEpzujc8VVXj+ obcOnjVwMggfI0Qf/zBP0kmUPgYQPxaINr5zUaIvpshSfu18nEySWfscjOnH z+DVl3m3/br7rNs+6h53z1fhJRl8YFunih77QzOW1pCyvPmNMLZTw5jPER2m CtseS0Q8Gh1Hnnl//90ft7a2jzdrmFqLKAVDBfZvs34/iRUzKx56mUzb8O/0 1gcvfz4/eYI1nodPs6JoxpS4QCtokm/rOGL1Elsa4xPkHwtYq4TvSD1B2FGI k232b4M39vY3lKCHEXCJMrp7EaYYXKTILW5J47GSszZjT3J48YXn0VYHMplr uHF15NSqR9hLwVByja9BQcRhrDtBEkytX4EdqVvbuzf4H2ewNzIULE35ElrT NtdEGtRxjvOmDx88WCwW3SA54rcZMYyw9V2NbMwzvfj6iO+6QzB5kltazinx YDM3LGTKUxWxYS5fcM+svVNbrtFTsqm09CbajYZ5jXLpu2besmro30WRO+vk YiPvDxkKeT9PXp8ev3n15qzKVnae3p2tEK5x94Dpv//tf+NK/v63/3MI/yIH aDm+QLkqv7SQDPDfnd7WlnkNShAIJLBbSpCPR8D/YZ1n6Lxq/RQVGIcp6U5m GPjZMQzZNpoWtb21tXXAv7zrXnSPutInOqQZRguny1HXKxP5wGG4aAN47QmH AXp0AFRFojkVCxC9t3wo9VXBKDePl+oxNZ5q8yWFzhJ2vEdVTQck0xVFtW1L LhL7XsO6mhMaOe9Q+7Tp09YFqcQoVXHfGL2/rMUvYrJ1MgWzr7B3Lwhi3wEv BUj9FdY0zKatX1dTwh1JAI3h8PqYkGNUMmfsVTTo86CIn77rMdZ1J1d4BGjf NR5B363SP1RZF9ewoul3MYldYRJvqUPNtfXCYyVI/XIx/7Ytn1NKk02+ViL1 KKq2aNt90DLXyhNMfvwMdnywzuE1CTlCH85v4sxG+akC2PCiRS/u56dHe30p Er7EMKz8kkcpScC/Ip18yf7VjeVA2u1RCmlYFtx0C7W9bagGGomCix8GKxXa ZhTdtL2mjpwSUHDOiW84au71vJ7Gd80qiab4ODi6TnLKZKjVJhcCCsJlCsty 6qtGX/2ciRhWPMd+la7ZSJVAGsOxckukbeiE7T+WXLRJ6fhJvKgIuqdLDbNp Qpe7AySP4w4ntDnJR57AfjT4QFnhev0wq2K0P3ZO7WwymBI/YIaHja+/cHWf GkCKb2Zsjdt+El5DcO0oStRJ0Xi9sssrbXi0v49+A5yVUcwv26uGME7/RVoX T/aJkrRjKp27xpvgW556PognE2KswEhGVB/XMlZHQzaMgxz+sdfZ3tru7O3t dSgR+tcVwwOFtn41no5Xf7nXbALE0yipM0n5tplNkvcjz4AfG3zsm2pUu+us 6dWehrXY4M20sRKR4NWqCE3TUtX3LzfLj75OLPB2AzCyAFfB21Ea/9swC7q7 NwMbLPCrGqz5y2ZQ429zYCb3i03jN9OkzBHmUVaqgtZxJ9l4BxzsrsaBrqhT RldfgQvabBUV9hQIYP058Mc4FUTc8vZ249ujfMXbY7BPV79RU2BexJlLCVmr vtib+Pw3ggrOBq/jXdSZj3Vt5uNKZQbTZT5SPu43OJd7osS40nYXgSItCWbr 0Gwp1YRiewBJwEc7M4nSiGpN7HNVC/fSz7fyRInvNjtlVxlZEqFQcNax4eYd l8edbDTC37+cRgGmFV/K0TTGdsUPzuLFv/2MNNd4ugHdNfzQd80IuppkfZK0 XCDmJUD+Tkyt4aBf6j7A5YfOA/jmcOdhd+dgf6u30+70tre7Wwfbj3a2m47M m/wqSpOPkWTlrD00nBm30lNQPTLWWMbOuwMnfLwZSWULVwCssqwLquiWY5eU k7ozU761uB1HrplNqhEDwLZaoIpnXNX7rP9luG5G9f7XueXXEz9tq+qZhAVF ORZqDzB3HEDefALyrAFQ/OV/LpzqR+IugFoPKdpX1eWeZ7TMV2TSrVACKNe0 qgT4CahNQGK1VZqUi1RRh+yIcjmvsi+WK7cDru4pX8tMbhH+dAHGXXyRUX+A mdMdcZHKFWSrBqGSNYLFg/ez+OpxnzKm269PT4+j98fHR8M3V0eL06dHV6fH qFkf/XBy8vSHo8Xw48mr10cfXhz13p08Hb8+/vHH1zevnh399vTq7MenR9nl 6dbeZPj92fuf/+Xp5PTk7Lr/U6/Xp4rvCXz3dtbf3vuI3w/Sp9eD6fOt6KdH 89dvF4sXVz8/+/GHH16d3Jy97E//O/zWGw9fTK77ydPL+F/OqB78T91ul6Uo 9n6V6xJ43R3K9JaqF3jsz81khJehVKmIvrsbEVWZJTBHCrBQUlgjl/wq+qlr krc5SMkm5W7qXPSkgbvf5TldT5h0sUxF5D89/te2OU0H3cdnWQ5nSXSA1DxL uMr98eso/0B1YE2i7+RmBmoltsJa3k1Z9LJXfbmnaevojpEkOp6+qFXVcdxa yAN9Zdj8KS5qVOL/5Pw17iZrF5o28mgYQY/6muf5uxSVhw3S6yvjcHiiVoXi 1mPeg0U1fvb26MeTV+boxcnZpfKe1U+fnl2evD07uWyfnlw+b5+ePXt3cfn2 5xXxUUBlPTZKXzagAzPGpH4xpAxSdDmBq/x2OPmPkJS0typ40cE5im7UKYVt GmZSaQQb3TrY2kK67j3s7SF2Ty4u4Ti+ztLO8zxZEXemhK0aYOXbBshq/Q0n qmmC6DcMaNYiYZzqaMs+mBuz1sNxSPhfOk9RhHseQU5N1WH8elNNVbkdrXvf Uo4zSOuCvGiQ5LN5n++zQiyqXO9OZzt6ppoG44swMV3xAcjEZLBSouOgINWf nny1TMcRSK5/tUz/NuJ8ntRJl75r4tBiO2IJESeS285+eXP+xO9kCvvrqUft czTQ0WVaM9BDf/CXpbUgEELqmOfp4Ry+Phwd9Ia7oyjuPBzGg06vN9zqRA/3 9zpbW9HW4FEv3u+P9ldAO6/7POm7RmgDkGnxtpchtsimJpdfrW+vBPWBd60E VdPWM1U5byG5jgZc3O7Skn1b6t3bV4WsygYAMLYgoUqsAZFKYNe6RludSO1E BSTu0m+bWU3O9ldyp0+J8ZwMWSfnx3qZqfhQljtdR5/jy3HihfIzeI7zNiQO MXFBr6ssw23jbViS8D2NPlDRV8lXX4c1yaU0N0zgRIzR+U50GK6IStL7ebYo pIE75x+R/mkvL8caBhf/xdomfaMRIW6F0XWUcBkWhu+ygoeegxpp3lwA/K8T YPZTcTQ0ny0Y/mvkLaKtmTv7bV9GSIjjDlYEPxiM448DsCi743I6aT4yenNj 9djY70M66WvnWOlZWbmfz5d9MoJC+bqhWl5Fpi0Twb5Hd5V9j75OpVnLlew9 lqFWQ1dZ1vp6ndhKDo0Jbmyce2FQZ6Bxtret5oYdY1sDvPGNrjvT6m7bT0JK A+h2xaABBsZ+l/T9inSbSNLsqcSG0ilmmhdFqEIGlJaupjTseIWx3yEVOvsr grFsZbp3hQfW9ldW6EKQFHgpxkIleXyFZ48CkjaXwiaxV7LQqT8BjBvWXqAB ZE6Pzo6wb5yrXi/Mp+/w289knd2jTjT3zLm0HrAtrA2RiSQxNbbR11fDWrKm NmvZ2lsug65qtF6qLxpyCZw/u/A1ABPB3ustUJ/daod+X0kOjXNjKfOcZj93 va6oy0y4fzAMi3m/w9jIbfS/pd3xTqXVGudsl9kgm5j7F6fnm964LaOvczEE pju4RQWLCVtoVW8vbcZC8ApJC5Qm3v16lNvANanh5aPrLwb7OmhZSGlOOlip Gls+sPd/6Wv3CmknALsLLnNoy6WHpow+yEYtQiPz2zwrqR9cmCtUS82v5+Y3 JesH33HNQ7Dnf/e2eYYWCHwB51L2xxuH75wHqKFI4KtX4pBD9QoejPiLs6xW +mF+oVMDMP/1W63EE4Brydf1Db4b7brn/5kJV3fxJVRrbKcJ0iMpMQMbiv1/ Rc02M0cp92eY+x+Hmr2+2XcjZ++Ff2Z6ttv4Lza8gnBdwx/zn8OGUf9jk6um 2+kvnzHR8jqOJtUGp+pIV49am634hC+fA/VzNAIl1ut5D7oqyhu9TyIBfoVO 2GQCyjKosdgwTI0+qh2V1hnByapdTJRmQaVrlo7YdcMlj157Nu0cE+5B+mrR dcmFHhG2fqN0ic2TzaX2Z5WOaNZKlcxGNaXGaFQH14ViBmAcXcfFEBR13L13 pbeU0AertS21tMnVjJuYUsKog0GmVYXB5S50JcCQAxruCj7em7SH9fowNV/E pTtFVFeaDd+nNrabgdkJ2JoyHkfWF0HXNtgGun6QQ5rO6M1wShWoimhXh+br 26RPgN6/hp1wg8spraeIHBVgJVEfNL/doXfQgtvb8Avbvpha4hFuFMEj5BOY EmXApI/UrAIGiPmz7cpFLn6TKwSVa69b3L1Dmt/ah+21WAsnvcWk6ATx3O3Y rqSkJtOAcYIg+wGSopiz2RTR3V50sisVInpRG3V4xkvrpcSzjT4pJIR5Qnnq dHrFjWPLQKMSeHZ/jq58InbuzkyHDR7vcBvjmI44mGR+6yltD4mOTVtTjlyA sR937JU9IBaiRO7qE4yKb7+fsEtWLzrR++jt6tym9Uq6jg3xgQCIqC/aYox9 H9DL7F836AjGuhT8KAbdNkgBItzxNCErrmsu6IIcd7aQgLmBYSR3o7tr4N29 urJsfwLXVgZpuu1zBkcgyC8nETvipLt3HGaBe+u3wGhr/8Kg0YEHeuuEdT0v yd+aX/PodA4XGMJFjaVoakyOtICJ43rQqW7XnnvhRshzLVG3a8XHbMlbhnkN jAbb89smHgRLGEML7qmrt5/TTu6PsJv2LT3wpEsU+djactsRe4mI8IUT2Rxy Dyl02SkCeEVcV0Qflr8wbfZjgN7QnsCu+oy4Y5wZxXSgTdBHDv6TApCs/wIB KNdOSmCNi4GQZGhJ43gy00jGsn7adRGYAdjHY4Ze9kpue5gjyJyH6Ul8W9Rs AvtRcY/vKe+U23yHs5Xax0sc29rqwb+dsivtaXKPC4c9E7lJDvcSiW/QV59Q C4BcPPf0F9X+0pWF0eBDmi0m8fDKXirpii8QgNQksPQ63okCpD1wSq9ZbqU7 P2f0T6Kl9vLUQyj3gpFakszoolHRLOJBViyBluz9R0mugiMK8FmJM2hM10al mKVZVqdM3aM+BuXcawPa2KB3gQ2Q+HeOcllvKNXXg77O6PZ5RagqVrmPRl51 +7axhpOQWCiSZZPCix8UmAmdX3lRgLZHTVS8ksfStKgdBAjC5VRVndq+rbbA Fw+IHoLigHlEg0tXutCFfVXltljbSmiQXaVYmUpRS1BflXwqZUdymDFG47eh VbzHeo0f7bCBgmzZpUfDykFqe8JukLb1JRYDNXS/JHOSY1WgKGONErX3xcX/ NseJdGm2TVtzvQsJORdcAxkZ45HgXnV+JIntV1HUhMOxtqsvYysYd4VGlBeS u+S60QzyaKRKDMgZJBtgj/MrbiQEyho2RoXtgqjCgAZtK6Jmm3RbBGyw0r7K JQuxFyXcmL8yYDpZUbWFlNNHZcMeQS/APIcippsrrmNh0FMuqkzykKF6nXq5 56OyXKAST+LgerC7krTBACoaFkE/2trLQYkUZgWvQCTWf8E6r+Q8FzaLGED5 Co8oNn1ELlpL7PCvVQNyrQjfxsm4TMQ1b640SNdLzCQsg7O6vsNcil5ycLhy zPqumXtjVLEp0IxHiVv/sa1L1azaurywN5yVS7vbamgTR6BMKxdtXbEzZnyc lj9N0HSdYfeRPOVWlCVJ8a54icJXpbl2UaUa22+Ojr07rbgCvUAQg7T1SzWJ cKqvBQcT/U16pKmQTt8VDmLb13JU14bflGzDoXXLxBVwTJltEfc1FszL5uIx 4WO2Q67X6cVMQRfVBpCc6E5HsWuOLN+yKr/2ndGLuLF6Dq/ldBFmd+sP520C a9a8SV6E7dYtBBBd5a6HLnkwVBQOmwHqNJMYPWAqaeiiPoayJVcBt/a182WB LFNbm7mIYk3NaDp0QFadTocqB9EFdORUJGaun76rfvV549Oh6CB4ZcUIlMG4 9Xlj46dYHBXYZ5hXGqUfwAgABdl8H4GIGYBmfzSJB+Z5nAI7iMHUx94n5q/L j3AQwU78OTEvtUuEoptLMJ2AO37z9sQ1t0ak4htXYITNmE6OLk8vHlD5L/WO Oz3Ha4FcM2PUg7Epo7SlcxYh5/qBJT3PLfEGV7f61xpt/F+PVjPj2NMAAA==[rfced] Note that we updated claim names to use double quotes to match the use in RFC-to-be 9575 <draft-ietf-stir-passport-rcd>. Please let us know if any updates are required. Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. rich call data vs. Rich Call Data Also, would you like instances of "Rich Call Data" to be replaced with "RCD" throughout, or is it intentionally expanded in the instances that remain? --> <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>