rfc9796xml2.original.xml   rfc9796.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-sipcore-callinfo-rcd-19" category="st <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
d" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symR -ietf-sipcore-callinfo-rcd-19" number="9796" updates="" obsoletes="" category="s
efs="true"> td" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" sym
Refs="true" version="3" xml:lang="en">
<front> <front>
<title abbrev="Call-Info Rich Call Data">SIP Call-Info Parameters for Rich C all Data</title> <title abbrev="Call-Info Rich Call Data">SIP Call-Info Parameters for Rich C all Data</title>
<seriesInfo name="RFC" value="9796"/>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos</organization> <organization>Somos</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>chris@appliedbits.com</email> <email>chris@appliedbits.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization>TransUnion</organization> <organization>TransUnion</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>Jon.Peterson@transunion.com</email> <email>Jon.Peterson@transunion.com</email>
</address> </address>
</author> </author>
<date year="2025" month="May"/>
<date year="2025" month="April" day="21"/> <area>ART</area>
<workgroup>sipcore</workgroup>
<area>art</area>
<keyword>Identity</keyword> <keyword>Identity</keyword>
<abstract> <abstract>
<t>This document specifies a usage of the SIP Call-Info header field that incorp
<?line 75?> orates Rich Call Data (RCD) associated with the identity of the originating part
y in order to provide to the terminating party a description of the caller (incl
<t>This document specifies a usage of the SIP Call-Info header field that incorp uding details about the reason for the session). RCD includes information about
orates Rich Call Data (RCD) associated with the identity of the originating part the caller beyond the telephone number (such as a calling name, logo, photo, or
y in order to provide to the terminating party a description of the caller (incl jCard object representing the caller), which can help the called party decide ho
uding details about the reason for the session). RCD includes information about w to handle the session request.</t>
the caller beyond the telephone number such as a calling name, a logo, photo, or <t>This document defines three new parameters 'call-reason', 'verified', a
jCard object representing the caller, which can help the called party decide ho nd 'integrity' for the SIP Call-Info header field and also a new token ("jcard")
w to handle the session request.</t> for the 'purpose' parameter of the Call-Info header field. It also provides gui
dance on the use of the Call-Info 'purpose' parameter token, "icon".</t>
<t>This document defines three new parameters 'call-reason', 'verified', and 'in
tegrity' for the SIP Call-Info header field and also a new token ("jcard") for t
he '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> </abstract>
</front> </front>
<middle> <middle>
<?line 81?>
<?line 81?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>Signaling protocols in telephone networks have long supported the deliv
ery of a 'calling name' from the originating side to the terminating side; howev
<t>Signaling protocols in telephone networks have long supported the delivery of er, in practice, the terminating side is often left to derive a name from the ca
a 'calling name' from the originating side to the terminating side, though in p lling-party number by consulting a local address book or an external database. S
ractice, the terminating side is often left to derive a name from the calling-pa IP <xref target="RFC3261"/> similarly can carry a 'display-name' in the From hea
rty number by consulting a local address book or an external database. SIP <xref der field value from the originating to terminating side, though it is a field t
target="RFC3261"/> similarly can carry a 'display-name' in the From header fiel hat is not commonly trusted and is often replaced or ignored. The same can be co
d value from the originating to terminating side, though it is a field that is n nsidered true of information in the Call-Info header field in SIP.</t>
ot commonly trusted and is often replaced or ignored. The same can be considered <!-- [rfced] Is "For this document" needed?
true of information in the Call-Info header field in SIP.</t>
<t>This document defines usage of the SIP Call-Info header field <xref target="R
FC3261"/> allowing called parties to receive a more comprehensive and extensible
set of Rich Call Data (RCD) for incoming calls. It specifically defines specifi
c usage of the Call-Info header field, a new parameter ('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 call
ing 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 pa
rty 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 tr
usted properties of 'rcd' claims defined in <xref target="I-D.ietf-stir-passport
-rcd"/>, this document defines two additional new parameters, 'verified' and 'in
tegrity'. 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 <xref target="I-
D.ietf-stir-passport-rcd"/>. The verification procedures include the successful
verification of the "rcd" claims and can be correspondingly represented in the C
all-Info header field via these new parameters.</t>
<t>Used on its own, this specification assumes that the called party UA can trus
t 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 commu
nications services, this end-to-end trust cannot be guaranteed. Therefore, the r
ecommended approach is that the entity inserting the Call-Info header field shou
ld also sign the caller information via STIR-defined protocol tools <xref target
="RFC7340"/> for SIP <xref target="RFC8224"/> and specifically through the use o
f RCD or the "rcd" PASSporT defined in <xref target="I-D.ietf-stir-passport-rcd"
/>.</t>
<t>Alternatively, this specification can be utilized in conjunction with the pro
tocols defined in <xref target="I-D.ietf-stir-passport-rcd"/> as part of the com
munications signaling path, specifically in the trusted UNI device interface at
the terminating side as part of an authenticated, network-to-device, trusted sig
naling 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 i
n this specification.</t>
<t>This specification provides an approach for the delivery of jCard data that u
tilizes the same mechanism as <xref target="RFC7852"/> which defined a means of
carrying additional data about callers for the purposes of emergency services (e
specially Section <xref target="RFC7852" section="4.4" sectionFormat="bare">Owne
r/Subscriber Information</xref> of <xref target="RFC7852"/>). This document defi
nes a 'purpose' parameter value 'jcard' for the more generic delivery of informa
tion 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> Original:
<section anchor="terminology"><name>Terminology</name> 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.
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", Perhaps:
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d Depending on the policies of the communications system, a calling
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x party could be either the end user device (e.g., a SIP user agent
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show (UA)) or a network service as part of a telephone service provider.
n here.</t>
</section> Alternatively, perhaps:
<section anchor="overview"><name>Overview</name> 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 provides a framework for the use of Call-Info header field to c <t>This document defines usage of the SIP Call-Info header field <xref tar
arry RCD in SIP <xref target="RFC3261"/>. The Call-Info header field (defined in get="RFC3261"/> that allows called parties to receive a more comprehensive and e
<xref section="20.9" sectionFormat="comma" target="RFC3261"/>) defines a 'purpo xtensible set of Rich Call Data (RCD) for incoming calls. It defines specific us
se' parameter. In addition to providing guidance on calling name practices and t age of the Call-Info header field, a new parameter ('call-reason'), and a new to
he use of the existing 'purpose' parameter token, "icon", this document expands ken ("jcard") for the 'purpose' parameter of the Call-Info header field. For thi
on other types of RCD by defining a new 'purpose' token, "jcard", and three new s document and depending on the policies of the communications system, a calling
parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info header party could be either the end user device (e.g., a SIP user agent (UA)) or a ne
field to align with RCD as defined in the STIR framework <xref target="RFC8224"/ twork service as part of a telephone service provider. Similarly, a called party
> and with "rcd" PASSporTs defined in <xref target="I-D.ietf-stir-passport-rcd"/ could be an end user device or the network telephone service provider acting on
>.</t> 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" claims defined in <xref target="RFC9795"/>, this
document defines two additional new parameters, 'verified' and 'integrity'. The
se 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-Network Interface (NNI)
that contains a verification service as defined in <xref target="RFC8224"/> and
further defined specific to RCD information in <xref target="RFC9795"/>. The ve
rification procedures include the successful verification of the "rcd" claims an
d 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 ca
n trust the SIP network to assign, deliver, and protect the correct RCD informat
ion 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 fiel
d should also sign the caller information via protocol tools defined by Secure T
elephone Identity Revisited (STIR) <xref target="RFC7340"/> for SIP <xref target
="RFC8224"/> and specifically through the use of RCD or the "rcd" PASSporT defin
ed in <xref target="RFC9795"/>.</t>
<t>The 'purpose' parameter token "jcard" is used to associate RCD related to the <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
identity of the calling party in the form of a jCard <xref target="RFC7095"/>. per the RFC Style Guide (see https://www.rfc-editor.org/rfc/rfc7322.html#section
While there is a "card" token defined in <xref target="RFC3261"/> which could be -3.6). Please review each expansion in the document carefully to ensure correctn
considered to have an overlapping purpose, the "jcard" token is intended to den ess.
ote the jCard profile defined in this document for use in the Call-Info header f
ield 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 a call and has been defined in <xref target="I-D.iet
f-stir-passport-rcd"/> 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 i UNI -> User-Network Interface (UNI)
ntent or reason for calling to help the called party understand the context and STIR -> Secure Telephone Identity Revisited (STIR)
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, w <t>Alternatively, this specification can be utilized in conjunction with t
ith the value "true", to represent the results of the verification procedures th he protocols defined in <xref target="RFC9795"/> as part of the communications s
at were performed by the sender of the Call-Info header field. The new Call-Info ignaling path, specifically in the trusted User-Network Interface (UNI) device i
header field parameter 'integrity' provides a mechanism to associate an integri nterface at the terminating side as part of an authenticated, network-to-device,
ty hash string, as defined in Section 8.2 of <xref target="I-D.ietf-stir-passpor trusted signaling where a device may not have the ability to verify the "rcd" P
t-rcd"/>, that is associated with the content of the resource referenced by the ASSporT, but it can receive the RCD information from the Call-Info header field
URI represented in the Call-Info header field.</t> 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 mea
ns of carrying additional data about callers for the purposes of emergency servi
ces (especially Section <xref target="RFC7852" section="4.4" sectionFormat="bare
">Owner/Subscriber Information</xref> of <xref target="RFC7852"/>). This documen
t defines a 'purpose' parameter value 'jcard' for the more generic delivery of i
nformation via jCard <xref target="RFC7095"/>. This document borrows from <xref
target="RFC7852"/> the capability to carry a data structure as a body, through t
he use of the "cid" URI scheme <xref target="RFC2392"/>.</t>
</section>
<section anchor="terminology">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="overview">
<name>Overview</name>
<t>This document provides a framework for the use of Call-Info header fiel
d to carry RCD in SIP <xref target="RFC3261"/>. The Call-Info header field (defi
ned 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 ex
pands on other types of RCD by defining a new 'purpose' token, "jcard", and thre
e new parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info h
eader field to align with RCD as defined in the STIR framework <xref target="RFC
8224"/> and with "rcd" PASSporTs defined in <xref 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="RFC709
5"/>. While there is a "card" token defined in <xref target="RFC3261"/> which co
uld 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 he
ader field for RCD. The choice of jCard in this specification is guided by two a
spects. jCard represents an extensible method of providing information about a p
erson or business associated with a call, has been defined in <xref target="RFC9
795"/>, 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 call
er's intent or reason for calling to help the called party understand the contex
t 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 indicat
ion, with the value "true", to represent the results of the verification procedu
res that were performed by the sender of the Call-Info header field. The new Cal
l-Info header field parameter 'integrity' provides a mechanism to associate an i
ntegrity hash string, as defined in <xref section="8.2" target="RFC9795"/>, that
is associated with the content of the resource referenced by the URI represente
d in the Call-Info header field.</t>
</section>
<section anchor="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 <xref target="RFC9795"/>. Typi
cally, a SIP-based session involves multiple hops through different trusted and
untrusted networks. The STIR framework <xref target="RFC7340"/> addresses the pr
otection of the carriage of call information and identities over untrusted netwo
rks, 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 provide
s procedures for defining new 'purpose' parameter tokens. This document discusse
s 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?
</section> Original:
<section anchor="a-call-info-framework-for-carrying-rich-call-data"><name>A Call The STIR RCD
-Info Framework for Carrying Rich Call Data</name> specification [I-D.ietf-stir-passport-rcd] defines calling name, a
logo or icon associated with the caller, and a call reason string.
<t>This specification extends the Call-Info header field to be compatible and co Perhaps:
mplementary to the RCD framework defined in <xref target="I-D.ietf-stir-passport The STIR RCD
-rcd"/>. Typically, a SIP-based session involves multiple hops through different specification [RFC9795] defines calling name (e.g., a logo or icon
trusted and untrusted networks. The STIR framework <xref target="RFC7340"/> add associated with the caller) and a call reason string.
resses the protection of the carriage of call information and identities over un -->
trusted networks, which wasn't addressed in the core SIP specifications. <xref s
ection="20.9" sectionFormat="comma" target="RFC3261"/> defines the Call-Info hea
der field as the mechanism for carrying call- and caller-related information and
also provides procedures for defining new 'purpose' parameter tokens. This docu
ment discusses the use of existing tokens and defines a new 'purpose' token to c
orrespond to the RCD framework.</t>
<t>There are a number of RCD information types that can be transmitted in the Ca ll-Info header field of a SIP request. The STIR RCD specification <xref target=" I-D.ietf-stir-passport-rcd"/> defines calling name, a logo or icon associated wi th the caller, and a call reason string. It also discusses an extensible way of carrying caller information using jCard <xref target="RFC7095"/>.</t> <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 <xref ta rget="RFC9795"/> defines calling name, a logo or icon associated with the caller , and a call reason string. It also discusses an extensible way to carry caller information using jCard <xref target="RFC7095"/>.</t>
<t>The RCD framework defined both in this document as well as in <xref target="I -D.ietf-stir-passport-rcd"/> carries call-specific information. The insertion of RCD is intended to be singular in that the receiving party should not be requir ed to make any call-specific decisions based on redundant, duplicate, or conflic ting 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 S TIR RCD PASSporT and unmodified once in a trusted domain. Any additional parties involved in the call path MUST NOT modify the Call-Info header field or add add itional Call-Info header fields related to RCD. The insertion of the RCD Call-In fo header field should be considered a trusted action based on trusted informati on, and the information MUST NOT 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 of stir or other mechanism s, detection of any modifications is not possible, so thus guidance for the use of this specification in a trusted UNI part of the network is important.</t> <!-- [rfced] For readability, please consider the possible update below. Also, is the information not to be "considered" modifiable, or should it be not modifi able?
<t>As discussed in <xref target="I-D.ietf-stir-passport-rcd"/>, the calling name Original:
uses the display-name value of the From header field <xref target="RFC3261"/> o The insertion of the RCD Call-Info header field
f the request. Alternatively, for some calls, the calling name may come from the should be considered a trusted action based on trusted information,
P-Asserted-ID header field <xref target="RFC3325"/>. While this is out of scope and the information MUST NOT be considered modifiable representing
for Call-Info header field in terms of the representation of the display-name v the best practice of determining the final representation of the
alue, this document does discuss the representation of the verification of this caller RCD to the user.
value using the 'verified' parameter.</t>
<t>For logos or icons that can represent the calling party, the 'purpose' token Perhaps:
"icon" <xref target="RFC3261"/> is used to indicate a URI for an image resource The best way to determine the final representation of the
that can be displayed to the user receiving the SIP request. For the purpose of caller RCD to the user is to consider the insertion of the
this document and the transmission of RCD, the "icon" 'purpose' token should be RCD Call-Info header field a trusted action based on trusted information,
used as defined. Section 8.2 provides high-level guidance on image formatting an whereby the information MUST NOT be considered modifiable.
d related information.</t> -->
<t>This document defines 'call-reason' as a new parameter for the Call-Info head er field. This parameter carries a string indicating the reason for the call.</t > <t>The RCD framework defined both in this document as well as in <xref tar get="RFC9795"/> carries call-specific information. The insertion of RCD is inten ded to be singular in that the receiving party should not be required to make an y 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 PASSp orT and unmodified once in a trusted domain. Any additional parties involved in the call path <bcp14>MUST NOT</bcp14> modify the Call-Info header field or add a dditional 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 informa tion, and the information <bcp14>MUST NOT</bcp14> be considered modifiable repre senting the best practice of determining the final representation of the caller RCD to the user. This specification acknowledges that without the use of STIR o r other mechanisms, detection of any modifications is not possible, so guidance for the use of this specification in a trusted UNI part of the network is import ant.</t>
<t>jCard is a comprehensive and extensible mechanism utilized as part of the STI R RCD framework. While <xref target="RFC3261"/> specifies a "card" 'purpose' tok en, the intent of defining a new "jcard" 'purpose' token is to use the JSON jCar d format <xref target="RFC7095"/> and to provide guidance for the use and non-us e of jCard attributes to describe the calling party in a communications session as well to provide some security considerations around that information. These t opics are covered in the next sections.</t> <!-- [rfced] It's unclear which section this sentence is referring to, as this d ocument does not have a Section 8.2. Perhaps Section 10.2 is intended?
</section> Current:
<section anchor="jcard-call-info-purpose-token"><name>"jcard" Call-Info 'purpose Section 8.2 provides high-level guidance on image formatting and
' Token</name> related information.
-->
<t>As discussed in <xref target="RFC9795"/>, the calling name uses the dis
play-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-I
D 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, thi
s document does discuss the representation of the verification of this value usi
ng 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 res
ource that can be displayed to the user receiving the SIP request. For the purpo
se of this document and the transmission of RCD, the "icon" 'purpose' token shou
ld be used as defined. Section 8.2 provides high-level guidance on image formatt
ing and related information.</t>
<t>This document defines 'call-reason' as a new parameter for the Call-Inf
o header field. This parameter carries a string indicating the reason for the ca
ll.</t>
<t>jCard is a comprehensive and extensible mechanism utilized as part of t
he STIR RCD framework. While <xref target="RFC3261"/> specifies a "card" 'purpos
e' token, the intent of defining a new "jcard" 'purpose' token is to use the JSO
N 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 se
ssion as well to provide some security considerations around that information. T
hese topics are covered in the next sections.</t>
</section>
<section anchor="jcard-call-info-purpose-token">
<name>"jcard" Call-Info 'purpose' Token</name>
<t>The Call-Info 'purpose' token "jcard" indicates support of RCD associat
ed with the identity of a calling party in a SIP call <xref section="20.9" secti
onFormat="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 f
or the JSON text <bcp14>MUST</bcp14> be set as application/json with an encoding
of UTF-8 <xref target="RFC8259"/>. This <bcp14>MAY</bcp14> be carried directly
in the Call-Info header field URI using the "data" URI scheme. A jCard also <bcp
14>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, t
he Call-Info header field URI <bcp14>MUST</bcp14> use a transport that can valid
ate the integrity of the source of the resource (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 <xref target="RFC9795"/> should be considered.</t>
<t>Because the use and purpose of this specification is to provide a singl
e presentation of rich call data information, a call and its corresponding singl
e RCD-related Call-Info header field <bcp14>MUST</bcp14> only contain a single j
Card object represented by an array with two elements. The array <bcp14>MUST</bc
p14> 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 jCar
d object.</t>
<!-- [rfced] We are having trouble parsing this sentence.
<t>The Call-Info 'purpose' token "jcard" indicates support of RCD associated wit a) Are "fn", "photo", and "logo" fields AND properties, or should the text
h the identity of a calling party in a SIP call <xref section="20.9" sectionForm refer to the properties (e.g., 'If "fn", "photo", or "logo" are used...')?
at="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 resou rce that is a jCard JSON object <xref target="RFC7095"/>. The media type for the JSON text MUST be set as application/json with an encoding of UTF-8 <xref targe t="RFC8259"/>. This MAY be carried directly in the Call-Info header field URI us ing the "data" URI scheme. A jCard also MAY be carried in the body of the SIP re quest bearing this Call-Info header field via the "cid" URI scheme <xref target= "RFC2392"/>. Alternatively, the Call-Info header field URI MUST use a transport that can validate the integrity of the source of the resource (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 <xref target="I-D.ietf-stir-passport-rcd"/ > should be considered.</t> b) What MUST match?
<t>Because the use and purpose of this specification is to provide a single pres entation of rich call data information, a call and its corresponding single RCD- related Call-Info header field MUST only contain a single jCard object represent ed by an array with two elements. The array MUST only include a single first ele ment with the string "vcard", and the second element is an array of jCard proper ties corresponding to the single entity jCard object.</t> c) Should single quotes be used as follows, as it appears token names usually ap pear in single quote?
<t>The fields like "fn", "photo", or "logo" if used with the use of "icon" or ca lling 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 clea rly determine the intended calling name or icon.</t> purpose token -> 'purpose' token
<t>An example of a Call-Info header field is:</t> 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.
-->
<figure><artwork><![CDATA[ <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 desc
ribed 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>
<artwork><![CDATA[
Call-Info: <https://example.com/qbranch.json>;purpose=jcard 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
<t>An example of the contents of a URL-linked jCard JSON file is shown as follow follows:</t>
s:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
["vcard", ["vcard",
[ [
["version",{},"text","4.0"], ["version",{},"text","4.0"],
["fn",{},"text","Q Branch"], ["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"], ["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"], ["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-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.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>
<t>An example SIP INVITE using the "data" URI scheme is as follows:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
INVITE sip:alice@example.com SIP/2.0 INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774> From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
Call-Info: <data:application/json,["vcard",[["version",{},"text", Call-Info: <data:application/json,["vcard",[["version",{},"text",
"4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch "4.0"],["fn",{},"text","Q Branch"],["org",{},"text","MI6;Q Branch
Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart Spy Gadgets"],["photo",{},"uri","https://example.com/photos/quart
ermaster-256x256.png"],["logo",{},"uri","https://example.com/log ermaster-256x256.png"],["logo",{},"uri","https://example.com/log
os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/ os/mi6-256x256.jpg"],["logo",{},"uri","https://example.com/logos/
skipping to change at line 165 skipping to change at line 215
Contact: <sip:12155551000@gateway.example.com> Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP s=Session SDP
c=IN IP4 pc33.atlanta.example.com c=IN IP4 pc33.atlanta.example.com
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
]]></artwork></figure> ]]></artwork>
<t>An example SIP INVITE using the "cid" URI scheme is as follows:</t>
<t>An example SIP INVITE using the "cid" URI scheme is as follows:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
INVITE sip:alice@example.com SIP/2.0 INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774> From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
Call-Info: <cid:12155551000@example.com>;purpose=jcard; Call-Info: <cid:12155551000@example.com>;purpose=jcard;
call-reason="Rendezvous for Little Nellie" call-reason="Rendezvous for Little Nellie"
CSeq: 314159 INVITE CSeq: 314159 INVITE
Max-Forwards: 70 Max-Forwards: 70
Date: Fri, 25 Sep 2025 19:12:25 GMT Date: Fri, 25 Sep 2025 19:12:25 GMT
skipping to change at line 206 skipping to change at line 254
--boundary1 --boundary1
Content-Type: application/json Content-Type: application/json
Content-ID: <12155551000@example.com> Content-ID: <12155551000@example.com>
["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"], ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri"," ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","
https://example.com/photos/quartermaster-256x256.png"],["logo", https://example.com/photos/quartermaster-256x256.png"],["logo",
{},"uri","https://example.com/logos/mi6-256x256.jpg"],["logo",{}, {},"uri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},
"uri","https://example.com/logos/mi6-64x64.jpg"]]] "uri","https://example.com/logos/mi6-64x64.jpg"]]]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="call-reason-call-info-parameter">
<section anchor="call-reason-call-info-parameter"><name>'call-reason' Call-Info <name>'call-reason' Call-Info Parameter</name>
Parameter</name> <t>This parameter is intended to be separate and distinct from the other U
RI and 'purpose' tokens that may precede these parameters.</t>
<t>This parameter is intended to be separate and distinct from the other URI and
'purpose' tokens that may proceed 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 an end-user during call alerting. As a general guideline, this me
ssage SHOULD be no longer than 64 characters; displays that support this specifi
cation may be forced to truncate messages that cannot fit onto a screen. This me
ssage 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 wi
ll 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 us
ed or interpreted as a 'clickable' action is discouraged.</t>
<t>An alternative approach would have been to use the value of Subject header fi
eld <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 pruden
t to define a new means of carrying a call reason indication.</t>
<t>An example of a Call-Info header field value with the "call-reason" parameter
follows:</t>
<figure><artwork><![CDATA[ <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 sui
table for display to an end user during call alerting. As a general guideline, t
his message <bcp14>SHOULD</bcp14> be no longer than 64 characters; displays that
support this specification may be forced to truncate messages that cannot fit o
nto a screen. This message conveys the caller's intention in contacting the call
ee. It is an optional parameter, and the sender of a SIP request cannot guarante
e 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 specificatio
n. In general, use of strings that could be forms of URIs or other potential str
ings 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 hea
der field <xref target="RFC3261"/> to convey the reason for the call. However, b
ecause the Subject header field has seen little historical use in SIP implementa
tions and its specification describes its potential use in filtering, it seemed
prudent to define a new means of carrying a call-reason indication.</t>
<t>An example of a Call-Info header field value with the "call-reason" par
ameter follows:</t>
<artwork><![CDATA[
Call-Info: <https://example.com/jbond.json>;purpose=jcard; Call-Info: <https://example.com/jbond.json>;purpose=jcard;
call-reason="For your ears only" call-reason="For your ears only"
]]></artwork></figure> ]]></artwork>
<!-- [rfced] We are having trouble understanding how "or any future parameters t
<t>In the case that there is only a 'call-reason' or 'verified' parameter or any hat may be defined" relates to the text. "only" seems to limit the parameters t
future parameters that may be defined and no need for a purpose parameter with hat may be used, but "any future parameters" seems open ended (i.e., any paramet
no associated URI the null data URI, "data:" is used as the URI. The purpose par er). Please review and consider whether the text can be clarified.
ameter "jcard", defined in this document, is used to avoid any conflicts or conf
usion with existing implementations and previously defined purpose parameters.
As an example:</t>
<figure><artwork><![CDATA[ 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 purpo
se parameter "jcard", defined in this document, is used to avoid any conflicts o
r confusion with existing implementations and previously defined purpose paramet
ers. As an example:</t>
<artwork><![CDATA[
Call-Info: <data:>;purpose=jcard; Call-Info: <data:>;purpose=jcard;
call-reason="For your ears only" call-reason="For your ears only"
]]></artwork></figure> ]]></artwork>
</section>
<section anchor="verified-call-info-parameter">
<name>'verified' Call-Info Parameter</name>
<t>The 'verified' parameter extends and complements the content conveyed b
y the RCD-related Call-Info header field. This parameter indicates to the recipi
ent that the information contained in the Call-Info header field has been verifi
ed by verification procedures for claims defined in <xref section="8" target="RF
C9795"/>. The presence of a 'verified' parameter on a Call-Info header field sho
uld be considered specific to the information for that Call-Info header field on
ly. If there is a Call-Info header field corresponding to information defined in
this specification that doesn't contain a 'verified' parameter, the recipient s
hould assume that information was not received and verified corresponding to the
verification procedures defined in <xref 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 inclu
ded the Call-Info header field performed a successful verification of the inform
ation represented. As a general principle of Call-Info header field information,
the recipients' ability to trust the 'verified' parameter is based on the trust
ed relationship of whom they are receiving the SIP request.</t>
</section> <!--[rfced] May this be rephrased to clarify "of whom"? Seemingly this
<section anchor="verified-call-info-parameter"><name>'verified' Call-Info Parame is about the trusted relationship with the party from whom they receive
ter</name> the SIP request.
<t>The 'verified' parameter extends and complements the content conveyed by the Original:
RCD-related Call-Info header field. This parameter indicates to the recipient th As a general
at the information contained in the Call-Info header field has been verified by principle of Call-Info header field information, the recipients
verification procedures for claims defined in Section 8 of <xref target="I-D.iet ability to trust the 'verified' parameter is based on the trusted
f-stir-passport-rcd"/>. The presence of a 'verified' parameter on a Call-Info he relationship of whom they are receiving the SIP request.
ader field should be considered specific to the information for that Call-Info h
eader field only. If there is a Call-Info header field corresponding to informat
ion defined in this specification that doesn't contain a 'verified' parameter, t
he recipient should assume that information was not received and verified corres
ponding to the verification procedures defined in Section 8 of <xref target="I-D
.ietf-stir-passport-rcd"/>.</t>
<t>There is a single valid value associated with the 'verified' parameter of 'tr Perhaps:
ue'. The value 'true' indicates to the recipient that the party that included th As a general
e Call-Info header field performed a successful verification of the information principle of Call-Info header field information, the recipients'
represented. As a general principle of Call-Info header field information, the r ability to trust the 'verified' parameter is based on the trusted
ecipients ability to trust the 'verified' parameter is based on the trusted rela relationship with the party from whom they are receiving the SIP request.
tionship of whom they are receiving the SIP request.</t> -->
<t>Example where the parameter verified="true" is used to represent that a verif <!-- [rfced] 'icon' vs. "icon"
ication procedure has been performed within a trust domain to indicate the 'icon This term appears in single quotes (2 instances) and double quotes (6 instances)
' URL has been successfully verified:</t> ;
should it be consistent?
<figure><artwork><![CDATA[ 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>
<artwork><![CDATA[
Call-Info: <https://example.com/jbond.png>;purpose=icon; Call-Info: <https://example.com/jbond.png>;purpose=icon;
verified="true" verified="true"
]]></artwork></figure> ]]></artwork>
<t>In addition to the use of the indication of successful verification of RCD in
formation, an important usage of the 'verified' parameter is for the indication
of verified "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 pr
ovider with the following STIR RCD PASSporT.</t>
<figure><artwork><![CDATA[ <t>In addition to the use of the indication of successful verification of
RCD information, an important usage of the 'verified' parameter is to indicate v
erification of display-name information, sometimes referred to as calling name o
r CNAM.</t>
<t>In the following example, a call was delivered via an NNI to a terminat
ing provider with the following STIR RCD PASSporT.</t>
<artwork><![CDATA[
Protected Header Protected Header
{ {
"alg":"ES256", "alg":"ES256",
"typ":"passport", "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem" "x5u":"https://cert.example.org/passport.pem"
} }
Payload Payload
{ {
"dest":{"tn":["12025551001"]}, "dest":{"tn":["12025551001"]},
"iat":1443208345, "iat":1443208345,
"orig":{"tn":"12025551000"}, "orig":{"tn":"12025551000"},
"rcd":{"nam":"James Bond","icn":"https://example.com/jbond.png"} "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 contai ning the STIR RCD PASSporT is verified through a verification service. The provi der then wants to deliver the call to an end device in the trusted and authentic ated UNI network. The provider uses local policies to determine the information desired to present to the end device. The following example SIP INVITE could be used to represent the RCD information using two Call-Info header fields. Becaus e the verification of both the icon and calling name passed, a Call-Info header for the 'icon' is added with a verified="true" parameter, and the use of Call-In fo with a null data URI is used, as discussed in the "call-reason" section above . 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="tru e" indicates that the display-name information in either the From and/or P-Asser ted-ID header field has been verified via RCD verification procedures.</t> <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 an d authenticated UNI network. The provider uses local policies to determine the i nformation to present to the end device. The following example SIP INVITE could be used to represent the RCD information using two Call-Info header fields. Bec ause both the icon and calling name have passed verification, a Call-Info header for the 'icon' is added with a verified="true" parameter, and the use of Call-I nfo with a null data URI is used, as discussed in the "call-reason" section abov e.
<t>Example SIP INVITE described above:</t> <!-- [rfced] This sentence is difficult to parse. Please clarify.
<figure><artwork><![CDATA[ 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 n
ull 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-Asserte
d-ID header field has been verified via RCD verification procedures.</t>
<t>Example SIP INVITE described above:</t>
<artwork><![CDATA[
INVITE sip:qbranch@example.com SIP/2.0 INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "QBranch" <sip:qbranch@example.com> To: "QBranch" <sip:qbranch@example.com>
From: "James Bond" <sip:12155551000@example.com;user=phone>; From: "James Bond" <sip:12155551000@example.com;user=phone>;
tag=1928> tag=1928>
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
Call-Info: <https://example.com/jbond.png>;purpose=icon; Call-Info: <https://example.com/jbond.png>;purpose=icon;
verified="true" verified="true"
Call-Info: <data:>;purpose=jcard;verified="true" Call-Info: <data:>;purpose=jcard;verified="true"
CSeq: 314159 INVITE CSeq: 314159 INVITE
skipping to change at line 293 skipping to change at line 386
Contact: <sip:12155551000@gateway.example.com> Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP s=Session SDP
c=IN IP4 pc33.atlanta.example.com c=IN IP4 pc33.atlanta.example.com
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
]]></artwork></figure> ]]></artwork>
</section>
<section anchor="integrity-call-info-parameter">
<name>'integrity' Call-Info Parameter</name>
<t>The 'integrity' parameter extends and complements the integrity informa
tion conveyed specifically by the "rcdi" claim in the RCD-related Call-Info head
er 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 in
tegrity hash value, based conceptually on <xref target="W3C-SRI"/>. <xref sectio
n="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 th
e 'rcdi' hashes is not necessary because each hash value should only correspond
to a single URI. Corresponding to guidance defined in <xref section="6" target="
RFC9795"/>, implementations of this specification <bcp14>MUST</bcp14> support th
e hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are iden
tified by "sha256", "sha384", and "sha512", respectively.</t>
<!-- [rfced] This sentence starts with "this hash value" and switches to "the in
tegrity value", but the connection between these is unclear. Please review.
</section> Original:
<section anchor="integrity-call-info-parameter"><name>'integrity' Call-Info Para Typically, this hash value, assuming the URI and the resource pointed
meter</name> 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.
<t>The 'integrity' parameter extends and complements the integrity information c Perhaps:
onveyed specifically by the 'rcdi' claim in the RCD-related Call-Info header fie Assuming the URI and the resource pointing
ld. This parameter is used to indicate, for a URI represented in the Call-Info h to the URI don't change between the STIR RCD PASSporT and the Call-
eader field, the resource referenced by that URI has an associated integrity has Info URI value, the integrity value can typically be used as the same
h value, based conceptually on <xref target="W3C-SRI"/>. Section 6 of <xref targ corresponding string in both the "rcdi" claim and the 'integrity'
et="I-D.ietf-stir-passport-rcd"/> describes the procedures for the creation of t parameter.
he digest value including the hash algorithm indicator a '-' separator and the h -->
ash value as a string. The JSON pointer object container described as the contai
ner of the 'rcdi' hashes is not necessary since each hash value should only corr
espond to a single URI. Corresponding to guidance defined in Section 6 of <xref
target="I-D.ietf-stir-passport-rcd"/>, implementations of this specification MUS
T support the hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorit
hms are identified by "sha256", "sha384", and "sha512", respectively.</t>
<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 th e 'rcdi' claim and the 'integrity' parameter string value.</t> <t>Typically, this hash value, assuming the URI and the resource pointed t o 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 b oth the "rcdi" claim and the 'integrity' parameter string value.</t>
<t>Note: the inclusion of both the 'verified' and 'integrity' when an 'rcdi' cla im is included and the identity header field and included PASSporT is verified s uccessfully is the suggested outcome. Creation of a Call-Info header field base d on an identity header field that carries Rich Call Data claims that does not p ass verification procedures is not suggested (i.e., the inclusion of an 'integri ty' parameter without a properly included 'verified' parameter)</t> <!-- [rfced] We are having trouble parsing this sentence. Please clarify.
<t>Example STIR RCD PASSporT:</t> 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.
<figure><artwork><![CDATA[ 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 verif
ied 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 'in
tegrity' parameter without a properly included 'verified' parameter)</t>
<t>Example STIR RCD PASSporT:</t>
<artwork><![CDATA[
Protected Header Protected Header
{ {
"alg":"ES256", "alg":"ES256",
"typ":"passport", "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem" "x5u":"https://cert.example.org/passport.pem"
} }
Payload Payload
{ {
"crn": "Rendezvous for Little Nellie", "crn": "Rendezvous for Little Nellie",
skipping to change at line 328 skipping to change at line 446
"iat": 1443208345, "iat": 1443208345,
"orig": {"tn": "12025551000"}, "orig": {"tn": "12025551000"},
"rcd": { "rcd": {
"nam": "Q Branch Spy Gadgets", "nam": "Q Branch Spy Gadgets",
"icn": "https://example.com/photos/q-256x256.png" "icn": "https://example.com/photos/q-256x256.png"
}, },
"rcdi": { "rcdi": {
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
} }
} }
]]></artwork></figure> ]]></artwork>
<t>Example corresponding SIP INVITE with Call-Info information derived fro
<t>Example corresponding SIP INVITE with Call-Info information derived from RCD m RCD information above:</t>
information above:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
INVITE sip:qbranch@example.com SIP/2.0 INVITE sip:qbranch@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: "James Bond" <sip:12155551001@example.com;user=phone> To: "James Bond" <sip:12155551001@example.com;user=phone>
From: "Q Branch Spy Gadgets" <sip:12025551000@example.com; From: "Q Branch Spy Gadgets" <sip:12025551000@example.com;
user=phone>;tag=1928> user=phone>;tag=1928>
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
Call-Info: <https://example.com/photos/q-256x256.png>;purpose= Call-Info: <https://example.com/photos/q-256x256.png>;purpose=
icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm icon;verified="true";integrity="sha256-RojgWwU6xUtI4q82+kHPyHm
1JKbm7+663bMvzymhkl4" 1JKbm7+663bMvzymhkl4"
Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for Call-Info: <data:>;purpose=jcard;call-reason="Rendezvous for
skipping to change at line 358 skipping to change at line 474
Contact: <sip:12155551000@gateway.example.com> Contact: <sip:12155551000@gateway.example.com>
Content-Type: application/sdp Content-Type: application/sdp
v=0 v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP s=Session SDP
c=IN IP4 pc33.atlanta.example.com c=IN IP4 pc33.atlanta.example.com
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="usage-and-an-example-of-call-info-for-rcd">
<section anchor="usage-and-an-example-of-call-info-for-rcd"><name>Usage and an E <name>Usage and an Example of Call-Info for RCD</name>
xample of Call-Info for RCD</name> <!-- [rfced] We are unsure what "is a general anticipated process" means. Perha
ps the text should refer to an "expected process" or an "accepted process"? Als
o, is the process a "general process" or is the process "generally anticipated"?
<t>The procedures for the usage of URIs and 'purpose' parameter tokens should fo Original:
llow the procedures defined in <xref target="RFC3261"/>. The general management Because the 'rcd' Call-Info header field is inserted as part of the
and provisioning of Rich Call Data for an initiating party does require a lot of receiving part of the transition from NNI to UNI, the information
validation of information regarding that specific initiating party which is out populated in a received stir ‘rcd’ PASSporT that is verified is a
of scope of this document. Because the 'rcd' Call-Info header field is inserte general anticipated process for translating information into the
d as part of the receiving part of the transition from NNI to UNI, the informati 'rcd' Call-Info header field to transport the rich call data into the
on populated in a received stir ‘rcd’ PASSporT that is verified is a general ant UNI toward the end user device.
icipated process for translating information into the 'rcd' Call-Info header fie -->
ld to transport the rich call data into the UNI toward the end user device.</t>
<t>The following example provides both the STIR RCD PASSporT and the correspondi <t>The procedures for the usage of URIs and 'purpose' parameter tokens sho
ng set of Call-Info header fields shows the use of multiple 'purpose' parameters uld follow the procedures defined in <xref target="RFC3261"/>. The general manag
to indicate a jCard and an icon and also a 'call-reason' parameter:</t> ement and provisioning of Rich Call Data for an initiating party requires a lot
of validation of information regarding that specific initiating party, which is
out of scope of this document. Because the 'rcd' Call-Info header field is inse
rted as part of the receiving part of the transition from NNI to UNI, the inform
ation 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>
<!-- [rfced] Should the text refer to the "jcard" and "icon" parameters here (i.
e., lowercase and doublequotes)?
<t>Example STIR RCD PASSporT:</t> 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:
-->
<figure><artwork><![CDATA[ <t>The following example provides both the STIR RCD PASSporT and the corre
sponding set of Call-Info header fields showing the use of multiple 'purpose' pa
rameters to indicate a jCard and an icon and also a 'call-reason' parameter:</t>
<t>Example STIR RCD PASSporT:</t>
<artwork><![CDATA[
Protected Header Protected Header
{ {
"alg":"ES256", "alg":"ES256",
"typ":"passport", "typ":"passport",
"ppt":"rcd", "ppt":"rcd",
"x5u":"https://cert.example.org/passport.pem" "x5u":"https://cert.example.org/passport.pem"
} }
Payload Payload
{ {
"crn":"For your ears only", "crn":"For your ears only",
skipping to change at line 392 skipping to change at line 524
"orig":{"tn":"12025551000"}, "orig":{"tn":"12025551000"},
"rcd":{ "rcd":{
"jcl":"https://example.com/qbranch.json", "jcl":"https://example.com/qbranch.json",
"icn":"https://example.com/jbond.png" "icn":"https://example.com/jbond.png"
}, },
"rcdi": { "rcdi": {
"/jcl": "sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82+kHP" "/jcl": "sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82+kHP"
"/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" "/icn": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
} }
} }
]]></artwork></figure> ]]></artwork>
<t>Example Call-Info header fields:</t>
<t>Example Call-Info header fields:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Call-Info: <data:>;purpose=jcard;verified="true" Call-Info: <data:>;purpose=jcard;verified="true"
Call-Info: <https://example.com/jbond.json>;purpose=jcard;verified Call-Info: <https://example.com/jbond.json>;purpose=jcard;verified
=true;integrity="sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82 =true;integrity="sha256-yHm1JKbm7+663bMvzymhkl4RojgWwU6xUtI4q82
+kHP" +kHP"
Call-Info: <https://example.com/jbond.png>;purpose=icon; Call-Info: <https://example.com/jbond.png>;purpose=icon;
call-reason="For your ears only";verified=true;integrity= call-reason="For your ears only";verified=true;integrity=
"sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4" "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4"
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="usage-of-jcard-and-property-specific-usage">
<section anchor="usage-of-jcard-and-property-specific-usage"><name>Usage of jCar <name>Usage of jCard and Property-Specific Usage</name>
d and Property-Specific Usage</name> <t>Beyond the definition of the specific properties or JSON arrays associa
ted with each property, this specification defines a few rules beyond those defi
<t>Beyond the definition of the specific properties or JSON arrays associated wi ned in <xref target="RFC7095"/> that are specific to the use of jCard for Call-I
th each property, this specification defines a few rules above and beyond <xref nfo and RCD to ensure there is a minimum level of supported properties to which
target="RFC7095"/> that are specific to the use of jCard for Call-Info and RCD t every implementation of this specification should adhere. This includes support
o ensure there is a minimum level of supported properties to which every impleme for interpreting the value of these properties and the ability to render in some
ntation of this specification should adhere. This includes support for interpret appropriate form the display capabilities of common telephone devices as well a
ing the value of these properties and the ability to render in some appropriate s applications, and also includes requirements specific to textual and graphics-
form the display capabilities of common telephone devices as well as application capable displays.</t>
s, and also includes requirements specific to textual and graphics-capable displ <section anchor="usage-of-uris-in-jcard">
ays.</t> <name>Usage of URIs in jCard</name>
<!-- [rfced] The last sentence below is dense and hard to follow. Please review
<section anchor="usage-of-uris-in-jcard"><name>Usage of URIs in jCard</name> .
<t>When one or more URIs are used in a jCard, it is important to note that any U
RI-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 jCa
rd can have URI references as defined in the jCard specification and this docume
nt, but the content referenced by those URIs MUST NOT have any URIs, and therefo
re MUST be enforced by the client to not follow those URI references or not rend
er that content to the user if any URI are present in that specific URI linked c
ontent. The purpose of this is to control the security and more specifically to
align with the content-integrity mechanism defined in <xref target="I-D.ietf-sti
r-passport-rcd"/>. There is not anticipated to be need for which deeper URI refe
rences would be required or even supported by the typical use of current jCard p
roperties. However, because jCard is extensible, this rule is set to restrict fu
rther extension without the proper consideration of security and integrity prope
rties of both Call-Info usage as well as the RCD and STIR signing of the data <x
ref target="I-D.ietf-stir-passport-rcd"/> <xref target="RFC8224"/>.</t>
</section>
<section anchor="multimedia-data"><name>Usage of Multimedia Data in jCard or wit
h Icon</name>
<t>For the use of the 'purpose' token "icon" or for the cases where the jCard ei
ther incorporates URIs or includes digital images and sounds directly via Base64
encoding (Section 4 of <xref target="RFC4648"/>), this document provides guidan
ce at the time of writing that can be adopted to facilitate the successful decod
ing and rendering of these images and media formats, noting that media formats i
s 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
formats SHOULD 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 recom
mended because, at the time of writing, they are becoming increasingly rare (i.e
., typically, devices either have color or color-aware graphical displays that s
upport PNG or JPEG formats or they are exclusively textual displays).</t>
<t>In addition, vector images are increasingly popular to use for icons because
they support scalable images without having to send multiple resolutions. The SV
G format has gained wide support as of this writing as a common format for vecto
r images. At a minimum, the SVG Tiny 1.2 specification <xref target="W3C-SVGTiny
1.2"/> SHOULD be supported as an additional default format for devices.</t>
<t>For the cases where image files are referenced by URIs as file resources, thi
s document defines a character string that SHOULD be concatenated onto the end o
f 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 appropriat
e resolution to retrieve without the need to retrieve all the image files. It is
also recommended that images have a square aspect ratio with equal height and w
idth and with a power of two value for the number of pixels (e.g., 32x32, 128x12
8, 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 convention that is RECOMMENDED is that files that
refer to the same content should use the same filename portion. If the image fo
rmat has a specific resolution, the HxW portion of the filename should correspon
d 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, f
ilename-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 m
any years of advances in image coding and display technologies, this specificati
on suggests relying on either future specifications or industry forum specificat
ions that might correspond to supporting particular classes of devices to furthe
r 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 fil
es <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. F
uture documents should consider both usage and potential security risks of playi
ng sounds that are not specifically authorized by a device user.</t>
</section>
<section anchor="cardinality"><name>Cardinality</name>
<t>Property cardinalities are indicated, for convenience, using the following no
tation and follow the guidance of jCard <xref target="RFC7095"/> and vCard <xref
target="RFC6350"/>, which is based on ABNF (see <xref section="3.6" sectionForm
at="comma" target="RFC5234"/>):</t>
<figure><artwork><![CDATA[
+-------------+--------------------------------------------------+
| Cardinality | Meaning |
+-------------+--------------------------------------------------+
| 1 | Exactly one instance per jCard MUST be present. |
| *1 | Exactly one instance per jCard MAY be present. |
| 1* | One or more instances per jCard MUST be present. |
| * | One or more instances per jCard MAY be present. |
+-------------+--------------------------------------------------+
]]></artwork></figure>
</section> Original (the sentence prior is provided for context):
<section anchor="identification-properties"><name>Identification Properties</nam When one or more URIs are used in a jCard, it is important to note
e> that any URI-referenced data, with the exception of the top-level
<t>The following properties, initially defined in <xref target="RFC6350"/>, hold usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI
the identity information of the entity associated with the jCard. This subset o references. In other words, the jCard can have URI references as
f properties selected for this document are relevant to telephone and messaging defined in the jCard specification and this document, but the content
applications.</t> 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.
<section anchor="fn-property"><name>"fn" Property</name> 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>The "fn" property provides a formatted text corresponding to the name of the <t>When one or more URIs are used in a jCard, it is important to note th
object the jCard represents. Reference: <xref section="6.2.1" sectionFormat="co at any URI-referenced data, with the exception of the top-level usage of "jcl" a
mma" target="RFC6350"/>.</t> s 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 specif
ication 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-inte
grity mechanism defined in <xref 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 extensibl
e, this rule is set to restrict further extension without the proper considerati
on of security and integrity properties of both Call-Info usage as well as the R
CD and STIR signing of the data <xref target="RFC9795"/> <xref target="RFC8224"/
>.</t>
</section>
<section anchor="multimedia-data">
<!-- [rfced] It appears as though tokens appear in double quotes. Should the se
ction title be updated to reflect "icon"?
<t>Value type: A single text value.</t> Original:
10.2. Usage of Multimedia Data in jCard or with Icon
<t>Cardinality: 1*</t> Perhaps:
10.2. Usage of Multimedia Data in jCard or with the "icon" Token
-->
<figure><artwork><![CDATA[ <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 vi
a Base64 encoding (<xref section="4" target="RFC4648"/>), this document provides
guidance at the time of writing that can be adopted to facilitate the successfu
l decoding and rendering of these images and media formats. Note that media form
ats are likely something implementers need to consider for their specific applic
ation.</t>
<t>For images, such as for the "photo" and "logo" properties, the defaul
t image formats <bcp14>SHOULD</bcp14> be PNG <xref target="ISOPNG"/> or JPEG <xr
ef target="ITUJPEG"/>, as these files are commonly used to support 24-bit RGB im
ages. 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 opt
ional 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 gr
aphical displays that support PNG or JPEG formats or they are exclusively textua
l displays).</t>
<t>In addition, vector images are increasingly popular to use as icons b
ecause 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 fo
r vector images. At a minimum, the SVG Tiny 1.2 specification <xref target="W3C-
SVGTiny1.2"/> <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 resour
ces, this document defines a character string that <bcp14>SHOULD</bcp14> be conc
atenated onto the end of a file name, but before the file extension, that signal
s the height and width of the image to the end device for the convenience of det
ermining the appropriate resolution to retrieve files without the need to retrie
ve all the image files. It is also recommended that images have a square aspect
ratio with equal height and width and with a power-of-two value for the number o
f pixels (e.g., 32x32, 128x128, 512x512). The format of the string should be "fi
lename-HxW", where "filename" is a unique string representing the file, "H" repr
esents the height in pixels, and "W" represents the width in pixels.</t>
<t>It is appropriate and useful to include multiple versions of images o
r sounds so that endpoints that cannot support all formats or resolutions can se
lect the format they do support. The <bcp14>RECOMMENDED</bcp14> convention is f
or files that refer to the same content to use the same filename portion. If th
e image format has a specific resolution, the HxW portion of the filename should
correspond to the pixel resolution. The file extension should reference the fil
e type (e.g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32
x32.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 ov
er the many years of advances in image coding and display technologies, this spe
cification suggests relying on either future specifications or industry forum sp
ecifications that might correspond to supporting particular classes of devices t
o 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 specific
ation. Future documents should consider both usage and potential security risks
of playing sounds that are not specifically authorized by a device user.</t>
</section>
<section anchor="cardinality">
<name>Cardinality</name>
<t>Property cardinalities are indicated, for convenience, using the foll
owing notation and follow the guidance of jCard <xref target="RFC7095"/> and vCa
rd <xref target="RFC6350"/>, which is based on ABNF (see <xref section="3.6" sec
tionFormat="comma" target="RFC5234"/>):</t>
<table>
<thead><tr><th>Cardinality</th><th>Meaning</th></tr></thead>
<tbody>
<tr><td>1</td><td>Exactly one instance per jCard <bcp14>MUST</bcp14> be pres
ent.</td></tr>
<tr><td>*1</td><td>Exactly one instance per jCard <bcp14>MAY</bcp14> be pres
ent.</td></tr>
<tr><td>1*</td><td>One or more instances per jCard <bcp14>MUST</bcp14> be pr
esent.</td></tr>
<tr><td>*</td><td>One or more instances per jCard <bcp14>MAY</bcp14> be pres
ent.</td></tr>
</tbody>
</table>
</section>
<section anchor="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 me
ssaging applications.</t>
<section anchor="fn-property">
<name>"fn" Property</name>
<t>The "fn" property provides formatted text corresponding to the name
of the object the jCard represents. Reference: <xref section="6.2.1" sectionFo
rmat="comma" target="RFC6350"/>.</t>
<dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single text value.</dd>
<dt>Cardinality:</dt><dd>1*</dd>
</dl>
<artwork><![CDATA[
Example: Example:
["fn", {}, "text", "Mr. John Q. Public\, Esq."] ["fn", {}, "text", "Mr. John Q. Public\, Esq."]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="n-property">
<section anchor="n-property"><name>"n" Property</name> <name>"n" Property</name>
<t>The "n" property provides the components of the name of the object
<t>The "n" property provides the components of the name of the object the jCard the jCard represents. Reference: <xref section="6.2.2" sectionFormat="comma" tar
represents. Reference: <xref section="6.2.2" sectionFormat="comma" target="RFC63 get="RFC6350"/>.</t>
50"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single structured text value. Each component
<t>Value type: A single structured text value. Each component can have multiple can have multiple values.</dd>
values.</t> <dt>Cardinality:</dt><dd>*1</dd>
</dl>
<t>Cardinality: *1</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="nickname-property">
<section anchor="nickname-property"><name>"nickname" Property</name> <name>"nickname" Property</name>
<t>The "nickname" property provides the text corresponding to the nick
<t>The "nickname" property provides the text corresponding to the nickname of th name of the object the jCard represents. Reference: <xref section="6.2.3" sectio
e object the jCard represents. Reference: <xref section="6.2.3" sectionFormat="c nFormat="comma" target="RFC6350"/>.</t>
omma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>One or more text values separated by a COMMA c
<t>Value type: One or more text values separated by a COMMA character (U+002C).< haracter (U+002C).</dd>
/t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["nickname", {}, "text", "Robbie"] ["nickname", {}, "text", "Robbie"]
["nickname", {}, "text", "Jim,Jimmie"] ["nickname", {}, "text", "Jim,Jimmie"]
["nickname", {}, "text", "TYPE=work:Boss"] ["nickname", {}, "text", "TYPE=work:Boss"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="photo-property">
<section anchor="photo-property"><name>"photo" Property</name> <name>"photo" Property</name>
<t>The "photo" property provides image or photograph information that
<t>The "photo" property provides image or photograph information that annotates annotates some aspect of the object the jCard represents. Reference: <xref secti
some aspect of the object the jCard represents. Reference: <xref section="6.2.4" on="6.2.4" sectionFormat="comma" target="RFC6350"/>.</t>
sectionFormat="comma" target="RFC6350"/>.</t> <t>In addition to the definition of jCard, and to promote interoperabi
lity and proper formatting and rendering of images, the photo <bcp14>SHOULD</bcp
<t>In addition to the definition of jCard, and to promote interoperability and p 14> correspond to a square image with the size of 128x128, 256x256, 512x512, or
roper formatting and rendering of images, the photo SHOULD correspond to a squar 1024x1024 pixels.</t>
e image with the size of 128x128, 256x256, 512x512, or 1024x1024 pixels.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single URI.</dd>
<t>Value type: A single URI.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"] ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="delivery-addressing-properties">
<section anchor="delivery-addressing-properties"><name>Delivery Addressing Prope <name>Delivery Addressing Properties</name>
rties</name> <t>This property is concerned with information related to the delivery a
ddress of the jCard object.</t>
<t>This property is concerned with information related to the delivery address o <section anchor="adr-property">
f the jCard object.</t> <name>"adr" Property</name>
<t>The "adr" property provides the delivery address of the object the
<section anchor="adr-property"><name>"adr" Property</name> jCard represents. Reference: <xref section="6.3.1" sectionFormat="comma" target=
"RFC6350"/>.</t>
<t>The "adr" property provides the delivery address of the object the jCard repr <dl spacing="compact" newline="false">
esents. Reference: <xref section="6.3.1" sectionFormat="comma" target="RFC6350"/ <dt>Value type:</dt><dd>A single structured text value separated by th
>.</t> e SEMICOLON character (U+003B).</dd>
<dt>Cardinality:</dt><dd>*</dd>
<t>Value type: A single structured text value separated by the SEMICOLON charact </dl>
er (U+003B).</t> <artwork><![CDATA[
<t>Cardinality: *</t>
<figure><artwork><![CDATA[
Example: Example:
["adr", {“type”:”work"}, "text", ["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", “DC”, ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
"20008", “U.S.A."] "20008", "U.S.A."]
] ]
]]></artwork></figure> ]]></artwork>
<t>"adr" also allows a structured value element that itself has multip
<t>"adr" also allows a structured value element that itself has multiple values. le values. In this case, the element of the array describing the structured valu
In this case, the element of the array describing the structured value is itsel e is itself an array with one element for each of the component's multiple value
f an array with one element for each of the component's multiple values. The fol s. The following example shows alternate values for the address string.</t>
lowing example shows alternate values for the address string.</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["adr", {“type”:”work"}, "text", ["adr", {"type":"work"}, "text",
["", "", ["3100 Massachusetts Avenue NW”,"Embassy of the ["", "", ["3100 Massachusetts Avenue NW","Embassy of the
United Kingdom"], "Washington", “DC”, "20008", “U.S.A."] United Kingdom"], "Washington", "DC", "20008", "U.S.A."]
] ]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="communications-properties">
<section anchor="communications-properties"><name>Communications Properties</nam <name>Communications Properties</name>
e> <t>These properties describe how to communicate with the object the jCar
d represents.</t>
<section 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 p
rovide an alternate telephone number or other related telephone numbers for othe
r uses.</t>
<!-- [rfced] Is it accurate to refer to the 'potential instances of the "tel" pr
operty', as opposed to 'instances of the "tel" property'?
<t>These properties describe how to communicate with the object the jCard repres Original:
ents.</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 [RFC8224] or required to match the "orig"
claim in the PASSporT [RFC8225].
<section anchor="tel-property"><name>"tel" Property</name> Similarly, is "has the intent" correct in the following (instead of "provides" a nd "specifies")?
<t>The "tel" property provides the telephone number for the object the jCard rep Original:
resents. Reference: <xref section="6.4.1" sectionFormat="comma" target="RFC6350" The "title" property has the intent of providing the position or job
/>.</t> of the object the jCard represents. Reference [RFC6350],
Section 6.6.1.
<t>Relative to the SIP From header field value, this information may provide an The "role" property has the intent of providing the position or job
alternate telephone number or other related telephone numbers for other uses.</t of the object the jCard represents. Reference [RFC6350],
> Section 6.6.2.
<t>It is important to note that any of the potential instances of the "tel" prop The "logo" property has the intent of specifying a graphic image of a
erty should not be considered part of the authentication or verification part of logo associated with the object the jCard represents. Reference
STIR <xref target="RFC8224"/> or required to match the "orig" claim in the PASS [RFC6350], Section 6.6.3.
porT <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 pot
ential confusion of the callee when provided with multiple telephone numbers ver
sus the actual, verified telephone number should be considered from a general po
licy point of view.</t>
<t>Value type: By default, it is a single free-form text value (for backward com The "org" property has the intent of specifying the organizational
patibility with vCard 3), but it SHOULD be reset to a URI value. It is expected name and units of the object the jCard represents. Reference
that the URI scheme will be "tel", as specified in <xref target="RFC3966"/>, but [RFC6350], Section 6.6.4.
other schemes MAY be used.</t>
<t>Cardinality: *</t> The "version" property MUST be included and is intended to specify
the version of the vCard specification used to format this vCard.
-->
<figure><artwork><![CDATA[ <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 verificati
on part of STIR <xref target="RFC8224"/> or required to match the "orig" claim i
n the PASSporT <xref target="RFC8225"/>. These telephone numbers can be for cont
act, fax, or other purposes aligned with the general usage of jCard and vCard, b
ut the potential confusion of the callee when provided with multiple telephone n
umbers instead of the actual, verified telephone number should be considered fro
m a general policy point of view.</t>
<dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>By default, it is a single free-form text valu
e (for backward compatibility with vCard 3), but it <bcp14>SHOULD</bcp14> be res
et to a URI value. It is expected that the URI scheme will be "tel", as specifie
d in <xref target="RFC3966"/>, but other schemes <bcp14>MAY</bcp14> be used.</dd
>
<dt>Cardinality:</dt><dd>*</dd>
</dl>
<artwork><![CDATA[
Example: Example:
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
"tel:+1-202-555-1000"] "tel:+1-202-555-1000"]
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="email-property">
<section anchor="email-property"><name>"email" Property</name> <name>"email" Property</name>
<t>The "email" property provides the electronic mail address of the ob
<t>The "email" property provides the electronic mail address of the object the j ject the jCard represents. Reference: <xref section="6.4.2" sectionFormat="comma
Card represents. Reference: <xref section="6.4.2" sectionFormat="comma" target=" " target="RFC6350"/>.</t>
RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single text value.</dd>
<t>Value type: A single text value.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
["email", {"pref":"1"}, "text", "jane_doe@example.com"] ["email", {"pref":"1"}, "text", "jane_doe@example.com"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="lang-property">
<section anchor="lang-property"><name>"lang" Property</name> <name>"lang" Property</name>
<t>The "lang" property indicates the language(s) that may be used for
<t>The "lang" property provides the language(s) that may be used for communicati communicating with the object the jCard represents. Reference: <xref section="6.
ng with the object the jCard represents. Reference: <xref section="6.4.4" sectio 4.4" sectionFormat="comma" target="RFC6350"/>.</t>
nFormat="comma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single language-tag value.</dd>
<t>Value type: A single language-tag value.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
["lang", {"type":"home"}, "language-tag", "fr"] ["lang", {"type":"home"}, "language-tag", "fr"]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="geographical-properties">
<section anchor="geographical-properties"><name>Geographical Properties</name> <name>Geographical Properties</name>
<t>These properties provide geographical information associated with the
<t>These properties provide geographical information associated with the object object the jCard represents.</t>
the jCard represents.</t> <section anchor="tz-property">
<name>"tz" Property</name>
<section anchor="tz-property"><name>"tz" Property</name> <t>The "tz" property provides the time zone of the object the jCard re
presents. Reference: <xref section="6.5.1" sectionFormat="comma" target="RFC6350
<t>The "tz" property provides the time zone of the object the jCard represents. "/>.</t>
Reference: <xref section="6.5.1" sectionFormat="comma" target="RFC6350"/>.</t> <t>Note: The reference for time-zone names is <eref brackets="angle" t
arget="https://www.iana.org/time-zones"/>.</t>
<t>Note: the reference for time-zone names is https://www.iana.org/time-zones.</ <dl spacing="compact" newline="false">
t> <dt>Value type:</dt><dd>The default is a single text value. It can als
o be reset to a single URI or a UTC-offset value.</dd>
<t>Value type: The default is a single text value. It can also be reset to a sin <dt>Cardinality:</dt><dd>*</dd>
gle URI or a UTC-offset value.</t> </dl>
<artwork><![CDATA[
<t>Cardinality: *</t>
<figure><artwork><![CDATA[
Example: Example:
["tz", {}, "text", "America/New_York"] ["tz", {}, "text", "America/New_York"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="geo-property">
<section anchor="geo-property"><name>"geo" Property</name> <name>"geo" Property</name>
<t>The "geo" property provides the global positioning of the object th
<t>The "geo" property provides the global positioning of the object the jCard re e jCard represents. Reference: <xref section="6.5.2" sectionFormat="comma" targe
presents. Reference: <xref section="6.5.2" sectionFormat="comma" target="RFC6350 t="RFC6350"/>.</t>
"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single URI.</dd>
<t>Value type: A single URI.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["geo", {}, "uri", "geo:37.386013,-122.082932"] ["geo", {}, "uri", "geo:37.386013,-122.082932"]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="organizational-properties">
<section anchor="organizational-properties"><name>Organizational Properties</nam <name>Organizational Properties</name>
e> <t>These properties are concerned with information associated with chara
cteristics of the organization or organizational units of the object that the jC
<t>These properties are concerned with information associated with characteristi ard represents.</t>
cs of the organization or organizational units of the object that the jCard repr <section anchor="title-property">
esents.</t> <name>"title" Property</name>
<t>The "title" property has the intent of providing the position or jo
<section anchor="title-property"><name>"title" Property</name> b of the object the jCard represents. Reference <xref section="6.6.1" sectionFor
mat="comma" target="RFC6350"/>.</t>
<t>The "title" property has the intent of providing the position or job of the o <dl spacing="compact" newline="false">
bject the jCard represents. Reference <xref section="6.6.1" sectionFormat="comma <dt>Value type:</dt><dd>A single text value.</dd>
" target="RFC6350"/>.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Value type: A single text value.</t> <artwork><![CDATA[
<t>Cardinality: *</t>
<figure><artwork><![CDATA[
Example: Example:
["title", {}, "text", "Research Scientist"] ["title", {}, "text", "Research Scientist"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="role-property">
<section anchor="role-property"><name>"role" Property</name> <name>"role" Property</name>
<t>The "role" property has the intent of providing the position or job
<t>The "role" property has the intent of providing the position or job of the ob of the object the jCard represents. Reference <xref section="6.6.2" sectionForm
ject the jCard represents. Reference <xref section="6.6.2" sectionFormat="comma" at="comma" target="RFC6350"/>.</t>
target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single text value.</dd>
<t>Value type: A single text value.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["role", {}, "text", "Project Leader"] ["role", {}, "text", "Project Leader"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="logo-property">
<section anchor="logo-property"><name>"logo" Property</name> <name>"logo" Property</name>
<t>The "logo" property has the intent of specifying a graphic image of
<t>The "logo" property has the intent of specifying a graphic image of a logo as a logo associated with the object the jCard represents. Reference <xref section
sociated with the object the jCard represents. Reference <xref section="6.6.3" s ="6.6.3" sectionFormat="comma" target="RFC6350"/>.</t>
ectionFormat="comma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single URI.</dd>
<t>Value type: A single URI.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"] ["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]
["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...>"] <...the remainder of base64-encoded data...>"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="org-property">
<section anchor="org-property"><name>"org" Property</name> <name>"org" Property</name>
<t>The "org" property has the intent of specifying the organizational
<t>The "org" property has the intent of specifying the organizational name and u name and units of the object the jCard represents. Reference <xref section="6.6.
nits of the object the jCard represents. Reference <xref section="6.6.4" section 4" sectionFormat="comma" target="RFC6350"/>.</t>
Format="comma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single structured text value consisting of c
<t>Value type: A single structured text value consisting of components separate omponents separated by the SEMICOLON character (U+003B).</dd>
d by the SEMICOLON character (U+003B).</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"] ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="explanatory-properties">
<section anchor="explanatory-properties"><name>Explanatory Properties</name> <name>Explanatory Properties</name>
<t>These properties provide additional information such as notes or revi
<t>These properties provide additional information such as notes or revisions sp sions specific to the jCard.</t>
ecific to the jCard.</t> <section anchor="categories-property">
<name>"categories" Property</name>
<section anchor="categories-property"><name>"categories" Property</name> <t>The "categories" property specifies application category informatio
n about the object the jCard represents. Reference: <xref section="6.7.1" sectio
<t>The "categories" property specifies application category information about th nFormat="comma" target="RFC6350"/>.</t>
e object the jCard represents. Reference: <xref section="6.7.1" sectionFormat="c <dl spacing="compact" newline="false">
omma" target="RFC6350"/>.</t> <dt>Value type:</dt><dd>One or more text values separated by a COMMA c
haracter
<t>Value type: One or more text values separated by a COMMA character (U+002C).</dd>
(U+002C).</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["categories", {}, "text", "TRAVEL AGENT"] ["categories", {}, "text", "TRAVEL AGENT"]
["categories", {}, "text", "INTERNET,IETF,INDUSTRY"] ["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="note-property">
<section anchor="note-property"><name>"note" Property</name> <name>"note" Property</name>
<t>The "note" property specifies supplemental information or a comment
<t>The "note" property specifies supplemental information or a comment about the about the object the jCard represents. Reference: <xref section="6.7.2" section
object the jCard represents. Reference: <xref section="6.7.2" sectionFormat="co Format="comma" target="RFC6350"/>.</t>
mma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single text value.</dd>
<t>Value type: A single text value.</t> <dt>Cardinality:</dt><dd>*</dd>
</dl>
<t>Cardinality: *</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["note", {}, "text", "This fax number is operational 0800 to 1715 ["note", {}, "text", "This fax number is operational 0800 to 1715
EST\, Mon-Fri."] EST\, Mon-Fri."]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sound-property">
<section anchor="sound-property"><name>"sound" Property</name> <name>"sound" Property</name>
<t>The "sound" property specifies digital sound content information th
<t>The "sound" property specifies digital sound content information that annotat at annotates some aspect of the object the jCard represents. This property is of
es some aspect of the object the jCard represents. This property is often used t ten used to specify the proper pronunciation of the name property value of the j
o specify the proper pronunciation of the name property value of the jCard. Refe Card. Reference: <xref section="6.7.5" sectionFormat="comma" target="RFC6350"/>.
rence: <xref section="6.7.5" sectionFormat="comma" target="RFC6350"/>.</t> </t>
<dl spacing="compact" newline="false">
<t>Value type: A single URI.</t> <dt>Value type:</dt><dd>A single URI.</dd>
<dt>Cardinality:</dt><dd>*</dd>
<t>Cardinality: *</t> </dl>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["sound", {}, "uri", "https://www.example.com/pub/logos ["sound", {}, "uri", "https://www.example.com/pub/logos
/abccorp.mp3"] /abccorp.mp3"]
["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBA ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBA
gICBEAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvb gICBEAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvb
W11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiB W11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiB
<...the remainder of base64-encoded data...>"] <...the remainder of base64-encoded data...>"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="uid-property">
<section anchor="uid-property"><name>"uid" Property</name> <name>"uid" Property</name>
<t>The "uid" property specifies a globally unique identifier correspon
<t>The "uid" property specifies a globally unique identifier corresponding to th ding to the object the jCard represents. Reference: <xref section="6.7.6" sectio
e object the jCard represents. Reference: <xref section="6.7.6" sectionFormat="c nFormat="comma" target="RFC6350"/>.</t>
omma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single URI value. It <bcp14>MAY</bcp14> als
<t>Value type: A single URI value. It MAY also be reset to free-form text.</t> o be reset to free-form text.</dd>
<dt>Cardinality:</dt><dd>*1</dd>
<t>Cardinality: *1</t> </dl>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"] ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="url-property">
<section anchor="url-property"><name>"url" Property</name> <name>"url" Property</name>
<t>The "url" property specifies a uniform resource locator associated
<t>The "url" property specifies a uniform resource locator associated with the o with the object the jCard represents. Reference: <xref section="6.7.8" sectionFo
bject the jCard represents. Reference: <xref section="6.7.8" sectionFormat="comm rmat="comma" target="RFC6350"/>.</t>
a" target="RFC6350"/>.</t> <!-- [rfced] For clarity, we suggest the update below. Please review and let us
know if this acceptable.
<t>There are potential security and privacy implications of providing URLs with
telephone calls. The end client receiving a jCard with a "url" property MUST onl
y display the URL and not automatically follow the URL or provide automatic prev
iew of the URL, and generally provide good practices in making it clear to the u
ser it is their choice to follow the URL in a browser context consistent with al
l of the common browser security and privacy practices available on most consume
r OS environments.</t>
<t>Value type: A single uri value.</t>
<t>Cardinality: *</t> 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.
<figure><artwork><![CDATA[ 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 gen
erally
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" propert
y <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 browse
r context consistent with all of the common browser security and privacy practic
es available on most consumer OS environments.</t>
<dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single uri value.</dd>
<dt>Cardinality:</dt><dd>*</dd>
</dl>
<artwork><![CDATA[
Example: Example:
["url", {}, "uri", "https://example.org/french-rest/chezchic.html"] ["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="version-property">
<section anchor="version-property"><name>"version" Property</name> <name>"version" Property</name>
<t>The "version" property <bcp14>MUST</bcp14> be included and is inten
<t>The "version" property MUST be included and is intended to specify the versio ded to specify the version of the vCard specification used to format this vCard.
n of the vCard specification used to format this vCard. Reference: <xref section Reference: <xref section="6.7.9" sectionFormat="comma" target="RFC6350"/>.</t>
="6.7.9" sectionFormat="comma" target="RFC6350"/>.</t> <dl spacing="compact" newline="false">
<dt>Value type:</dt><dd>A single text value.</dd>
<t>Value type: A single text value.</t> <dt>Cardinality:</dt><dd>1</dd>
</dl>
<t>Cardinality: 1</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Example: Example:
["version", {}, "text", "4.0"] ["version", {}, "text", "4.0"]
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> </section>
</section> <section anchor="extension-of-jcard">
<section anchor="extension-of-jcard"><name>Extension of jCard</name> <name>Extension of jCard</name>
<t>Part of the intent of using jCard is to leverage its extensibility to d
<t>Part of the intent of using jCard is to leverage its extensibility to define efine new properties to relay new information related to a caller. This capabil
new properties to relay new information related to a caller. This capability is ity is inherently supported as part of standard extensibility. However, usage o
inherently supported as part of standard extensibility. However, usage of thos f those new properties should be published and registered following <xref sectio
e new properties should be published and registered following <xref section="3.6 n="3.6" sectionFormat="comma" target="RFC7095"/> or as defined in future specifi
" sectionFormat="comma" target="RFC7095"/> or new specifications.</t> cations.</t>
</section>
</section> <section anchor="IANA">
<section anchor="IANA"><name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="jcard-purpose-parameter-value">
<section anchor="jcard-purpose-parameter-value"><name>'jcard' Purpose Parameter <name>'jcard' Purpose Parameter Value</name>
Value</name> <t>This document defines the 'jcard' value for the 'purpose' parameter o
f the Call-Info header field <xref target="RFC3261"/>. IANA has added this docum
<t>This document defines the 'jcard' value for the 'purpose' parameter of the Ca ent to the list of references for the 'purpose' value of Call-Info in the "Heade
ll-Info header field <xref target="RFC3261"/>. IANA has added this document to t r Field Parameters and Parameter Values" registry within the "Session Initiation
he list of references for the 'purpose' value of Call-Info in the "Header Field Protocol (SIP) Parameters" registry group.</t>
Parameters and Parameter Values" sub-registry of the "Session Initiation Protoco </section>
l (SIP) Parameters" registry.</t> <section anchor="sip-call-info-header-field-call-reason-parameter">
<name>SIP Call-Info Header Field 'call-reason' Parameter</name>
</section> <t>This document defines the 'call-reason' generic parameter for use in
<section anchor="sip-call-info-header-field-call-reason-parameter"><name>SIP Cal the Call-Info header field in the "Header Field Parameters and Parameter Values"
l-Info Header Field 'call-reason' Parameter</name> registry defined by <xref target="RFC3968"/>. The parameter's token is "call-re
ason", and it takes the value of a quoted string.</t>
<t>This document defines the 'call-reason' generic parameter for use as a new pa <table>
rameter in the Call-Info header field in the "Header Field Parameters and Parame <thead><tr><th>Header Field</th><th>Parameter Name</th><th>Predefined Values</
ter Values" registry defined by <xref target="RFC3968"/>. The parameter's token th><th>Reference</th></tr></thead>
is "call-reason", and it takes the value of a quoted string.</t> <tbody><tr><td>Call-Info</td><td>call-reason</td><td>No</td><td>RFC 9796</td><
/tr></tbody>
<figure><artwork><![CDATA[ </table>
+--------------+----------------+-------------------+------------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+------------+
| Call-Info | call-reason | No | [this RFC] |
+--------------+----------------+-------------------+------------+
]]></artwork></figure>
</section>
<section anchor="sip-call-info-header-field-verified-parameter"><name>SIP Call-I
nfo Header Field 'verified' Parameter</name>
<t>This document defines the 'verified' generic parameter for use as a new param
eter 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
"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>
</section> </section>
<section anchor="sip-call-info-header-field-integrity-parameter"><name>SIP Call- <section anchor="sip-call-info-header-field-verified-parameter">
Info Header Field 'integrity' Parameter</name> <name>SIP Call-Info Header Field 'verified' Parameter</name>
<t>This document defines the 'verified' generic parameter for use in the
Call-Info header field in the "Header Field Parameters and Parameter Values" re
gistry 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>
<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></t
r></tbody>
</table>
<t>This document defines the 'integrity' generic parameter for use as a new para </section>
meter in the Call-Info header field in the "Header Field Parameters and Paramete <section anchor="sip-call-info-header-field-integrity-parameter">
r Values" registry defined by <xref target="RFC3968"/>. The parameter's token is <name>SIP Call-Info Header Field 'integrity' Parameter</name>
"integrity", and it takes the value of a quoted string.</t> <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>
<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></t
r></tbody>
</table>
</section>
</section>
<section anchor="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 i
s in the clear anyway. Transport-level security can be used to hide information
from eavesdroppers, and the same confidentiality mechanisms would protect any Ca
ll-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 use
r agent. To ensure the integrity and authenticity of this data, the security fra
mework established by STIR, including the use of the 'rcd'PASSporT as defined in
<xref target="RFC9795"/>, should be followed. This framework enables digital si
gnatures to verify the issuer of assertions related to the calling party's ident
ity, distinguishing persistent identity attributes from transient, per-call deta
ils. Implementers should also consider certificate-based constraints to ensure p
roper binding between caller identity assertions and call-specific metadata whil
e maintaining the integrity of the information throughout transmission. Since Ca
ll-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, en
force 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
?
<figure><artwork><![CDATA[ Current:
+--------------+----------------+-------------------+------------+ The SIP framework, defined in [RFC3261] and the various extensions to
| Header Field | Parameter Name | Predefined Values | Reference | SIP, which includes STIR [RFC8224] and rich call data [RFC9795], since
+--------------+----------------+-------------------+------------+ its existence has provided mechanisms to assert information about the
| Call-Info | integrity | No | [this RFC] | person or entity behind the call.
+--------------+----------------+-------------------+------------+
]]></artwork></figure>
</section> Perhaps:
</section> The SIP framework, defined in [RFC3261] and the various extensions to
<section anchor="Security"><name>Security Considerations</name> 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.
-->
<t>Revealing information such as the name, location, and affiliation of a person <!-- [rfced] What does "weigh this responsibility" refer to? Is it
necessarily entails certain privacy risks. The SIP Call-Info header field has n the core security consideration, the risk of impersonation, or both?
o particular confidentiality requirement, as the information sent in SIP is in t
he clear anyway. Transport-level security can be used to hide information from e
avesdroppers, and the same confidentiality mechanisms would protect any Call-Inf
o 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 in Original (earlier sentences included for context):
tended primarily for providing verified information at the termination of a call It can also
, where a verification service has a trusted UNI relationship with the user agen enable the ability for actors to impersonate a calling party they are
t. To ensure the integrity and authenticity of this data, the security framework not authorized to represent. The core security consideration that
established by STIR, including the use of the 'rcd'PASSporT as defined in <xref either explicitly or implicitly have been acknowledged with any of
target="I-D.ietf-stir-passport-rcd"/>, should be followed. This framework enabl the SIP and STIR specifications is that there is a management and
es digital signatures to verify the issuer of assertions related to the calling policy layer that validates the participants in the ecosystem and
party's identity, distinguishing persistent identity attributes from transient, their use of a SIP network with telephone number identifiers and
per-call details. Implementers should also consider certificate-based constraint identity related information. The use of this specification should
s to ensure proper binding between caller identity assertions and call-specific weigh this responsibility and make the appropriate considerations to
metadata while maintaining the integrity of the information throughout transmiss validate the proper participation and use of these tools follow these
ion. Since Call-Info serves as a means to convey verified caller information to larger security, impersonation prevention, and privacy
the end user, mechanisms should be in place to validate the authenticity of the considerations.
assertion, enforce appropriate certificate associations, and preserve the trustw
orthiness of Rich Call Data from origination to termination.</t>
<t>The SIP framework, defined in <xref target="RFC3261"/> and the various extens Perhaps:
ions to SIP, which stir <xref target="RFC8224"/> and rich call data <xref target Users should assess this [risk / core consideration / both the risk
="I-D.ietf-stir-passport-rcd"/> are included, since its existence has provided m and core consideration] and make the appropriate adjustments to
echanisms to assert information about the person or entity behind the call. This validate proper participation while following these
can be a feature that can be a benefit to the SIP network that allows users to larger security, impersonation prevention, and privacy
help identify the calling party behind an abstract telephone number. It can also considerations.
enable the ability for actors to impersonate a calling party they are not autho -->
rized to represent. The core security consideration that either explicitly or im <t>The SIP framework, defined in <xref target="RFC3261"/> and the various
plicitly have been acknowledged with any of the SIP and stir specifications is t extensions to SIP which includes STIR <xref target="RFC8224"/> and rich call dat
hat there is a management and policy layer that validates the participants in th a <xref target="RFC9795"/>, since its existence has provided mechanisms to asser
e ecosystem and their use of a SIP network with telephone number identifiers and t information about the person or entity behind the call. This feature that can
identity related information. The use of this specification should weigh this r be a benefit to the SIP network that allows users to help identify the calling p
esponsibility and make the appropriate considerations to validate the proper par arty behind an abstract telephone number. It can also enable the ability for act
ticipation and use of these tools follow these larger security, impersonation pr ors to impersonate a calling party they are not authorized to represent. The cor
evention, and privacy considerations.</t> e security consideration that has either explicitly or implicitly been acknowled
ged with any of the SIP and STIR specifications is that there be a management an
d policy layer that validates the participants in the ecosystem and their use of
a SIP network with telephone number identifiers and identity-related informatio
n. The use of this specification should weigh this responsibility and make the a
ppropriate considerations to validate the proper participation and use of these
tools following these larger security, impersonation prevention, and privacy con
siderations.</t>
<t>The use of this specification with the insertion of metadata related to
a caller or the purpose of the call should recognize the risk that this informa
tion 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 thr
eat 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 con
tent 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 mechanisms entirely, and methods to restrict or disable the po
tential exposure should be considered to mitigate these concerns. Largely, any i
nformation that is included in rich call data should be considered public, and t
his specification does not define any mechanism to protect this information beyo
nd the security and privacy associated with the SIP signalling itself. This is a
property that is consistent with SIP more generally, and this specification fol
lows a similar pattern for its use.</t>
<!--[rfced] May this be rephrased for readability? If so, who should
do the considering?
<t>The use of this specification with the insertion of meta data related to a ca Original:
ller or the purpose of the call should recognize the risk that this information A network specific
can be viewed by those network elements and participants in the delivery of the set of policies or best practices for the use and hosting of media
SIP call. The insertion of media directly or via Base64 encoding or using a remo content that is agreed to contain validated media resources that have
te URI that query network resources should be considered as a potential threat v been evaluated to not pose a security threat to the participants or
ector to the user or user agent that could potentially allow the parsing of docu the devices supported in the ecosystem should be considered.
ments 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 d
isable these mechanisms entirely and methods to restrict or disable these potent
ial concerns should be considered to mitigate these concerns. Largely, any infor
mation that is included in rich call data should be considered public and this s
pecification does not define any mechanism to protect this information beyond th
e security and privacy associated with the SIP signalling itself. This is a prop
erty that is consistent with SIP more generally and this specification follows a
similar pattern for its use.</t>
<t>This specification contains the ability to include media resources and URI an Perhaps:
d URL resource references to media resources that could pose a threat when refer Network administrators should consider a network-specific
encing or decoding the content of these media resources similar to threats that set of policies or best practices for the use and hosting of media
web browsers and other media decoding applications must be concerned about. A ne content that is agreed to contain validated media resources that have
twork specific set of policies or best practices for the use and hosting of medi been evaluated to not pose a security threat to the participants or
a content that is agreed to contain validated media resources that have been eva the devices supported in the ecosystem.
luated to not pose a security threat to the participants or the devices supporte -->
d in the ecosystem should be considered.</t> <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 media resources, which is similar
to threats that web browsers and other media decoding applications must be conce
rned about. 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 th
at 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>
<references anchor="sec-combined-references">
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
392.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
261.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
966.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
968.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
095.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
852.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
903.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
225.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
259.xml"/>
</section> <!-- companion: RFC 9795 - draft-ietf-stir-passport-rcd-26 -->
</middle> <reference anchor="RFC9795" target="https://www.rfc-editor.org/info/rfc9
795">
<front>
<title>Personal Assertion Token (PASSporT) Extension for Rich Call D
ata</title>
<author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos Inc.</organization>
</author>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization>Neustar Inc.</organization>
</author>
<date month="May" year='2025'/>
</front>
<seriesInfo name="RFC" value="9795"/>
<seriesInfo name="DOI" value="10.17487/RFC9795"/>
</reference>
<back> <!-- [rfced] Regarding [W3C-SRI], the original URL
for this reference directed the reader to a W3C First Public Working Draft
with a date of 22 April 2025. However, the original date provided for
this reference was 23 June 2016, which matches that of the W3C
Recommendation titled "Subresource Integrity"
(https://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this
reference to that.
<references title='References' anchor="sec-combined-references"> However, please let us know if you intended to point to
the First Public Working Draft (https://www.w3.org/TR/2025/WD-sri-2-20250422/)
or otherwise.
<references title='Normative References' anchor="sec-normative-references"> Original:
[W3C-SRI] W3C, "Subresource Integrity", 23 July 2016,
<https://www.w3.org/TR/SRI/>.
<reference anchor="RFC2392"> Current:
<front> [W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J.
<title>Content-ID and Message-ID Uniform Resource Locators</title> Weinberger, Ed., "Subresource Integrity", W3C
<author fullname="E. Levinson" initials="E." surname="Levinson"/> Recommendation, 23 June 2016,
<date month="August" year="1998"/> <https://www.w3.org/TR/2016/REC-SRI-20160623/>.
<abstract> -->
<t>The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow ref
erences to messages and the body parts of messages. For example, within a single
multipart message, one HTML body part might include embedded references to othe
r 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">
<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"/>
<author fullname="A. Johnston" initials="A." surname="Johnston"/>
<author fullname="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 applicati
on-layer control (signaling) protocol for creating, modifying, and terminating s
essions 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"/>
<date month="December" year="2004"/>
<abstract>
<t>This document specifies the URI (Uniform Resource Identifier) scheme "t
el". The "tel" URI describes resources identified by telephone numbers. This doc
ument obsoletes RFC 2806. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3966"/>
<seriesInfo name="DOI" value="10.17487/RFC3966"/>
</reference>
<reference anchor="RFC3968">
<front>
<title>The Internet Assigned Number Authority (IANA) Header Field Parameter
Registry for the Session 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) regi
stry for the Session Initiation Protocol (SIP) header field parameters and param
eter values. It also lists the already existing parameters and parameter values
to be used as the initial entries for this registry. This document specifies an
Internet Best Current Practices for the Internet Community, and requests discuss
ion 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 describes the commonly used base 64, base 32, and base 16
encoding schemes. It also discusses the use 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>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/
>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="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 spe
cification documents ABNF. It balances compactness and simplicity with reasonabl
e representational power. The differences between standard BNF and ABNF involve
naming rules, repetition, alternatives, order-independence, and value ranges. Th
is specification also supplies additional rule definitions and encoding for a co
re lexical analyzer of the type common to several Internet specifications. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</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 for representing and exchan
ging a variety of information about individuals and other entities (e.g., format
ted and structured name and delivery addresses, email address, multiple telephon
e numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 24
25, 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>
<reference anchor="RFC7095">
<front>
<title>jCard: The JSON Format for vCard</title>
<author fullname="P. Kewisch" initials="P." surname="Kewisch"/>
<date month="January" year="2014"/>
<abstract>
<t>This specification defines "jCard", a JSON format for vCard data. The v
Card data format is a text format for representing and exchanging information ab
out individuals and other entities, for example, telephone numbers, email addres
ses, structured names, and delivery addresses. JSON is a lightweight, text-based
, language- independent data interchange format commonly used in Internet applic
ations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7095"/>
<seriesInfo name="DOI" value="10.17487/RFC7095"/>
</reference>
<reference anchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="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 claim
s to be transferred between two parties. The claims in a JWT are encoded as a JS
ON 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>
<author fullname="R. Gellens" initials="R." surname="Gellens"/>
<author fullname="B. Rosen" initials="B." surname="Rosen"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
<author fullname="R. Marshall" initials="R." surname="Marshall"/>
<author fullname="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 co
nnected, and all service providers in the path of the call have information abou
t the call, the caller, or the location, which is helpful for the PSAP to have i
n 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 descr
ibed here.</t>
<t>The mechanisms permit the data to be conveyed by reference (as an exter
nal 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 w
here 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>
<author fullname="S. Leonard" initials="S." surname="Leonard"/>
<date month="September" year="2016"/>
<abstract>
<t>This document registers media types for certain image formats promulgat
ed 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 Bitm
ap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image f
iles 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>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="C. Wendt" initials="C." surname="Wendt"/>
<date month="February" year="2018"/>
<abstract>
<t>The baseline security mechanisms in the Session Initiation Protocol (SI
P) are inadequate for cryptographically assuring the identity of the end users t
hat originate SIP requests, especially in an interdomain context. This document
defines a mechanism for securely identifying originators of SIP requests. It doe
s so by defining a SIP header field for conveying a signature used for validatin
g 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>
<author fullname="C. Wendt" initials="C." surname="Wendt"/>
<author fullname="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 Pe
rsonal Assertion Token, PASSporT, is cryptographically signed to protect the int
egrity of the identity of the originator and to verify the assertion of the iden
tity 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. PASSpor
T is particularly useful for many personal-communications applications over IP n
etworks 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>
<author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
<date month="December" year="2017"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, languag
e-independent data interchange format. It was derived from the ECMAScript Progra
mming Language Standard. JSON defines a small set of formatting rules for the po
rtable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications of JSON
, repairs specification errors, and offers experience-based interoperability gui
dance.</t>
</abstract>
</front>
<seriesInfo name="STD" value="90"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
</reference>
<reference anchor="I-D.ietf-stir-passport-rcd"> <reference anchor="W3C-SRI" target="https://www.w3.org/TR/2016/REC-SRI-2
<front> 0160623/">
<title>PASSporT Extension for Rich Call Data</title> <front>
<author fullname="Chris Wendt" initials="C." surname="Wendt"> <title>Subresource Integrity</title>
<organization>Somos Inc.</organization> <author fullname="Devdatta Akhawe" role="editor" />
</author> <author fullname="Frederik Braun" role="editor" />
<author fullname="Jon Peterson" initials="J." surname="Peterson"> <author fullname="Francois Marier" role="editor" />
<organization>Neustar Inc.</organization> <author fullname="Joel Weinberger" role="editor" />
</author> <date year="2016" month="June" day="23"/>
<date day="5" month="June" year="2023"/> </front>
<abstract> <refcontent>W3C Recommendation</refcontent>
<t> This document extends PASSporT, a token for conveying </reference>
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 to the called party. This framework is
intended to include and extend caller and call specific information
beyond human-readable display name comparable to the &quot;Caller ID&quot;
function common on the telephone network and is also enhanced with a
integrity mechanism that is designed to protect the authoring and
transport of this information for different authoritative use-cases.
</t> <!-- XML for the W3C Public Working Draft Version of
</abstract> [W3C-SubresourceIntegrity]
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-stir-passport-rcd-26"/>
</reference> <reference anchor="W3C-SRI" target="https://www.w3.org/TR/2025/WD-sri-2-
20250422/">
<front>
<title>Subresource Integrity</title>
<author fullname="Frederik Braun" role="editor" />
<date year="2025" month="April" day="25"/>
</front>
<refcontent>W3C First Public Working Draft</refcontent>
</reference>
-->
<reference anchor="W3C-SRI" target="https://www.w3.org/TR/SRI/"> <reference anchor="W3C-SVGTiny1.2" target="https://www.w3.org/TR/2008/RE
<front> C-SVGTiny12-20081222/">
<title>Subresource Integrity</title> <front>
<author > <title>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</title>
<organization>W3C</organization> <author fullname="Ola Anderssone" role="editor" />
</author> <author fullname="Robin Berjon" role="editor" />
<date year="2016" month="July" day="23"/> <author fullname="Erik Dahlström" role="editor" />
</front> <author fullname="Andrew Emmons" role="editor" />
</reference> <author fullname="Jon Ferraiolo" role="editor" />
<reference anchor="W3C-SVGTiny1.2" target="https://www.w3.org/TR/SVGMobile/"> <author fullname="Anthony Grasso" role="editor" />
<front> <author fullname="Vincent Hardy" role="editor" />
<title>Scalable Vector Graphics (SVG) Tiny 1.2</title> <author fullname="Scott Hayman" role="editor" />
<author > <author fullname="Dean Jackson" role="editor" />
<organization>W3C</organization> <author fullname="Chris Lilley" role="editor" />
</author> <author fullname="Cameron McCormack" role="editor" />
<date year="2008" month="December" day="22"/> <author fullname="Andreas Neumann" role="editor" />
</front> <author fullname="Craig Northway" role="editor" />
</reference> <author fullname="Antoine Quint" role="editor" />
<reference anchor="ITUJPEG" > <author fullname="Nandini Ramani" role="editor" />
<front> <author fullname="Doug Schepers" role="editor" />
<title>Information technology - Digital compression and coding of continuous <author fullname="Andrew Shellshear" role="editor" />
-tone still images, JPEG File Interchange Format (JFIF) ITU-T Recommendation T.8 <date year="2008" month="December" day="22"/>
71, ISO/IEC 10918-5</title> </front>
<author > <refcontent>W3C Recommendation</refcontent>
<organization>ITU-T</organization> </reference>
</author>
<date year="2013" month="May"/>
</front>
</reference>
<reference anchor="ISOPNG" >
<front>
<title>Information technology -- Computer graphics and image processing -- P
ortable Network Graphics (PNG), Functional specification, ISO/IEC 15948:2004</ti
tle>
<author >
<organization>ISO/IEC</organization>
</author>
<date year="2004" month="March"/>
</front>
</reference>
<reference anchor="RFC2119"> <!-- [rfced] Regarding [ITUJPEG]: This reference uses the date for the ISO/IEC
<front> Standard ISO/IEC 10918-5 (May 2013), but points to the ITU-T
<title>Key words for use in RFCs to Indicate Requirement Levels</title> Recommendation which was published in May 2011
<author fullname="S. Bradner" initials="S." surname="Bradner"/> (https://www.itu.int/rec/T-REC-T.871-201105-I/en). We have updated this
<date month="March" year="1997"/> reference to use the date for the ITU-T Recommendation and added a URL
<abstract> pointing to that specification. Please let us know if you have any
<t>In many standards track documents several words are used to signify the concerns.
requirements in the specification. These words are often capitalized. This docu -->
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> <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 co
ntinuous-tone still images: JPEG File Interchange Format (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>
<references title='Informative References' anchor="sec-informative-reference s"> <!-- [rfced] We have added a URL to the [ISOPNG] reference. Please let us know if you have any concerns.
<reference anchor="RFC2361"> Current:
<front> [ISOPNG] ISO/IEC, "Information technology - Computer graphics and
<title>WAVE and AVI Codec Registries</title> image processing - Portable Network Graphics (PNG),
<author fullname="E. Fleischman" initials="E." surname="Fleischman"/> Functional specification", ISO/IEC 15948:2004, March 2004,
<date month="June" year="1998"/> <https://www.iso.org/standard/29581.html>.
<abstract> -->
<t>The purpose of this paper is to establish a mechanism by which codecs r <reference anchor="ISOPNG" target="https://www.iso.org/standard/29581.ht
egistered within Microsoft's WAVE and AVI Registries may be referenced within th ml">
e IANA Namespace by Internet applications. This memo provides information for th <front>
e Internet community. It does not specify an Internet standard of any kind.</t> <title>Information technology -- Computer graphics and image process
</abstract> ing -- Portable Network Graphics (PNG), Functional specification</title>
</front> <author>
<seriesInfo name="RFC" value="2361"/> <organization>ISO/IEC</organization>
<seriesInfo name="DOI" value="10.17487/RFC2361"/> </author>
</reference> <date year="2004" month="March"/>
<reference anchor="RFC3325"> </front>
<front> <seriesInfo name="ISO/IEC" value="15948:2004"/>
<title>Private Extensions to the Session Initiation Protocol (SIP) for Asser </reference>
ted 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 re
placed many traditional telephony deployments. Interworking VoIP systems with th
e traditional telephone network has reduced the overall level of calling party n
umber and Caller ID assurances by granting attackers new and inexpensive tools t
o impersonate or obscure calling party numbers when orchestrating bulk commercia
l calling schemes, hacking voicemail boxes, or even circumventing multi-factor a
uthentication systems trusted by banks. Despite previous attempts to provide a s
ecure assurance of the origin of SIP communications, we still lack effective sta
ndards for identifying the calling party in a VoIP session. This document examin
es 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 h
igh-level requirements for a solution in this space.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7340"/>
<seriesInfo name="DOI" value="10.17487/RFC7340"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
361.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
340.xml"/>
</references>
</references> </references>
</references> <section numbered="false" anchor="Acknowledgements">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="David Hancock"/>, <contact fu
llname="Alec Fenichel"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname=
"Yi Jing"/> and other members of the SIPCORE and STIR working groups and ATIS/SI
P Forum IPNNI for their helpful suggestions and comments during the creation of
this document.</t>
</section>
</back>
<?line 852?> <!-- [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.
<section numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name 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.
<t>We would like to thank David Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing an d 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> rich call data vs. Rich Call Data
</section> 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?
-->
</back> <!-- [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)
.
-->
<!-- ##markdown-source: <!-- [rfced] Please review the "Inclusive Language" portion of the online
H4sIAAAAAAAAA+1923IbV5LgO7/iLPwgsRuACN5EUa2OpihKplqiaJGyx+tx Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
TBSAAlESUAVXFQhCGm30Z+xG7P5cf8nm9VyqCiAla2K6d8cRtkGg6lwy8+Q9 and let us know if any changes are needed. Updates of this nature typically
83Q6nY0yKSfxobk4PTfH0WTSOU1HmTmP8mgal3FemFGWm7fJYEy/mmdRGW1E result in more precise language, which is helpful for readers.
/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==
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 141 change blocks. 
1707 lines changed or deleted 1369 lines changed or added

This html diff was produced by rfcdiff 1.48.