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
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>
<section anchor="terminology"><name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show
n here.</t>
</section>
<section anchor="overview"><name>Overview</name>
<t>This document provides a framework for the use of Call-Info header field to c
arry RCD in SIP <xref target="RFC3261"/>. The Call-Info header field (defined in
<xref section="20.9" sectionFormat="comma" target="RFC3261"/>) defines a 'purpo
se' parameter. In addition to providing guidance on calling name practices and t
he use of the existing 'purpose' parameter token, "icon", this document expands
on other types of RCD by defining a new 'purpose' token, "jcard", and three new
parameters, 'call-reason', 'verified', and 'integrity' for the Call-Info header
field to align with RCD as defined in the STIR framework <xref target="RFC8224"/
> and with "rcd" PASSporTs defined in <xref target="I-D.ietf-stir-passport-rcd"/
>.</t>
<t>The 'purpose' parameter token "jcard" is used to associate RCD related to the
identity of the calling party in the form of a jCard <xref target="RFC7095"/>.
While there is a "card" token defined in <xref target="RFC3261"/> which could be
considered to have an overlapping purpose, the "jcard" token is intended to den
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
ntent or reason for calling to help the called party understand the context and
intent of the call and why they may want to answer the call.</t>
<t>The new Call-Info header field parameter 'verified' provides an indication, w
ith the value "true", to represent the results of the verification procedures th
at were performed by the sender of the Call-Info header field. The new Call-Info
header field parameter 'integrity' provides a mechanism to associate an integri
ty hash string, as defined in Section 8.2 of <xref target="I-D.ietf-stir-passpor
t-rcd"/>, that is associated with the content of the resource referenced by the
URI represented 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 co
mplementary to the RCD framework defined in <xref target="I-D.ietf-stir-passport
-rcd"/>. Typically, a SIP-based session involves multiple hops through different
trusted and untrusted networks. The STIR framework <xref target="RFC7340"/> add
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>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>
<t>As discussed in <xref target="I-D.ietf-stir-passport-rcd"/>, the calling name
uses the display-name value of the From header field <xref target="RFC3261"/> o
f the request. Alternatively, for some calls, the calling name may come from the
P-Asserted-ID header field <xref target="RFC3325"/>. While this is out of scope
for Call-Info header field in terms of the representation of the display-name v
alue, this document does discuss the representation of the verification of this
value using the 'verified' parameter.</t>
<t>For logos or icons that can represent the calling party, the 'purpose' token
"icon" <xref target="RFC3261"/> is used to indicate a URI for an image resource
that can be displayed to the user receiving the SIP request. For the purpose of
this document and the transmission of RCD, the "icon" 'purpose' token should be
used as defined. Section 8.2 provides high-level guidance on image formatting an
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>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>
</section> <t>This document defines usage of the SIP Call-Info header field <xref tar
<section anchor="jcard-call-info-purpose-token"><name>"jcard" Call-Info 'purpose get="RFC3261"/> that allows called parties to receive a more comprehensive and e
' Token</name> xtensible set of Rich Call Data (RCD) for incoming calls. It defines specific us
age of the Call-Info header field, a new parameter ('call-reason'), and a new to
ken ("jcard") for the 'purpose' parameter of the Call-Info header field. Dependi
ng on the policies of the communications system, a calling party could be either
the end user device (e.g., a SIP user agent (UA)) or a network service as part
of a telephone service provider. Similarly, a called party could be an end user
device or the network telephone service provider acting on behalf of the recipie
nt 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 Call-Info 'purpose' token "jcard" indicates support of RCD associated wit <t>Alternatively, this specification can be utilized in conjunction with t
h the identity of a calling party in a SIP call <xref section="20.9" sectionForm he protocols defined in <xref target="RFC9795"/> as part of the communications s
at="comma" target="RFC3261"/>. The format of a Call-Info header field when using ignaling path, specifically in the trusted User-Network Interface (UNI) device i
the "jcard" token is as follows.</t> nterface at the terminating side as part of an authenticated, network-to-device,
trusted signaling where a device may not have the ability to verify the "rcd" P
ASSporT, but it can receive the RCD information from the Call-Info header field
as defined in this specification.</t>
<t>This specification provides an approach for the delivery of jCard data
that utilizes the same mechanism as <xref target="RFC7852"/> which defined a 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>
<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> <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 the following primary RCD elements: a calling name, a l ogo or icon associated with the caller, and a call reason string. It also discus ses an extensible way to carry caller information using jCard <xref target="RFC7 095"/>.</t>
<t>Because the use and purpose of this specification is to provide a single pres <t>The RCD framework defined both in this document as well as in <xref tar
entation of rich call data information, a call and its corresponding single RCD- get="RFC9795"/> carries call-specific information. The insertion of RCD is inten
related Call-Info header field MUST only contain a single jCard object represent ded to be singular in that the receiving party should not be required to make an
ed by an array with two elements. The array MUST only include a single first ele y call-specific decisions based on redundant, duplicate, or conflicting RCD. The
ment with the string "vcard", and the second element is an array of jCard proper RCD information is either intended to be added by a party that is authoritative
ties corresponding to the single entity jCard object.</t> 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 trusted and verified caller RCD information inserted in the RCD Call-Info
header field <bcp14>MUST NOT</bcp14> be modified or altered. The user should be
able to
trust that the RCD information accurately represents the verified information.
This specification acknowledges that without the use of STIR or other mechanisms
, detection of any modifications is not possible, so guidance for the use of thi
s specification in a trusted UNI part of the network is important.</t>
<t>The fields like "fn", "photo", or "logo" if used with the use of "icon" or ca <t>As discussed in <xref target="RFC9795"/>, the calling name uses the dis
lling name in From or P-Asserted-ID header field or purpose token, as described play-name value of the From header field <xref target="RFC3261"/> of the request
in the previous section, MUST match if present to allow the called party to clea . Alternatively, for some calls, the calling name may come from the P-Asserted-I
rly determine the intended calling name or icon.</t> 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. <xref target="RFC9795" section="8.2" sectionFormat="of"/>
provides high-level guidance on image formatting 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 RCD information, a call and its corresponding single RCD-relat
ed Call-Info header field <bcp14>MUST</bcp14> only contain a single jCard object
represented by an array with two elements. The array <bcp14>MUST</bcp14> only i
nclude a single first element with the string "vcard", and the second element is
an array of jCard properties corresponding to the single entity jCard object.</
t>
<t>An example of a Call-Info header field is:</t> <t>jCard has multiple fields that may convey similar information, for exam ple, "fn", “n”, or “nickname” are strings that represent names in different ways , or "photo" or "logo" represent a picture. Users of this specification should m ake sure there is consistency for the calling name string corresponding to the s ingle name in the SIP From or P-Asserted-ID header field or a “logo” or “photo” corresponds to the RCD “icon” as described in the previous section. As described in <xref target="RFC8224"/> and <xref target="RFC9795"/> verification procedure s, the values represented in the RCD <bcp14>MUST</bcp14> match the corresponding information in the SIP message to enable proper verification of calling name or icon consistently.</t>
<figure><artwork><![CDATA[ <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 142
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 181
--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>
<t>In the case that there is only a 'call-reason' or 'verified' parameter or any
future parameters that may be defined and no need for a purpose parameter with
no associated URI the null data URI, "data:" is used as the URI. The purpose par
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[ <t>For ‘call-reason’ or ‘verified’ parameters defined in this document tha
t do not require an associated URI or for future parameters that do not require
an associated URI, the Call-Info header field URI should be set to the null data
URI, “data:”.
The purpose parameter "jcard", defined in this document, is used to avoid any co
nflicts or confusion with existing implementations and previously defined purpos
e parameters. 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> <section anchor="verified-call-info-parameter">
<section anchor="verified-call-info-parameter"><name>'verified' Call-Info Parame <name>'verified' Call-Info Parameter</name>
ter</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
<t>The 'verified' parameter extends and complements the content conveyed by the ent that the information contained in the Call-Info header field has been verifi
RCD-related Call-Info header field. This parameter indicates to the recipient th ed by verification procedures for claims defined in <xref section="8" target="RF
at the information contained in the Call-Info header field has been verified by C9795"/>. The presence of a 'verified' parameter on a Call-Info header field sho
verification procedures for claims defined in Section 8 of <xref target="I-D.iet uld be considered specific to the information for that Call-Info header field on
f-stir-passport-rcd"/>. The presence of a 'verified' parameter on a Call-Info he ly. If there is a Call-Info header field corresponding to information defined in
ader field should be considered specific to the information for that Call-Info h this specification that doesn't contain a 'verified' parameter, the recipient s
eader field only. If there is a Call-Info header field corresponding to informat hould assume that information was not received and verified corresponding to the
ion defined in this specification that doesn't contain a 'verified' parameter, t verification procedures defined in <xref section="8" target="RFC9795"/>.</t>
he recipient should assume that information was not received and verified corres <t>There is a single valid value associated with the 'verified' parameter
ponding to the verification procedures defined in Section 8 of <xref target="I-D of 'true'. The value 'true' indicates to the recipient that the party that inclu
.ietf-stir-passport-rcd"/>.</t> 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,
<t>There is a single valid value associated with the 'verified' parameter of 'tr the recipients'
ue'. The value 'true' indicates to the recipient that the party that included th ability to trust the 'verified' parameter is based on the trusted
e Call-Info header field performed a successful verification of the information relationship with the party from whom they are receiving the SIP request.
represented. As a general principle of Call-Info header field information, the r </t>
ecipients ability to trust the 'verified' parameter is based on the trusted rela
tionship of whom they are receiving the SIP request.</t>
<t>Example where the parameter verified="true" is used to represent that a verif
ication procedure has been performed within a trust domain to indicate the 'icon
' URL has been successfully verified:</t>
<figure><artwork><![CDATA[ <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>Example SIP INVITE described above:</t>
<figure><artwork><![CDATA[ <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.
This document defines that the display-name information in either the From and/o
r P-Asserted-ID header field has been verified via RCD PASSporT verification pro
cedures when the following is present: a ‘purpose’ parameter tokens of “jcard”,
a Call-Info header field with a null data URI “data:”, and a verified parameter
equal to “true”.
</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 262
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="integrity-call-info-parameter">
<section anchor="integrity-call-info-parameter"><name>'integrity' Call-Info Para <name>'integrity' Call-Info Parameter</name>
meter</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
<t>The 'integrity' parameter extends and complements the integrity information c er field. This parameter is used to indicate, for a URI represented in the Call-
onveyed specifically by the 'rcdi' claim in the RCD-related Call-Info header fie Info header field, that the resource referenced by that URI has an associated in
ld. This parameter is used to indicate, for a URI represented in the Call-Info h tegrity hash value, based conceptually on <xref target="W3C-SRI"/>. <xref sectio
eader field, the resource referenced by that URI has an associated integrity has n="6" target="RFC9795"/> describes the procedures for the creation of the digest
h value, based conceptually on <xref target="W3C-SRI"/>. Section 6 of <xref targ value including the hash algorithm indicator a '-' separator and the hash value
et="I-D.ietf-stir-passport-rcd"/> describes the procedures for the creation of t as a string. The JSON pointer object container described as the container of th
he digest value including the hash algorithm indicator a '-' separator and the h e 'rcdi' hashes is not necessary because each hash value should only correspond
ash value as a string. The JSON pointer object container described as the contai to a single URI. Corresponding to guidance defined in <xref section="6" target="
ner of the 'rcdi' hashes is not necessary since each hash value should only corr RFC9795"/>, implementations of this specification <bcp14>MUST</bcp14> support th
espond to a single URI. Corresponding to guidance defined in Section 6 of <xref e hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are iden
target="I-D.ietf-stir-passport-rcd"/>, implementations of this specification MUS tified by "sha256", "sha384", and "sha512", respectively.</t>
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>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>
<t>Example STIR RCD PASSporT:</t> <t> Assuming the URI and the resource pointing
to the URI don't change between the STIR RCD PASSporT and the Call-
Info URI value, the integrity value can typically be used as the same
corresponding string in both the "rcdi" claim and the 'integrity'
parameter. </t>
<figure><artwork><![CDATA[ <aside><t>Note: When the ‘rcdi’ claim is part of the successfully verified
RCD PASSporT, the Call-Info Header Field should include both the ‘verified’ and
‘integrity’ parameters.
Creation of a Call-Info header field based on an identity header field that carr
ies RCD claims that does not pass verification procedures is not suggested (i.e.
, the inclusion of an 'integrity' parameter without a properly included 'verifie
d' parameter).</t></aside>
<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 299
"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 327
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>
<t>The procedures for the usage of URIs and 'purpose' parameter tokens should fo
llow the procedures defined in <xref target="RFC3261"/>. The general management
and provisioning of Rich Call Data for an initiating party does require 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 inserte
d as part of the receiving part of the transition from NNI to UNI, the informati
on populated in a received stir ‘rcd’ PASSporT that is verified is a general ant
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
ng set of Call-Info header fields shows the use of multiple 'purpose' parameters
to indicate a jCard and an icon and also a 'call-reason' parameter:</t>
<t>Example STIR RCD PASSporT:</t> <t>The procedures for the usage of URIs and 'purpose' parameter tokens sho
uld follow the procedures defined in <xref target="RFC3261"/>. The general manag
ement and provisioning of RCD for an initiating party requires a lot of validati
on of information regarding that specific initiating party, which is out of scop
e of this document.
Since the ‘rcd’ Call-Info header field is verified during the transition from th
e Network-to-Network Interface (NNI) to the User-to-Network Interface (UNI), a c
ommon approach is to extract and translate the verified information from a recei
ved STIR ‘rcd’ PASSporT into this header field. This allows the RCD to be delive
red to the end user device through the UNI.
</t>
<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 Call-Info 'p
urpose' tokens to indicate "jCard" and "icon" and also a 'call-reason' Call-Info
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 361
"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>
<t>When one or more URIs are used in a jCard, it is important to note th
<section anchor="usage-of-uris-in-jcard"><name>Usage of URIs in jCard</name> at any URI-referenced data, with the exception of the top-level usage of "jcl" a
s a URI to the jCard itself <bcp14>MUST NOT</bcp14> contain any URI references.
<t>When one or more URIs are used in a jCard, it is important to note that any U In other words, the jCard can have URI references as
RI-referenced data, with the exception of the top-level usage of "jcl" as a URI defined in the jCard specification and this document, but the content
to the jCard itself MUST NOT contain any URI references. In other words, the jCa referenced by those URIs MUST NOT have any URIs; therefore, the client <bcp14>
rd can have URI references as defined in the jCard specification and this docume MUST</bcp14>
nt, but the content referenced by those URIs MUST NOT have any URIs, and therefo ensure that those URI references are not followed, and any URIs that are
re MUST be enforced by the client to not follow those URI references or not rend present in that specific URI-linked content are not rendered.
er that content to the user if any URI are present in that specific URI linked c The purpose of this is to control the security and more specifically to align wi
ontent. The purpose of this is to control the security and more specifically to th the content-integrity mechanism defined in <xref target="RFC9795"/>. There is
align with the content-integrity mechanism defined in <xref target="I-D.ietf-sti not anticipated to be need for which deeper URI references would be required or
r-passport-rcd"/>. There is not anticipated to be need for which deeper URI refe even supported by the typical use of current jCard properties. However, because
rences would be required or even supported by the typical use of current jCard p jCard is extensible, this rule is set to restrict further extension without the
roperties. However, because jCard is extensible, this rule is set to restrict fu proper consideration of security and integrity properties of both Call-Info usa
rther extension without the proper consideration of security and integrity prope ge as well as the RCD and STIR signing of the data <xref target="RFC9795"/> <xre
rties of both Call-Info usage as well as the RCD and STIR signing of the data <x f target="RFC8224"/>.</t>
ref target="I-D.ietf-stir-passport-rcd"/> <xref target="RFC8224"/>.</t> </section>
<section anchor="multimedia-data">
</section> <name>Usage of Multimedia Data in jCard or with the “icon” Call-Info ‘pu
<section anchor="multimedia-data"><name>Usage of Multimedia Data in jCard or wit rpose’ Token</name>
h 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
<t>For the use of the 'purpose' token "icon" or for the cases where the jCard ei a Base64 encoding (<xref section="4" target="RFC4648"/>), this document provides
ther incorporates URIs or includes digital images and sounds directly via Base64 guidance at the time of writing that can be adopted to facilitate the successfu
encoding (Section 4 of <xref target="RFC4648"/>), this document provides guidan l decoding and rendering of these images and media formats. Note that media form
ce at the time of writing that can be adopted to facilitate the successful decod ats are likely something implementers need to consider for their specific applic
ing and rendering of these images and media formats, noting that media formats i ation.</t>
s likely something implementers need to consider for their specific application. <t>For images, such as for the "photo" and "logo" properties, the defaul
</t> 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
<t>For images, such as for the "photo" and "logo" properties, the default image ages. Supporting older telephone devices that only support bitmap (BMP) images
formats SHOULD be PNG <xref target="ISOPNG"/> or JPEG <xref target="ITUJPEG"/>, <xref target="RFC7903"/> with a lower bit range (e.g., 16-bit, 8-bit, or 1-bit),
as these files are commonly used to support 24-bit RGB images. Supporting older or grayscale, or 1-bit black and white color displays, should be considered opt
telephone devices that only support bitmap (BMP) images <xref target="RFC7903"/ ional or even not recommended because, at the time of writing, they are becoming
> with a lower bit range (e.g., 16-bit, 8-bit, or 1-bit), or grayscale, or 1-bit increasingly rare (i.e., typically, devices either have color or color-aware gr
black and white color displays, should be considered optional or even not recom aphical displays that support PNG or JPEG formats or they are exclusively textua
mended because, at the time of writing, they are becoming increasingly rare (i.e l displays).</t>
., typically, devices either have color or color-aware graphical displays that s <t>In addition, vector images are increasingly popular to use as icons b
upport PNG or JPEG formats or they are exclusively textual displays).</t> 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
<t>In addition, vector images are increasingly popular to use for icons because r vector images. At a minimum, the SVG Tiny 1.2 specification <xref target="W3C-
they support scalable images without having to send multiple resolutions. The SV SVGTiny1.2"/> <bcp14>SHOULD</bcp14> be supported as an additional default format
G format has gained wide support as of this writing as a common format for vecto for devices.</t>
r images. At a minimum, the SVG Tiny 1.2 specification <xref target="W3C-SVGTiny <t>For the cases where image files are referenced by URIs as file resour
1.2"/> SHOULD be supported as an additional default format for devices.</t> 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
<t>For the cases where image files are referenced by URIs as file resources, thi s the height and width of the image to the end device for the convenience of det
s document defines a character string that SHOULD be concatenated onto the end o ermining the appropriate resolution to retrieve files without the need to retrie
f a file name, but before the file extension, that signals the height and width ve all the image files. It is also recommended that images have a square aspect
of the image to the end device for the convenience of determining the appropriat ratio with equal height and width and with a power-of-two value for the number o
e resolution to retrieve without the need to retrieve all the image files. It is f pixels (e.g., 32x32, 128x128, 512x512). The format of the string should be "fi
also recommended that images have a square aspect ratio with equal height and w lename-HxW", where "filename" is a unique string representing the file, "H" repr
idth and with a power of two value for the number of pixels (e.g., 32x32, 128x12 esents the height in pixels, and "W" represents the width in pixels.</t>
8, 512x512). The format of the string should be "filename-HxW", where "filename" <t>It is appropriate and useful to include multiple versions of images o
is a unique string representing the file, "H" represents the height in pixels, r sounds so that endpoints that cannot support all formats or resolutions can se
and "W" represents the width in pixels.</t> 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
<t>It is appropriate and useful to include multiple versions of images or sounds e image format has a specific resolution, the HxW portion of the filename should
so that endpoints that cannot support all formats or resolutions can select the correspond to the pixel resolution. The file extension should reference the fil
format they do support. The convention that is RECOMMENDED is that files that e type (e.g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32
refer to the same content should use the same filename portion. If the image fo x32.png, filename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64
rmat has a specific resolution, the HxW portion of the filename should correspon .jpg).</t>
d to the pixel resolution. The file extension should reference the file type (e. <t>Because this is a complex and often debated topic that has evolved ov
g., filename.png, filename.svg, or filename.jpg) or (e.g., filename-32x32.png, f er the many years of advances in image coding and display technologies, this spe
ilename-64x64.png, filename.svg, filename-32x32.jpg, or filename-64x64.jpg).</t> cification suggests relying on either future specifications or industry forum sp
ecifications that might correspond to supporting particular classes of devices t
<t>Because this is a complex and often debated topic that has evolved over the m o further define how URIs can reference appropriate image formats and files.</t>
any years of advances in image coding and display technologies, this specificati <t>For audio files, the recommendation is to provide mp3, m4a or mp4, or
on suggests relying on either future specifications or industry forum specificat wav files <xref target="RFC2361"/>, although the usage of sound (for example, a
ions that might correspond to supporting particular classes of devices to furthe special ring tone for a particular caller) is not well defined in this specific
r define how URIs can reference appropriate image formats and files.</t> ation. Future documents should consider both usage and potential security risks
of playing sounds that are not specifically authorized by a device user.</t>
<t>For audio files, the recommendation is to provide mp3, m4a or mp4, or wav fil </section>
es <xref target="RFC2361"/>, although the usage of sound (for example, a special <section anchor="cardinality">
ring tone for a particular caller) is not well defined in this specification. F <name>Cardinality</name>
uture documents should consider both usage and potential security risks of playi <t>Property cardinalities are indicated, for convenience, using the foll
ng sounds that are not specifically authorized by a device user.</t> 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
</section> tionFormat="comma" target="RFC5234"/>):</t>
<section anchor="cardinality"><name>Cardinality</name> <table>
<thead><tr><th>Cardinality</th><th>Meaning</th></tr></thead>
<t>Property cardinalities are indicated, for convenience, using the following no <tbody>
tation and follow the guidance of jCard <xref target="RFC7095"/> and vCard <xref <tr><td>1</td><td>Exactly one instance per jCard <bcp14>MUST</bcp14> be pres
target="RFC6350"/>, which is based on ABNF (see <xref section="3.6" sectionForm ent.</td></tr>
at="comma" target="RFC5234"/>):</t> <tr><td>*1</td><td>Exactly one instance per jCard <bcp14>MAY</bcp14> be pres
ent.</td></tr>
<figure><artwork><![CDATA[ <tr><td>1*</td><td>One or more instances per jCard <bcp14>MUST</bcp14> be pr
+-------------+--------------------------------------------------+ esent.</td></tr>
| Cardinality | Meaning | <tr><td>*</td><td>One or more instances per jCard <bcp14>MAY</bcp14> be pres
+-------------+--------------------------------------------------+ ent.</td></tr>
| 1 | Exactly one instance per jCard MUST be present. | </tbody>
| *1 | Exactly one instance per jCard MAY be present. | </table>
| 1* | One or more instances per jCard MUST be present. | </section>
| * | One or more instances per jCard MAY be present. | <section anchor="identification-properties">
+-------------+--------------------------------------------------+ <name>Identification Properties</name>
]]></artwork></figure> <t>The following properties, initially defined in <xref target="RFC6350"
/>, hold the identity information of the entity associated with the jCard. This
</section> subset of properties selected for this document are relevant to telephone and me
<section anchor="identification-properties"><name>Identification Properties</nam ssaging applications.</t>
e> <section anchor="fn-property">
<t>The following properties, initially defined in <xref target="RFC6350"/>, hold <name>"fn" Property</name>
the identity information of the entity associated with the jCard. This subset o <t>The "fn" property provides formatted text corresponding to the name
f properties selected for this document are relevant to telephone and messaging of the object the jCard represents. Reference: <xref section="6.2.1" sectionFo
applications.</t> rmat="comma" target="RFC6350"/>.</t>
<dl spacing="compact" newline="false">
<section anchor="fn-property"><name>"fn" Property</name> <dt>Value type:</dt><dd>A single text value.</dd>
<dt>Cardinality:</dt><dd>1*</dd>
<t>The "fn" property provides a formatted text corresponding to the name of the </dl>
object the jCard represents. Reference: <xref section="6.2.1" sectionFormat="co <artwork><![CDATA[
mma" target="RFC6350"/>.</t>
<t>Value type: A single text value.</t>
<t>Cardinality: 1*</t>
<figure><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>
<t>These properties describe how to communicate with the object the jCard repres <section anchor="tel-property">
ents.</t> <name>"tel" Property</name>
<t>The "tel" property provides the telephone number for the object the
<section anchor="tel-property"><name>"tel" Property</name> jCard represents. Reference: <xref section="6.4.1" sectionFormat="comma" target
="RFC6350"/>.</t>
<t>The "tel" property provides the telephone number for the object the jCard rep <t>Relative to the SIP From header field value, this information may p
resents. Reference: <xref section="6.4.1" sectionFormat="comma" target="RFC6350" rovide an alternate telephone number or other related telephone numbers for othe
/>.</t> r uses.</t>
<t>Relative to the SIP From header field value, this information may provide an
alternate telephone number or other related telephone numbers for other uses.</t
>
<t>It is important to note that any of the potential instances of the "tel" prop
erty should not be considered part of the authentication or verification part of
STIR <xref target="RFC8224"/> or required to match the "orig" claim in the PASS
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
patibility with vCard 3), but it SHOULD be reset to a URI value. It is expected
that the URI scheme will be "tel", as specified in <xref target="RFC3966"/>, but
other schemes MAY be used.</t>
<t>Cardinality: *</t>
<figure><artwork><![CDATA[ <t>It is important to note that any of the instances of the "tel" prop
erty should not be considered part of the authentication or verification part of
STIR <xref target="RFC8224"/> or required to match the "orig" claim in the PASS
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 ins
tead of the actual, verified telephone number should be considered from a genera
l 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> <aside><t>Note: The reference for time-zone names is <eref brackets="a
ngle" target="https://www.iana.org/time-zones"/>.</t></aside>
<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 provides the position or job of the object the
<section anchor="title-property"><name>"title" Property</name> jCard represents. Reference <xref section="6.6.1" sectionFormat="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 provides the position or job of the object the
<t>The "role" property has the intent of providing the position or job of the ob jCard represents. Reference <xref section="6.6.2" sectionFormat="comma" target="
ject the jCard represents. Reference <xref section="6.6.2" sectionFormat="comma" 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 specifies a graphic image of a logo associated
<t>The "logo" property has the intent of specifying a graphic image of a logo as with the object the jCard represents. Reference <xref section="6.6.3" sectionFor
sociated with the object the jCard represents. Reference <xref section="6.6.3" s mat="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 specifies the organizational name and units of t
<t>The "org" property has the intent of specifying the organizational name and u he object the jCard represents. Reference <xref section="6.6.4" sectionFormat="c
nits of the object the jCard represents. Reference <xref section="6.6.4" section omma" 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>
<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> There are potential security and privacy implications of providing
URLs with telephone calls.</t>
<t>Cardinality: *</t> <t>
The end client receiving a jCard with a
"url" property <bcp14>MUST</bcp14> only display the URL and not automatically
follow
the URL or provide an automatic preview of the URL. In addition, it <bcp14>M
UST</bcp14> generally
adhere to good practice to make it clear to the user that it is their
choice whether to follow the URL in a browser context consistent with all of
the common browser security and privacy practices available on most
consumer OS environments.
</t>
<figure><artwork><![CDATA[ <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 anchor="sip-call-info-header-field-integrity-parameter"><name>SIP Call-
Info Header Field 'integrity' Parameter</name>
<t>This document defines the 'integrity' generic parameter for use as a new para
meter in the Call-Info header field in the "Header Field Parameters and Paramete
r Values" registry defined by <xref target="RFC3968"/>. The parameter's token is
"integrity", and it takes the value of a quoted string.</t>
<figure><artwork><![CDATA[
+--------------+----------------+-------------------+------------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+------------+
| Call-Info | integrity | No | [this RFC] |
+--------------+----------------+-------------------+------------+
]]></artwork></figure>
</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 n
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
tended primarily for providing verified information at the termination of a call
, where a verification service has a trusted UNI relationship with the user agen
t. To ensure the integrity and authenticity of this data, the security framework
established by STIR, including the use of the 'rcd'PASSporT as defined in <xref
target="I-D.ietf-stir-passport-rcd"/>, should be followed. This framework enabl
es digital signatures to verify the issuer of assertions related to the calling
party's identity, distinguishing persistent identity attributes from transient,
per-call details. Implementers should also consider certificate-based constraint
s to ensure proper binding between caller identity assertions and call-specific
metadata while maintaining the integrity of the information throughout transmiss
ion. Since Call-Info serves as a means to convey verified caller information to
the end user, mechanisms should be in place to validate the authenticity of the
assertion, enforce appropriate certificate associations, and preserve the trustw
orthiness of Rich Call Data from origination to termination.</t>
<t>The SIP framework, defined in <xref target="RFC3261"/> and the various extens
ions to SIP, which stir <xref target="RFC8224"/> and rich call data <xref target
="I-D.ietf-stir-passport-rcd"/> are included, since its existence has provided m
echanisms to assert information about the person or entity behind the call. This
can be a feature that can be a benefit to the SIP network that allows users to
help identify the calling party behind an abstract telephone number. It can also
enable the ability for actors to impersonate a calling party they are not autho
rized to represent. The core security consideration that either explicitly or im
plicitly have been acknowledged with any of the SIP and stir specifications is t
hat there is a management and policy layer that validates the participants in th
e ecosystem and their use of a SIP network with telephone number identifiers and
identity related information. The use of this specification should weigh this r
esponsibility and make the appropriate considerations to validate the proper par
ticipation and use of these tools follow these larger security, impersonation pr
evention, and privacy considerations.</t>
<t>The use of this specification with the insertion of meta data related to a ca </section>
ller or the purpose of the call should recognize the risk that this information <section anchor="sip-call-info-header-field-verified-parameter">
can be viewed by those network elements and participants in the delivery of the <name>SIP Call-Info Header Field 'verified' Parameter</name>
SIP call. The insertion of media directly or via Base64 encoding or using a remo <t>This document defines the 'verified' generic parameter for use in the
te URI that query network resources should be considered as a potential threat v Call-Info header field in the "Header Field Parameters and Parameter Values" re
ector to the user or user agent that could potentially allow the parsing of docu gistry defined by <xref target="RFC3968"/>. The parameter's token is "verified",
ments crafted to trigger a bug or install a virus. Remote access to URI content and it takes the value of a quoted string that can only be "true".</t>
should additionally be considered as potentially exposing information about that <table>
user or user agent. Some sensitive users may desire the ability to control or d <thead><tr><th>Header Field</th><th>Parameter Name</th><th>Predefined Values</
isable these mechanisms entirely and methods to restrict or disable these potent th><th>Reference</th></tr></thead>
ial concerns should be considered to mitigate these concerns. Largely, any infor <tbody><tr><td>Call-Info</td><td>verified</td><td>Yes</td><td>RFC 9796</td></t
mation that is included in rich call data should be considered public and this s r></tbody>
pecification does not define any mechanism to protect this information beyond th </table>
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 </section>
d URL resource references to media resources that could pose a threat when refer <section anchor="sip-call-info-header-field-integrity-parameter">
encing or decoding the content of these media resources similar to threats that <name>SIP Call-Info Header Field 'integrity' Parameter</name>
web browsers and other media decoding applications must be concerned about. A ne <t>This document defines the 'integrity' generic parameter for use as a
twork specific set of policies or best practices for the use and hosting of medi new parameter in the Call-Info header field in the "Header Field Parameters and
a content that is agreed to contain validated media resources that have been eva Parameter Values" registry defined by <xref target="RFC3968"/>. The parameter's
luated to not pose a security threat to the participants or the devices supporte token is "integrity", and it takes the value of a quoted string.</t>
d in the ecosystem should be considered.</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 RCD ('rcd') is intende
d primarily for providing verified information at the termination of a call, whe
re a verification service has a trusted UNI relationship with the user agent. To
ensure the integrity and authenticity of this data, the security framework esta
blished by STIR, including the use of the 'rcd'PASSporT as defined in <xref targ
et="RFC9795"/>, should be followed. This framework enables digital signatures to
verify the issuer of assertions related to the calling party's identity, distin
guishing persistent identity attributes from transient, per-call details. Implem
enters should also consider certificate-based constraints to ensure proper bindi
ng between caller identity assertions and call-specific metadata while maintaini
ng the integrity of the information throughout transmission. Since Call-Info ser
ves as a means to convey verified caller information to the end user, mechanisms
should be in place to validate the authenticity of the assertion, enforce appro
priate certificate associations, and preserve the trustworthiness of RCD from or
igination to termination.</t>
</section> <t>The SIP framework, defined in <xref target="RFC3261"/> and the various extensions to SIP which includes STIR <xref target="RFC8224"/> and RCD <xref tar get="RFC9795"/>, has always provided mechanisms to assert information about the person or entity behind the call. This feature that can be a benefit to the SIP network that allows users to help identify the calling party behind an abstract telephone number. It can also enable the ability for actors to impersonate a cal ling party they are not authorized to represent. The core security consideration that has either explicitly or implicitly been acknowledged with any of the SIP and STIR specifications is that there be a management and policy layer that vali dates the participants in the ecosystem and their use of a SIP network with tele phone number identifiers and identity-related information.
Users should assess this risk and make the appropriate adjustments to validate p
roper participation while following these tools following these larger security,
impersonation prevention, and privacy considerations.</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 RCD should be considered public, and this specifi
cation does not define any mechanism to protect this information beyond the secu
rity and privacy associated with the SIP signalling itself. This is a property t
hat is consistent with SIP more generally, and this specification follows a simi
lar pattern for its use.</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.
Network administrators should consider a network-specific set of policies or bes
t practices for the use and hosting of media content that is agreed to contain v
alidated media resources that have been evaluated to not pose a security threat
to the participants or the devices supported in the ecosystem.</t>
</section>
</middle> </middle>
<back> <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"/>
<references title='References' anchor="sec-combined-references"> <!-- companion: RFC 9795 - draft-ietf-stir-passport-rcd-26 -->
<references title='Normative References' anchor="sec-normative-references">
<reference anchor="RFC2392">
<front>
<title>Content-ID and Message-ID Uniform Resource Locators</title>
<author fullname="E. Levinson" initials="E." surname="Levinson"/>
<date month="August" year="1998"/>
<abstract>
<t>The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow 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">
<front>
<title>PASSporT Extension for Rich Call Data</title>
<author fullname="Chris Wendt" initials="C." surname="Wendt">
<organization>Somos Inc.</organization>
</author>
<author fullname="Jon Peterson" initials="J." surname="Peterson">
<organization>Neustar Inc.</organization>
</author>
<date day="5" month="June" year="2023"/>
<abstract>
<t> This document extends PASSporT, a token for conveying
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>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-stir-passport-rcd-26"/>
</reference>
<reference anchor="W3C-SRI" target="https://www.w3.org/TR/SRI/"> <reference anchor="RFC9795" target="https://www.rfc-editor.org/info/rfc9
<front> 795">
<title>Subresource Integrity</title> <front>
<author > <title>Personal Assertion Token (PASSporT) Extension for Rich Call D
<organization>W3C</organization> ata</title>
</author> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<date year="2016" month="July" day="23"/> <organization>Somos Inc.</organization>
</front> </author>
</reference> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<reference anchor="W3C-SVGTiny1.2" target="https://www.w3.org/TR/SVGMobile/"> <organization>Neustar Inc.</organization>
<front> </author>
<title>Scalable Vector Graphics (SVG) Tiny 1.2</title> <date month="June" year='2025'/>
<author > </front>
<organization>W3C</organization> <seriesInfo name="RFC" value="9795"/>
</author> <seriesInfo name="DOI" value="10.17487/RFC9795"/>
<date year="2008" month="December" day="22"/> </reference>
</front>
</reference>
<reference anchor="ITUJPEG" >
<front>
<title>Information technology - Digital compression and coding of continuous
-tone still images, JPEG File Interchange Format (JFIF) ITU-T Recommendation T.8
71, ISO/IEC 10918-5</title>
<author >
<organization>ITU-T</organization>
</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"> <reference anchor="W3C-SRI" target="https://www.w3.org/TR/2016/REC-SRI-2
<front> 0160623/">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <front>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <title>Subresource Integrity</title>
<date month="March" year="1997"/> <author fullname="Devdatta Akhawe" role="editor" />
<abstract> <author fullname="Frederik Braun" role="editor" />
<t>In many standards track documents several words are used to signify the <author fullname="Francois Marier" role="editor" />
requirements in the specification. These words are often capitalized. This docu <author fullname="Joel Weinberger" role="editor" />
ment defines these words as they should be interpreted in IETF documents. This d <date year="2016" month="June" day="23"/>
ocument specifies an Internet Best Current Practices for the Internet Community, </front>
and requests discussion and suggestions for improvements.</t> <refcontent>W3C Recommendation</refcontent>
</abstract> </reference>
</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="W3C-SVGTiny1.2" target="https://www.w3.org/TR/2008/RE
C-SVGTiny12-20081222/">
<front>
<title>Scalable Vector Graphics (SVG) Tiny 1.2 Specification</title>
<author fullname="Ola Anderssone" role="editor" />
<author fullname="Robin Berjon" role="editor" />
<author fullname="Erik Dahlström" role="editor" />
<author fullname="Andrew Emmons" role="editor" />
<author fullname="Jon Ferraiolo" role="editor" />
<author fullname="Anthony Grasso" role="editor" />
<author fullname="Vincent Hardy" role="editor" />
<author fullname="Scott Hayman" role="editor" />
<author fullname="Dean Jackson" role="editor" />
<author fullname="Chris Lilley" role="editor" />
<author fullname="Cameron McCormack" role="editor" />
<author fullname="Andreas Neumann" role="editor" />
<author fullname="Craig Northway" role="editor" />
<author fullname="Antoine Quint" role="editor" />
<author fullname="Nandini Ramani" role="editor" />
<author fullname="Doug Schepers" role="editor" />
<author fullname="Andrew Shellshear" role="editor" />
<date year="2008" month="December" day="22"/>
</front>
<refcontent>W3C Recommendation</refcontent>
</reference>
<references title='Informative References' anchor="sec-informative-reference <reference anchor="ITUJPEG" target="https://www.itu.int/rec/T-REC-T.871-
s"> 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>
<reference anchor="RFC2361"> <reference anchor="ISOPNG" target="https://www.iso.org/standard/29581.ht
<front> ml">
<title>WAVE and AVI Codec Registries</title> <front>
<author fullname="E. Fleischman" initials="E." surname="Fleischman"/> <title>Information technology -- Computer graphics and image process
<date month="June" year="1998"/> ing -- Portable Network Graphics (PNG), Functional specification</title>
<abstract> <author>
<t>The purpose of this paper is to establish a mechanism by which codecs r <organization>ISO/IEC</organization>
egistered within Microsoft's WAVE and AVI Registries may be referenced within th </author>
e IANA Namespace by Internet applications. This memo provides information for th <date year="2004" month="March"/>
e Internet community. It does not specify an Internet standard of any kind.</t> </front>
</abstract> <seriesInfo name="ISO/IEC" value="15948:2004"/>
</front> </reference>
<seriesInfo name="RFC" value="2361"/>
<seriesInfo name="DOI" value="10.17487/RFC2361"/>
</reference>
<reference anchor="RFC3325">
<front>
<title>Private Extensions to the Session Initiation Protocol (SIP) for Asser
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>
<?line 852?> <t>We would like to thank <contact fullname="David Hancock"/>, <contact fu
llname="Alec Fenichel"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname=
<section numbered="false" anchor="Acknowledgements"><name>Acknowledgements</name "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>
<t>We would like to thank David Hancock, Alec Fenichel, Paul Kyzivat, Yi Jing an </section>
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>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1923IbV5LgO7/iLPwgsRuACN5EUa2OpihKplqiaJGyx+tx
TBSAAlESUAVXFQhCGm30Z+xG7P5cf8nm9VyqCiAla2K6d8cRtkGg6lwy8+Q9
83Q6nY0yKSfxobk4PTfH0WTSOU1HmTmP8mgal3FemFGWm7fJYEy/mmdRGW1E
/X4eXx96z1ceGGaDFN4/NMM8GpWdJC5HnSKZDbI87gzgqQTe6eSDYaf3aKOY
96dJUSRZWi5n8MrpyeXzjUFUxldZvjw0RTnc2Ehm+aEp83lRbm9tPdra3ojy
ODo0UV5ufIiXiywfwoM8vvsCduT+OB3GKex0ubFRlFE6/LdokqUw2TIuNmbJ
ofmlzAZtU2R5mcejAj4tp/jh142NaF6Os/xwo7NhTJIWsOmu+SlOhyX8zXs8
HudJYb/L8iuYOptmBfwRT6NkcmgG+MRfotlsksTDflIW3UE2hZ8H2TwtcZPv
Ltz4L7vmnCCfpXaKl1nqf0lzXOZRWrxLE/pGJoLnuvrcX0p8YI4PNEy3kWb5
NCqT6/gQfnn7/Hh759G2fNzZ3u/px0f7++7jgXzc3d/Vj3vbO7vycX9nb0s+
Ptx6tKcf93qP9OPBnk7x8NHWjnw82N7edR/37Mc9eu2086zL5FMmeWcWFcUM
kIS0g7/+tHPcuXh7ih+NUUKeA3EW2TwfxOY0BTLKEe30QJRfxeWhaY3LclYc
PniwWCy6i50ugPPB5dsHMNCDFj0oODf0B4E7SpOPAK0sPcQ56fshkOih2d7q
7Xe2Hna2d3Q5P764TNJlr7sdrgrIPupPYvNjPCjhRL3Io9k4GRTmPrywafAV
A++YOy30xxevs34yib9muVsHnd52Z3sbYXv57uX5yYtgnS08zkQZQHJlPBin
2SS7WpqOeZZcJWU0ASqazgDAeGANnCT4e5ikVyYbwSc4Yuk8mxedEk4XHN0E
GEIyja5iOFI4lXkOqyas5INxlF7F5jlNZu6/fH76fBNX1Lk0b2OYYwrniVdx
2T142Gub04s3D05Pjk1v61HvoLPXMrfvnYYLkbXT2drDrV+8OT97Ia/dtvWO
OYY9z2HR5krRhjunnZlZng0QHAADePIcqJPwfBaXwHk+eIiGCTfb5vk8HeAM
AMliFg+SUTKgGb0N7j2C4wWY2r0DeuWlEMW7na0dYJq6He+Mu4O9Y4/aw51d
OLcbHVh91C+AawzKjY3LMfA0YONzwEOpK41h32Ze4K4B3eU4rkiNcRwNAUjw
4GQIPwNekxR4MpxYWFlRERLm/tvjZ5sGTnQ2SOD3oVkk5ZhGTYRZ6yxZDrSX
wk4AxjNg+ksYF77EucoMEXANb+BHfBjQNA0fjswwLgZ5MiPMypgohuD9+7DC
yZwoeBiXwERhi/1sXtIzIGSAkZIExD8LpvrNroGVG34RtpV4ZOPelfH78TJL
h7KwSTwb48FI59M+/FbMAR4RwpRl4hVx+zb8DXSXtQ08XML/YPb3x1E+NFn/
PTAPWBWeP4QQvOGmapvFGAE8iFJAxGTmfhoKHIaARIDTOFsgrOD8DYFOvY3B
yL/N46LsVtE/jEdJCjstx3kMq48XOKDqB/dwjg6D6l7b3LuOcySVIXzGQ3Iv
UR58zwJyDdXgK9GkyAAIOE+ZfYhTc7/1fgAAaG3aEe7N5kBWRXzPrUQR2zxw
15yWPLCQS2Gu5skwSkFK4HGHF+dFXB+jaSJaVNu0EmB4rS6fnGkyBGhubHyH
3C3PhnM65BsbF8kVHHWixRywOcgmSDA+LTCfKAAf1zEgHp4s5jMUcjGTzTCe
wAnO6TBEDG0lFYBonk1rR6RYcRrw+zZ8m82vxriIGR71ZEDf1Z80QAHZqATw
T+JRieMBMGEliBmY200tK+owkQlt95coDor5hMZDiobHTDQcougw/Sz7gHQN
pBrfwMTIDYF7Rf2oiLtEHp8+iSLy+TOsZppMonyyJNoGSsjxTN8bJsVsEi07
DImEkfgcVxVQ1HU0mcfNgEIYrYRPiQCIAmZWmDQrUQBOsxRWQwppzDRrgQWn
cxIN4FvYHuAeNFKgvUs8ZAg03EA/JtDAZDmiOJ8T2flcRPay4ojArwChlYf0
rvzZhzA8kS0QBB6/QG4PAMrjQcxYn8JeRPqPY1g/fgk7RwTCXyjzirjEiRv5
PJ5clAZTnaagI2ll4GSytFvQL8O9NO+jLZzCHc/7AUfaZJbyrbnJc3rVhz9O
M4xnoLaQOsQonGWTZICQVKkDtAMqOYt82OgSCGja9iQAHyLQ1AFDQCgxiMSY
FwkDI4vKYZJrOLTmfty96uKriGP6AWAF67j/7mhzkw6X8hbAS06vgKzB8ZmT
OBakPwtnzOEE6onTpVkZYleGR7eyIoGmzrp6AoN8h4HUj8fRZKTgAWJLZgnu
wpPSQOmnobifxcgMkKGiPGQlVOEKs2VTSzOoO6GkHER6UPXQ8jCl4OYeGBT3
zGASJdNCyJAO2qdPqw2Qz5/bFRKwcnKRIatLRM8LBaYvIqsSkjgFiCFPvJIo
162y3uFpqciWxhEiBAgbdQJznURCExYPoEMgpcc30XQ2iZVkVMViQo2H7qDJ
i6DEd3QMXGI+ipDszs5ON3li1PcjsFlhQN4Rk7VPbgEoxdhDfgPbHs1zom19
xB56wHF1n7digllssArSy4fznDQ0UtVY15kPUF0fzSfh47L3FgzXUkIgylKO
ncNIs4xONxCfVcJ4c2vYNSKkJKyGdNA1GxvvChQUsL8SqHCRCj0FdgEqyEBd
BYO8ptO9O6IVElVbju8wj2+DFGqrFsE6mZITcyTYWANpoV5KRxzJAE96EQ/m
SKTM05Zd8322iHnIAsUfCTIAxTRKl0wvQB8pDB0Pa2yPCaSQ/XqT8D5gRyho
AexXc4AXjCVCNI9hgaKv5Gol4sGewZYikDqJBychcCBQPOeiK69AUjEmvkYK
IgLMV+F9qCAyLy5P33aUalWrA1ijakdEjgYVEDmeOavKeIQfiDxQqUnd8BRQ
xISwUqbG86OLCyD1y7szJmCZRxPSq9D6QzbeQFhC2XOw0pOPPCpg7L3Yp84a
c4rrnef3JU2T2HNKcVSO2yFE5DQpn353dqryxTEhwXBNZfUFXBoy/7bP1njA
tp3ELWiBREYWI005jZak85FyTgKlD9ACqoKjRexj2YCntumDEZgQHVv9CR+r
njGrlK4yhgKQ11GoOmCIV2vgIAj0YKiq41sTbFWi3s2HRiihYD6J6uo0RjdN
UkxxKUzbB3vbgF82NXVxoBvGUUqClLRzUvmd/KMZ2DLmI1XY5YjiRa/G0zgH
DWawtPwBdBzaGtHFp08XMVPmbnfX3H+zSOP8wcW8j5Y9Whye92aTjpEudhNZ
R5OYjhoVP7YX7pGO6ExWUn5hdYDzQQDEKndgoDKsth7tsWjyZ+8Dw80WBSPf
hymznJlHYWrqEAALINZBOc9jdhn0syEd6xr7IHoEQ79l3r09NcVgDHDledDF
S7zhO3NJJ4f9W5++K91fn5GkYvMhXhp0nBem9frdxWWrzf83Z2/o89uTH96d
vj15hp8vvj969cp+0Ccuvn/z7tUz98m9efzm9euTs2f8MnxrKl+9Pvq5xWKq
9eb88vTN2dGrliV/p23nZOL2hSuAMCYFrxBXT5+PzNPjc9Pbhd3/N9x+r/cI
wMx/HPQe7hIdoyWPk5FFx38CBJd4cuIImT8aR4gXdH4WJOxAWCzQx5LHBMs3
10iu8aJqkLlzCLgG4iKRrPQkyFrlO1PcM8eoWsSs7ax4935V58J32kYPz/ZW
F6Cwuf4QgGmW2hPsfGx4rn2vie+LsN4EVpsqBBnfJAWx6Vv9KVWdOr6ZwXgF
TpexLbScMb9A2PTFaGQnAypYbgIdlq29tiyr7sFqf40LazXiQI5cifTEFVZ5
eEz6g0cRVfWA3gwFyhdI3i6f35VgVnCgpjRH7ZN1RHbB0oLzeELGkjiQqr7Y
0FCVLSELZKuygf39NE7Yz5jH7FJp8Qp4PU3UagWMtTZ9h0nG0hikWwaImsBB
pfXwhlk31E3yFElBTII0RXJjgURngcyrBeIe4RKrstbSICIdiXm9ok+B0uNn
fDgH44xMYpWyjfIbV4bnCeYEQiarEX8vwTbgt6yVUairTDwtgNFxNsTh3cms
+6EjM6NQIKqT/XmB572oOdzZwCfSGwOxkiX5BYqe/1o0zGYlb8bqrEreQArw
0CDymIL17ry8eHNmfor75hLxBWL/5U+Xm0JEe8i0harx3K4AviPz4DAj4VzH
y8LT5+8JNZQIFc/Dr4SN9NXoPp8DAeUUPRadFka5YfeDDuiOCB/l8ZKFCaqR
C7Bj6LSlxUJcOuLduPvWnOPAV/ISMEo1iGS1dlZjWmiVIU/NHC2J9YS+WeuX
WmU5k164wJMLlITkJaRKQQOEx21+srvvzWOynuR0GmjAqGjX8jzS3xjVI8Be
u8JvVeoddLdxpbe7c9jN2xSUInw7JNsYM9ikAJ904CCDeted/QOkQhx5Pz4P
dIVj1acrGRZNij/xh2Fxi3zqsxMXXkFGIs6z2SRGThflS+X7KAqckLq7/DGX
yxlbcuJo6qBTf2hjTEl6nU2uAbdTjA3AvGaczQqryA6TEYGzDLzrmLfAf2m4
hCmrSZSK9S2hBrFmxOMRxP/yPBH+Qwc2YJ94plnwkYMQjkfDGjTitoiK9F5p
Z7QIx3QUUt0CNMHSV6plXqRtnVFIBok9GMy8hEyI+YnjCrldR8V5dXthLMw7
8jic1alCjaqiSxQ1wyopBnMLc+H0VvXjd8RPrspng8pG2q91tzXSIzNNNIXI
WJeYk+iEgYOUlEX2VrK7g7Jipkl5u+OO9BlEn4ZFHcnhNOHZu0VM6oabAr0U
KRqwp6/OdSS2y0EMIlSRWczwXFzTAT9UFRbRMjDMG7xac8peqKtuLJqaOUEf
tPEGs6wAaYHSr7iD7kBHUIDSse5fb2EMcXHg8dElBIf6HCAV1z+fsLlm/X/s
eXG6qvj4xLOISE1En5xGH5ATLisrwXh5QQ4rZmEUIR+CGgCSvG2G89mEXEsU
oQf8jeBPInSrBNbc2IUGdCrrB9bB4iOStVpBRLkfYHqiH4/5kORVuFGz3OrE
pIURhfOhJx+Deufhb0u8Vj1j7jrNhvxAlpKfDcNDwuyG2TRKABNHAB7Pp6MR
QmHnjuchhaJXz6i/wNDgy7UnLceh/eGbHyx848RCOaAPZRXr/byhReE2GzEz
tujW7z1wt6156+PAbjYcmeFK+UC1rI0+sBRrNOPShzH7YfQBOGfRxL0XhdKL
DjHuVPgjBuK6xjSoBdHgQ5otJhjhUYUuwSB36XNpPJ+IB7axrXAp2rQsKznx
kPCm1JcrQXHg38RuMIkSxp176RUVl0eTGeQTHDp8fd+xDUHBXFPkHnD60L9d
WI53x0hdHPor5iqn/DwCUZtl6noygW+iWkVQpEPF447bplAkBbsbFoBGwSDz
MynOO0cF0nI87Jw+a5p4ZzuwqBMCP2ISMTjIZrHojKvyBpDACrfwJsqqQ6MW
5cxiC/s1A9WjazAIg5flDUXePYvGOp82NjC6jqKxUNnoyfDQjgncEQzkqjrB
fqUAdZ7zQ4wnVCNQbx9xVgqn9lkd31cgBEDOQ0IhcCdsNAhn6eJ56Ou2sAgy
BzjkQaoJ68ks68SdwTuobswxM9qMs3y6gd1jlbxxcjXuTGIgz8CLx3tlXsbZ
OunQNKiNKzNOQos7UrXOaYvrnWaiRbrHVS+IRMexBq5At5KWJ1a0+FkonW5d
kopTnG3kqxKtslLS6Zty5IKsJC8nUjxaNd8jiwk1GyueSnVSVdGaUN4Nckt8
nXwjvDfGhK+hMem4FMhGnovPpFnaEf7LYwGq86Q/LznJR53mzR6+qB6/lfRf
0fa8FRDHs6FiFYXyXgQ2XmozQ0M1D7ebzSi1ltKMrkmAilaRoqOlYJouyGJW
4DVl6pEXiXXXpp8rflA5/4Wm3amWeVtiajVnhwCFB59UoJUmHussgkoaZgW7
xliExylrLs0ITTXM2yq61b2GbN85RIjdcSoEczvCxCxL0MGI/pUKx6PDxPRC
ZCgJqJXgFh6pISY5LGeO8Oh58o+RatTn5DDkDTNWmwEiD94XGmemVAOXSf7u
8nnnQF2He49sEO310c+kYRGDAN00wdQFFzNeAQHcqQdIjKb5wTGQ3Hoo0I6q
zCFDY7jNT6oT7g5PRjmPDMtbnwGyPipXVR9u2Q9BlU43iw2iXCumQMwmmA1u
GRA7ymT9guKqIwsTysz3l5fnF6ZMJDLgsnJ0SLUINsHyHLUVPJ7NNJtkS47c
pNdJnqVT4X4AtXYwfV5fWdVgcokgoh3SCLV03TrD/gIPdpNJACfqqfiqfS5a
leA1Z77HCCMySifoegp1o5yTtCcSFw9NC+c7xpSgIOlIx4N9WqfOCgIh4qCA
pqRoudU0Z5KL8QnP5Tm6qonfLTITs1tQvG38oxvc8RIZfJTkcCTkJcc1RYq3
roNAHIkJdPDo80nhVmDllJemF0JDlC+ZWdiyvzvhimI4ThIw8VsjjC+2KK++
RWZ7C7VMEAIjVqHskoW4RPHyogOkFgNAyTSA79eo7PCrEoyoA9XwNHsm4+sk
mxcq3toMYKAITGcaGavsZpylW49LoLtsElN+tJqQ7uCTkyFYvGjUaEKlmhO4
VhAlxeHGxv/w/tmwDx6aP2mJkoyEpWYPfusDSxqMu8jf//xYgPCEBFg4UGUJ
npu94CW9e/uqA0v/AJvw5BBF6xINxDtBWF3nL0pyG8b8QiUy8E2co+7San/6
3G6hgGq1W7vdrdavbXlgFP72g3lKm3EPZPlV8MTr0/3H+pS5mC3NiwhM7bJw
bwjB4TugF8ErTUCjh4oHv3W29/Zv4N/uLL1yQxCd3jICWUwPpsm+HeL97KuH
2N+92d/lAeD9Xzd+XY05lIenZz+eXp6sE7OhzlJFFaxQhiiS2SHImkH8F29h
OMeD7e4WPvdjEh3q3w8uX12Y2WBnpxuVkwh4Xdd76TGT4ZOPj8Yvdvt/TaNi
PCwOcIhLoNwjnMP8qXG6P+NDeMQPzdOszw/1tnt78E9va2vLf/Qxmn9PKM/5
z4/L6OpJ79H2wc5W7+HDXRqFz8qzQxMd7PZ3Bw/34/39h70t9xMfI4TWYVU3
alsC/qWRcAmxQr3rCHc9zdIoId1+IcnOsRAXRwHmE4GYzis0fGfao0EaafhL
yJdGqdDwr7/+a4UTPfas1iett8gpP14jIwZ5TCO8SsqSCvmAecZUind8Ef92
aHZ6u729R0Ku+PXr6KYDRv4CBi0OzUPC7TOqxXueJ22zvQcmwAzUf/jQewR0
dAgfXrymwsRjlM+D8rBOYlcwwCJadqtUecz8sXNJxdI+xRTD2QYVCV4/oSVk
T94BaR6Z7YNHWwe7u3vb+/7H0zNzer678uzgAMWTCzH0Lp6d4xeDJ3d4q3yy
ZWj+6ZNoPkwys/uo93DbvL08f3D04zn/FD3Jy9k0mh1umfPj1+8eHMCOv5S/
VJXp/2Iva9gLAGvVDNVjQbS/5mz8U5wLDi4DWwJWchMPH4P9hnGbfPlEP/T8
l17F6VU5PjTdLqhF8H2n4x67/dD9E5+5L9vse24/YJ9AuvvTKrKisW4RYHeQ
XV+udDUILxrkNgl2i/CiMb5OAfOEF4vsL1TAfq0qX99VfK4NjTvEWeu8qg1R
0xh/Ldm2HVKUHoxCVylJoSDksJQEGfrPxCGPMQzKHeBi1aB0Sf3FoS94bb4Q
LlJsm2CDbH+Ge165M075Qqt0TE4RIJh5NDFTOFfo6C7mCVfoU6IDO/M5L4sK
UbigbZ5rqBysLi4f6ZojdIdRDnjEHvQYTBMNj+jwku4M4E0zKuflkG1q9nfN
YBxhvA9g81hnFjiq77HBrYAg7tNqBxJzyOcpRSxkShcbQV/JKCnBOmffzSCP
41RcZ7q+NQlxEoobMO8NqstjyjNgCz2buRgwY8A36TUpLEid0MXZch7xL5aF
xcACe0UgUdriZ8mm8os8YHTyVorbEQalWLrk4RDwJDiAYIxLHUNzHihYxuXR
uFiKmDU6cygBWlDddjFSpAoFt3qN0H1D1iqclMKFUGcZgRTbPDS+Rv4G8YF5
6etY4Q389gNS6D2NRyccb8vmOWBwyJZ75NyFrspjQaN7qQAujmADmxdzdv6s
jGu6I7Qq2OJKv/qel6xxYMwNLXApE9YaANJllmOCmGbUIpkkNgFNAgXiAAtP
gvpOCvrNAVgGGiUIEkoCTDBaEE+pPms+FPcJuwQl+NJQsBJk17icyrs7ShjE
1ofU8thVK4iGNaioVYWtSTa872fpsMmp0qCzYdBxCQRj4igvyF3XCqbDklrG
ZxHblBlO0CbfXlThtlneGKvlIv6lGc2pMsWrW7Xioe8SqzkSBfCPOVs6sg4y
NyCBL8388AtHKrBthjpN4Zs2exgOXSa7JMbBb8we6mPbUoBVmd7tIC3+OkuG
nBYkyT2FZvrMC1shZ9PbmmhYnXu2tn1YX1XRNSRZLI2tJwza9DfA/3c+Plfo
D83xeZtnGuaOFr77TjiI4+K3e61rYWAXmRNfr6sOtzleQbCAfd235vXZdHWb
FgVrXJUATcmVtbJwG16/PalYaJG8uAPhH80nKV3NWRrTlvyC6SosmF0DkFZl
XAFBYADHnfqVc9fc7v48a8sTeQWYLoLpsS4U0bT9dgXDWpBLxc/1nLdFxGlH
Ul3JrMXiszFSsArDX4lWzUAl0EkUgmJkIgaawsfNeB+Ze5ilL0qulB/SN3c6
An7CIAdkhuuo3+XxR7fVwvsA90JFFUV4BiJ3kIhsXJl65AW5gn0UfkWtq2Jv
hFTiJWJyvgxnjBFfQZ47Tma4iMWYLZglpRKszszZ2DgRqc5VvwJNrQOVFTzh
GgpfMvgpSFFZbX9gactxGgd0pAWX7iax1CAPibaPEZp7GP1wYzhkTZZ2cYfm
K7UIsG2dEMHZWIZUNl1TGfyawEoQ1mlMpCuvJq1KkLfN+VaS2Re2fFlFBqqN
hnPa89/yk9ha4WSYoFIm2FCBCjdyLYGrBcmOz45ed62exEob2SCujQYpjAuK
6lFBcMyxftjP2dkpx8+DbmTa/sQyBDdqLTO3W/dgnnMRA8zyPR0u/O4Td4Vr
RZOr1mHr5GJ7b19cFaZVLmfwnfIt+/VsVsLXWGCo39zszeEbJZYB2LvWwYQt
B3WE7iyekivlM60mWk6yaOgvAhR0GPpTq0xbh7+0eujZI8dQr/XrZ50LWGLr
sLe7u7O9dbCzu6dfY1smfdV7c6tlX8QFwwOAHnjiZYQYfAqU3Gq3kkHqLb+R
1lufed2hG+WyYl5aBIlYKcSKFdexZqrYLCDhcSLZLIupJVlj4qPSpha6NPdM
UW1B1kHJDlg4JllaRGXWDnNeC9chIWCMVDQQdMDB5FpJqK1MRemw3KXLNi2i
OcOIsi/6C82f92LU+JRbkCY7Vc6OD9TQIK7VqVUzQiQAsMhWpYiDNu2nblSZ
D5Ut0FYG2r8yKGKOMJ+43agNabMo5s0o9ylrX4ooq+KiwTlSq/mWVwO7RuUM
Zwv4Gc51m1JSBrDa8zpe1eVAtPJrcfBwAjjS1erMs4ZlWXOrTc0xRtF8Uvr5
MJqeRiQ3HLJBXROhTp1R7SVIN660/PGaX1G6BYz9YH3KRV21R36MNLRC+/N0
AI8mXZIGQXZ9MEmSHf6Dw0mtH8QjzhGRhkm9oJLPHu8eXZLWsxxi+pLg0u/W
Mu5i4ja98w8Xdvp/KDJUCzh49bmr3QV+Ee+d/AUuBbBiyrP3IOgMJK4E7NWW
SLM25Ytf416o1wC0xSv1RQW8atCsKAcGPofDjbmflmcVVuqXpdSCDZwB1mHN
MGwxoQ5tnz5Jp2v0J6iVun+7leq5TDnXLPBrkGQAWRKWf1yhv56tUNcbF3+i
ZYKeifVo46kCjQB2r3NPo0nkEBy6F9Qattn8rBNQHhf58tEEZsexOnBynwE7
txL/pJYBEwFOEdsipDRGmwOLmEFLAFzE6BP3ViFOBcmM9CtMrQlP3sPjqv/A
5tU3OAvugIZ2zTnYnEFKmX8uFFQFeWEuvj/C0GKbPuwc7LJugX/s9bap+gtD
cNW30ApmnVW9Xa1iHJGlQJ9gIO24A3/BSPBXTp2XOBkZfR2uqJvW7ZMs+WiU
SDRcGJwJxrMtmMFnhhn5hLgJeB800jj2uqPUShTD44cD2NIkn4cwmm2hjmSH
+95h7sIa5tVqkYlTDgMWo/M3Mzd5m2YGQJ1lKGh4VXB4iqraubr3oyhlaYW/
Fc6rYwsPK/aH65xsH200PQIPQiLwmF/hgUenyrzEajSgomOPJ6xUEq0npsEg
8nrmai1PpSesuFStg5BrCIGSVvdw5Gfceu8n3bjbroMaIdiIKa16jFwLUQuv
JkfDpvGUwypVNuiE//Dm+SAHO9msT+fROdmUN2yQGzTmVReqGfNmlTWvb6+x
53Vt8DcZ9qbVmNTRtk+RrW/unkDLL/qTJsGsD2RAZoidt9n7q58W7/Zv3pWn
u78dbP/xw/fny++nvZd/7U8f/nF/f6f/+vrjcjr+MNnVoZscC0o2IaOpuhLc
yQrt6pw82pSHUevK+Q9jj6wxMXqrTAzPQmlEsw5kqSUYiODdlA73e22VJsJx
5gdNS7ZLxQR5bLnMk1vIh4ZYSUO3mj7rkvEaMlUbTaX/Mq/+sc2rd+T2Ju9J
ak5csoHjEdJejA2tBk3eOs4pDyVM2ao2blFNmD1zVduguSUb6+0a9ZlGKUxn
y5fJjYjQkwK+irjXquo0KRP/Zg4S/dKJg7qhUKWYlJqJPA+jUFdAdqxrRq55
fH1gTgiqFsdXK68rvkJuAr46M40bTdTrhcNGI/otleUlrs+rhATenZ2q0uL2
Nctmc623pipMiWpSV4a//+1/wsL+/rf/5bQ6rc60ql3iR+QidPcms0janKPO
x1QijUGqzeKSVBTztQCg+JyrNIzrhWyq3tNGkT9Yb7DXJV7Lsmo+YVumbnXl
1aZARYHnawdW9QzBKqGgI5HtPNVwQIpKTwApDOVzaX3GckPJioTEw2+mNzYq
jqs0xwbV8ZvpjqI8NqWV2KnuEP1ZFf65Q/xHA0CquaHHebIi7OPXnznd0dwp
UCRPB9MGKiPojDSz1RlX6IdNukDLG+T3Kp7rNc8Vh+Ercotu0Sa+LFFNB6Mt
PMEBG7SoOwKUxrBQ/V0O6dtSpxwQKkvmdO6vwWGANasAuP4MwGXOufZ12blQ
OUcPYW2yvVSKe0r4HjwrFP0bLnJ2uFFxbb29IfnJ5PHmXvGuYdsoXph8PokL
tkVooXLJld+YghMj8riWpRR0oQi71eBQ0tEIdJR5HjSNxcZI0/nUcP8SyjDQ
RGFvo/Aqi/6Y+nOHbrcVXjdNNRpSR2d2E9vLvdQbN/JTddXZ5TcLKmJ/HSqo
vOSWnFOjQcBTjwzK2Z3l1M2S2ud60TDXBlyuJ+Erh7wbVViWFn6/NU85LtpO
StmdiJrFrvcAK5Igj6/o/XYdWsHEroiabnhESjombIXQuLHxE7qucF0AJeqU
zjpoLlFdUmro0bbcq+TyPWAB0o4XCSZd4qsdz4mOPMlraxrfoGPcI/cym0lP
G6sAk2RglzOljjLhSX+YsognI9evy2al8czOfV9QCjjnclMn9LY3Ct2xhlnW
4SsNzZ75+UpDLiKOIO20r7fGSfpkNYqAUVaCqV249ECmVRc2xswXZNieG3Eq
ZQOaBz9JYgtzp/3L6P5OAJGcX5cOteecrs1ve5SMLOQQ2xq51zZ8lszwAanj
lmHCHF09mdxDAR/J8U6NsddLBndItBXenxE03PZA2HFeYdfx50vamCrrQTD4
GjXXztgcZr0JIZ5JsYwHxIXmNthmg3gNzzUlc1WrHNjBruwR9kxNUKtNEBpS
723fI9fjSFg4smkthCAGhL5qrPCRm3fkBclk1oZwPFnYuof4rY8IB9zwHiXS
3R1H5yPpMSlN6aCwBerGePOG2IzEANGSuCWm5TVMr3Cl16jYczOaZ2ySaEcI
ybk6RQX+03dT+1wHJ/zMDccq+Wwr2ohluVcLgTkzLneQ57IdHr2bL7U0xDLj
oVymypej8rUwWIRXuKgFZi48hRn2d11rnPv2CgwOOsldvJ8/b1abtNVvOdQ7
UxK+HWsB2LOGtERMtH83EMsoGqD80YREL51vGMtiuE0Y8geHQKzEcFtiVLCh
CTwKTpKdMfgJiRQbdMCuKT1vHOTTo1FGx405A1Gl4gDMY8tjPAEoLeT06lm9
aFMRJwWCHPLiDiCOjNuqV1GKi98crfCKu87PXiCd0jWy2Asw5/tt4Su+VBeD
fkzvRUz9KrSvldwdqKFn1S+2dzt9EI1vXzyVVXeNueDfCLoTYsM1+U+wpAF1
IBhlGs3M/aevzzcVF6yYPdrawcb6nNwDjB8GxClzCsHJbXK9fVxG2xzw/2Bb
Pfy0SR+vUHkEJhW7H0x/Eg0+SLPzpMQNTlxZHYK+KXPdVpApO5RUbnufk/C2
9gqi1Ss6cgwdypWCcLRQgZfbufAnDRC50KVCTY4oiVBeMNV1wIdOtMBXRQ3C
u2say/QQ+4pypQ2mLV4VaCkYkMLgqVWvdKTNbpBJ2zbXfCO0nps8DvfCvqFc
a7lGtiOiV3vl0I/4IcVNhlPODnuVWDaW6DkXCMZoJ3PpS40S+eJH3RLlLFxx
RcWCervJHJGLXysXiaTt3pRrD/BtXGiwta45Kp0iz8cMZ7N3X1c7KofXaQPt
uuPn5KfkVXi3DcnJ9ZYheO86Pu+zbjni9oyGuhdrsgX3nNGIdlHriWntI1vj
qZFhIhy3ckztAK6aki6RpV7KJEVbaRruDo06YZ/1OcoVxl+syJZe9XxxFctV
4IZX41LuEBnCKdfEbNpfLTfTiTFKDky0PKXahtY3VBy1sEIBO4TzG6gPyqnt
j5SoOg7AbItJ0UDxzz37NZlyWcE1BdZmx3IxhiF1RIzW3/BU1TZtr1CJ4OQs
JGFkkek1sHpHpe0YPktu4kmh/G9n+2ZnG9jg9sEN/Ns2e73tG/h3s9q1j2Qi
49dxuBZuDnHX+f7mp1ZbyMt+22JDdp4mv83t27W2wPh027S+b/mXf3joxXt7
acmSsfFT7UGGg30O2Q1D20NkxE5ZlOdeU0DLFaRUn865oIO62ZKGQg1+o9IW
44b1x5ZJANo91ujxGdI2wArTGwgFqsTGhlYicjZLLXMV9uHdF2Xv++PTSx/p
+Nr2YJzuwYaLYErd/fSbIseQpMXCX6mKCiQ/p285VcPthtkY4FsHUOqwA8us
9Y72hB5vKKGx4Jjr25YnOVZA7RaFbHUy9G95fxXXVySq7RfvZ1d0NWzltQ6R
ffiy9B9oGLDyFowZTOIaF2wGbfTYuoskA/CGL92iK5OHcV8sqxl6JMYC71g6
i2ea8043Sy7ZKwe8cngdkZWVaAtbTy+1df1g+tHFZonl2RXnD+eTUGfxpdxJ
K+qB1LSGlzewFj+cw/FdInHMp9UHWL2lsxrivHDqHHVPH5BYH0yiQi7As0pd
Vrkcla5sJ0HEDZCVFvwTHSqqdMEqsVqWeRycpG8qt2c29S6cznbaZrobkTtn
tkvoXUTXcsqkayXGBNtYhj72bqATQ4w4hblfuXVW7vIzLBZRjZUiYA8aVKi/
qXY3mY3rr0A0zxlNKooLd+DEVCCbdG7jq15hvlq0eVJ8IAwgzRBPZ05nnZjE
2Hy3g/Tl/yiNE1WkUhN2skmPKU4ZofNvY0MduZgNJd8mVtUb6v2UIy4uVlnc
9poduWgZrMQ5kbzwrWvoPKpf5MDVke7b/Z29LUSejZLaZK6jp2fPzf0ilt6k
e9s7u66B7U53HyzNWgjhjx3/n/CvO/3zRxjk332IwV+v44g0kDv/8+/fbiX0
T0+GxWA82eNIr0mK9z8N6DYkAbO62kQEd3klMsgfencchHvOujH8QXp/kEHe
eA5WHaRYtxR/Jeaug1SX8o0AG+Y7fGdOJSFV+PC5tb8r4WHfMOcw/8SrptcU
BaXocTap5EgGN2XIZYT8S1OFLsFAYgDFvC+RZc/HxXqL+P7qV1KCFImvxa3t
rHX2hWD/FZJPnqMeL4H+DqCBDZBsvIcj5PSVBmWCyyS5UzsKTOyv3FjszEWM
vF3JrnYeKqcvAnrfqjQ5dJB0R36/u93tkZ/tR9KfS8rDOdJsaVqApr56B/gQ
iLYS6D7R5gbaYxN7KRlp52Rar/OueZmNU/ND15zP+wCgf22bk+K3bqvW+wjB
VYdWI7DYvJkCcLSl6BcB53bYbK+Gjb2vdeiDyZxEdK+hrMlFEpzujc8VVXj+
obcOnjVwMggfI0Qf/zBP0kmUPgYQPxaINr5zUaIvpshSfu18nEySWfscjOnH
z+DVl3m3/br7rNs+6h53z1fhJRl8YFunih77QzOW1pCyvPmNMLZTw5jPER2m
CtseS0Q8Gh1Hnnl//90ft7a2jzdrmFqLKAVDBfZvs34/iRUzKx56mUzb8O/0
1gcvfz4/eYI1nodPs6JoxpS4QCtokm/rOGL1Elsa4xPkHwtYq4TvSD1B2FGI
k232b4M39vY3lKCHEXCJMrp7EaYYXKTILW5J47GSszZjT3J48YXn0VYHMplr
uHF15NSqR9hLwVByja9BQcRhrDtBEkytX4EdqVvbuzf4H2ewNzIULE35ElrT
NtdEGtRxjvOmDx88WCwW3SA54rcZMYyw9V2NbMwzvfj6iO+6QzB5kltazinx
YDM3LGTKUxWxYS5fcM+svVNbrtFTsqm09CbajYZ5jXLpu2besmro30WRO+vk
YiPvDxkKeT9PXp8ev3n15qzKVnae3p2tEK5x94Dpv//tf+NK/v63/3MI/yIH
aDm+QLkqv7SQDPDfnd7WlnkNShAIJLBbSpCPR8D/YZ1n6Lxq/RQVGIcp6U5m
GPjZMQzZNpoWtb21tXXAv7zrXnSPutInOqQZRguny1HXKxP5wGG4aAN47QmH
AXp0AFRFojkVCxC9t3wo9VXBKDePl+oxNZ5q8yWFzhJ2vEdVTQck0xVFtW1L
LhL7XsO6mhMaOe9Q+7Tp09YFqcQoVXHfGL2/rMUvYrJ1MgWzr7B3Lwhi3wEv
BUj9FdY0zKatX1dTwh1JAI3h8PqYkGNUMmfsVTTo86CIn77rMdZ1J1d4BGjf
NR5B363SP1RZF9ewoul3MYldYRJvqUPNtfXCYyVI/XIx/7Ytn1NKk02+ViL1
KKq2aNt90DLXyhNMfvwMdnywzuE1CTlCH85v4sxG+akC2PCiRS/u56dHe30p
Er7EMKz8kkcpScC/Ip18yf7VjeVA2u1RCmlYFtx0C7W9bagGGomCix8GKxXa
ZhTdtL2mjpwSUHDOiW84au71vJ7Gd80qiab4ODi6TnLKZKjVJhcCCsJlCsty
6qtGX/2ciRhWPMd+la7ZSJVAGsOxckukbeiE7T+WXLRJ6fhJvKgIuqdLDbNp
Qpe7AySP4w4ntDnJR57AfjT4QFnhev0wq2K0P3ZO7WwymBI/YIaHja+/cHWf
GkCKb2Zsjdt+El5DcO0oStRJ0Xi9sssrbXi0v49+A5yVUcwv26uGME7/RVoX
T/aJkrRjKp27xpvgW556PognE2KswEhGVB/XMlZHQzaMgxz+sdfZ3tru7O3t
dSgR+tcVwwOFtn41no5Xf7nXbALE0yipM0n5tplNkvcjz4AfG3zsm2pUu+us
6dWehrXY4M20sRKR4NWqCE3TUtX3LzfLj75OLPB2AzCyAFfB21Ea/9swC7q7
NwMbLPCrGqz5y2ZQ429zYCb3i03jN9OkzBHmUVaqgtZxJ9l4BxzsrsaBrqhT
RldfgQvabBUV9hQIYP058Mc4FUTc8vZ249ujfMXbY7BPV79RU2BexJlLCVmr
vtib+Pw3ggrOBq/jXdSZj3Vt5uNKZQbTZT5SPu43OJd7osS40nYXgSItCWbr
0Gwp1YRiewBJwEc7M4nSiGpN7HNVC/fSz7fyRInvNjtlVxlZEqFQcNax4eYd
l8edbDTC37+cRgGmFV/K0TTGdsUPzuLFv/2MNNd4ugHdNfzQd80IuppkfZK0
XCDmJUD+Tkyt4aBf6j7A5YfOA/jmcOdhd+dgf6u30+70tre7Wwfbj3a2m47M
m/wqSpOPkWTlrD00nBm30lNQPTLWWMbOuwMnfLwZSWULVwCssqwLquiWY5eU
k7ozU761uB1HrplNqhEDwLZaoIpnXNX7rP9luG5G9f7XueXXEz9tq+qZhAVF
ORZqDzB3HEDefALyrAFQ/OV/LpzqR+IugFoPKdpX1eWeZ7TMV2TSrVACKNe0
qgT4CahNQGK1VZqUi1RRh+yIcjmvsi+WK7cDru4pX8tMbhH+dAHGXXyRUX+A
mdMdcZHKFWSrBqGSNYLFg/ez+OpxnzKm269PT4+j98fHR8M3V0eL06dHV6fH
qFkf/XBy8vSHo8Xw48mr10cfXhz13p08Hb8+/vHH1zevnh399vTq7MenR9nl
6dbeZPj92fuf/+Xp5PTk7Lr/U6/Xp4rvCXz3dtbf3vuI3w/Sp9eD6fOt6KdH
89dvF4sXVz8/+/GHH16d3Jy97E//O/zWGw9fTK77ydPL+F/OqB78T91ul6Uo
9n6V6xJ43R3K9JaqF3jsz81khJehVKmIvrsbEVWZJTBHCrBQUlgjl/wq+qlr
krc5SMkm5W7qXPSkgbvf5TldT5h0sUxF5D89/te2OU0H3cdnWQ5nSXSA1DxL
uMr98eso/0B1YE2i7+RmBmoltsJa3k1Z9LJXfbmnaevojpEkOp6+qFXVcdxa
yAN9Zdj8KS5qVOL/5Pw17iZrF5o28mgYQY/6muf5uxSVhw3S6yvjcHiiVoXi
1mPeg0U1fvb26MeTV+boxcnZpfKe1U+fnl2evD07uWyfnlw+b5+ePXt3cfn2
5xXxUUBlPTZKXzagAzPGpH4xpAxSdDmBq/x2OPmPkJS0typ40cE5im7UKYVt
GmZSaQQb3TrY2kK67j3s7SF2Ty4u4Ti+ztLO8zxZEXemhK0aYOXbBshq/Q0n
qmmC6DcMaNYiYZzqaMs+mBuz1sNxSPhfOk9RhHseQU5N1WH8elNNVbkdrXvf
Uo4zSOuCvGiQ5LN5n++zQiyqXO9OZzt6ppoG44swMV3xAcjEZLBSouOgINWf
nny1TMcRSK5/tUz/NuJ8ntRJl75r4tBiO2IJESeS285+eXP+xO9kCvvrqUft
czTQ0WVaM9BDf/CXpbUgEELqmOfp4Ry+Phwd9Ia7oyjuPBzGg06vN9zqRA/3
9zpbW9HW4FEv3u+P9ldAO6/7POm7RmgDkGnxtpchtsimJpdfrW+vBPWBd60E
VdPWM1U5byG5jgZc3O7Skn1b6t3bV4WsygYAMLYgoUqsAZFKYNe6RludSO1E
BSTu0m+bWU3O9ldyp0+J8ZwMWSfnx3qZqfhQljtdR5/jy3HihfIzeI7zNiQO
MXFBr6ssw23jbViS8D2NPlDRV8lXX4c1yaU0N0zgRIzR+U50GK6IStL7ebYo
pIE75x+R/mkvL8caBhf/xdomfaMRIW6F0XWUcBkWhu+ygoeegxpp3lwA/K8T
YPZTcTQ0ny0Y/mvkLaKtmTv7bV9GSIjjDlYEPxiM448DsCi743I6aT4yenNj
9djY70M66WvnWOlZWbmfz5d9MoJC+bqhWl5Fpi0Twb5Hd5V9j75OpVnLlew9
lqFWQ1dZ1vp6ndhKDo0Jbmyce2FQZ6Bxtret5oYdY1sDvPGNrjvT6m7bT0JK
A+h2xaABBsZ+l/T9inSbSNLsqcSG0ilmmhdFqEIGlJaupjTseIWx3yEVOvsr
grFsZbp3hQfW9ldW6EKQFHgpxkIleXyFZ48CkjaXwiaxV7LQqT8BjBvWXqAB
ZE6Pzo6wb5yrXi/Mp+/w289knd2jTjT3zLm0HrAtrA2RiSQxNbbR11fDWrKm
NmvZ2lsug65qtF6qLxpyCZw/u/A1ABPB3ustUJ/daod+X0kOjXNjKfOcZj93
va6oy0y4fzAMi3m/w9jIbfS/pd3xTqXVGudsl9kgm5j7F6fnm964LaOvczEE
pju4RQWLCVtoVW8vbcZC8ApJC5Qm3v16lNvANanh5aPrLwb7OmhZSGlOOlip
Gls+sPd/6Wv3CmknALsLLnNoy6WHpow+yEYtQiPz2zwrqR9cmCtUS82v5+Y3
JesH33HNQ7Dnf/e2eYYWCHwB51L2xxuH75wHqKFI4KtX4pBD9QoejPiLs6xW
+mF+oVMDMP/1W63EE4Brydf1Db4b7brn/5kJV3fxJVRrbKcJ0iMpMQMbiv1/
Rc02M0cp92eY+x+Hmr2+2XcjZ++Ff2Z6ttv4Lza8gnBdwx/zn8OGUf9jk6um
2+kvnzHR8jqOJtUGp+pIV49am634hC+fA/VzNAIl1ut5D7oqyhu9TyIBfoVO
2GQCyjKosdgwTI0+qh2V1hnByapdTJRmQaVrlo7YdcMlj157Nu0cE+5B+mrR
dcmFHhG2fqN0ic2TzaX2Z5WOaNZKlcxGNaXGaFQH14ViBmAcXcfFEBR13L13
pbeU0AertS21tMnVjJuYUsKog0GmVYXB5S50JcCQAxruCj7em7SH9fowNV/E
pTtFVFeaDd+nNrabgdkJ2JoyHkfWF0HXNtgGun6QQ5rO6M1wShWoimhXh+br
26RPgN6/hp1wg8spraeIHBVgJVEfNL/doXfQgtvb8Avbvpha4hFuFMEj5BOY
EmXApI/UrAIGiPmz7cpFLn6TKwSVa69b3L1Dmt/ah+21WAsnvcWk6ATx3O3Y
rqSkJtOAcYIg+wGSopiz2RTR3V50sisVInpRG3V4xkvrpcSzjT4pJIR5Qnnq
dHrFjWPLQKMSeHZ/jq58InbuzkyHDR7vcBvjmI44mGR+6yltD4mOTVtTjlyA
sR937JU9IBaiRO7qE4yKb7+fsEtWLzrR++jt6tym9Uq6jg3xgQCIqC/aYox9
H9DL7F836AjGuhT8KAbdNkgBItzxNCErrmsu6IIcd7aQgLmBYSR3o7tr4N29
urJsfwLXVgZpuu1zBkcgyC8nETvipLt3HGaBe+u3wGhr/8Kg0YEHeuuEdT0v
yd+aX/PodA4XGMJFjaVoakyOtICJ43rQqW7XnnvhRshzLVG3a8XHbMlbhnkN
jAbb89smHgRLGEML7qmrt5/TTu6PsJv2LT3wpEsU+djactsRe4mI8IUT2Rxy
Dyl02SkCeEVcV0Qflr8wbfZjgN7QnsCu+oy4Y5wZxXSgTdBHDv6TApCs/wIB
KNdOSmCNi4GQZGhJ43gy00jGsn7adRGYAdjHY4Ze9kpue5gjyJyH6Ul8W9Rs
AvtRcY/vKe+U23yHs5Xax0sc29rqwb+dsivtaXKPC4c9E7lJDvcSiW/QV59Q
C4BcPPf0F9X+0pWF0eBDmi0m8fDKXirpii8QgNQksPQ63okCpD1wSq9ZbqU7
P2f0T6Kl9vLUQyj3gpFakszoolHRLOJBViyBluz9R0mugiMK8FmJM2hM10al
mKVZVqdM3aM+BuXcawPa2KB3gQ2Q+HeOcllvKNXXg77O6PZ5RagqVrmPRl51
+7axhpOQWCiSZZPCix8UmAmdX3lRgLZHTVS8ksfStKgdBAjC5VRVndq+rbbA
Fw+IHoLigHlEg0tXutCFfVXltljbSmiQXaVYmUpRS1BflXwqZUdymDFG47eh
VbzHeo0f7bCBgmzZpUfDykFqe8JukLb1JRYDNXS/JHOSY1WgKGONErX3xcX/
NseJdGm2TVtzvQsJORdcAxkZ45HgXnV+JIntV1HUhMOxtqsvYysYd4VGlBeS
u+S60QzyaKRKDMgZJBtgj/MrbiQEyho2RoXtgqjCgAZtK6Jmm3RbBGyw0r7K
JQuxFyXcmL8yYDpZUbWFlNNHZcMeQS/APIcippsrrmNh0FMuqkzykKF6nXq5
56OyXKAST+LgerC7krTBACoaFkE/2trLQYkUZgWvQCTWf8E6r+Q8FzaLGED5
Co8oNn1ELlpL7PCvVQNyrQjfxsm4TMQ1b640SNdLzCQsg7O6vsNcil5ycLhy
zPqumXtjVLEp0IxHiVv/sa1L1azaurywN5yVS7vbamgTR6BMKxdtXbEzZnyc
lj9N0HSdYfeRPOVWlCVJ8a54icJXpbl2UaUa22+Ojr07rbgCvUAQg7T1SzWJ
cKqvBQcT/U16pKmQTt8VDmLb13JU14bflGzDoXXLxBVwTJltEfc1FszL5uIx
4WO2Q67X6cVMQRfVBpCc6E5HsWuOLN+yKr/2ndGLuLF6Dq/ldBFmd+sP520C
a9a8SV6E7dYtBBBd5a6HLnkwVBQOmwHqNJMYPWAqaeiiPoayJVcBt/a182WB
LFNbm7mIYk3NaDp0QFadTocqB9EFdORUJGaun76rfvV549Oh6CB4ZcUIlMG4
9Xlj46dYHBXYZ5hXGqUfwAgABdl8H4GIGYBmfzSJB+Z5nAI7iMHUx94n5q/L
j3AQwU78OTEvtUuEoptLMJ2AO37z9sQ1t0ak4htXYITNmE6OLk8vHlD5L/WO
Oz3Ha4FcM2PUg7Epo7SlcxYh5/qBJT3PLfEGV7f61xpt/F+PVjPj2NMAAA==
</rfc> </rfc>
 End of changes. 85 change blocks. 
1821 lines changed or deleted 1049 lines changed or added

This html diff was produced by rfcdiff 1.48.