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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<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 | <t>This document defines usage of the SIP Call-Info header field <xref tar | |||
"icon" <xref target="RFC3261"/> is used to indicate a URI for an image resource | get="RFC3261"/> that allows called parties to receive a more comprehensive and e | |||
that can be displayed to the user receiving the SIP request. For the purpose of | xtensible set of Rich Call Data (RCD) for incoming calls. It defines specific us | |||
this document and the transmission of RCD, the "icon" 'purpose' token should be | age of the Call-Info header field, a new parameter ('call-reason'), and a new to | |||
used as defined. Section 8.2 provides high-level guidance on image formatting an | ken ("jcard") for the 'purpose' parameter of the Call-Info header field. Dependi | |||
d related information.</t> | 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>This document defines 'call-reason' as a new parameter for the Call-Info head | <t>Alternatively, this specification can be utilized in conjunction with t | |||
er field. This parameter carries a string indicating the reason for the call.</t | he protocols defined in <xref target="RFC9795"/> as part of the communications s | |||
> | ignaling path, specifically in the trusted User-Network Interface (UNI) device i | |||
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 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>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> | <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> | |||
</section> | <!-- [rfced] For readability, please consider the possible update below. Also, | |||
<section anchor="jcard-call-info-purpose-token"><name>"jcard" Call-Info 'purpose | is the information not to be "considered" modifiable, or should it be not modifi | |||
' Token</name> | able? | |||
<t>The Call-Info 'purpose' token "jcard" indicates support of RCD associated wit | Original: | |||
h the identity of a calling party in a SIP call <xref section="20.9" sectionForm | The insertion of the RCD Call-Info header field | |||
at="comma" target="RFC3261"/>. The format of a Call-Info header field when using | should be considered a trusted action based on trusted information, | |||
the "jcard" token is as follows.</t> | and the information MUST NOT be considered modifiable representing | |||
the best practice of determining the final representation of the | ||||
caller RCD to the user. | ||||
<t>The Call-Info header field is defined to include a URI that points to a resou | Perhaps: | |||
rce that is a jCard JSON object <xref target="RFC7095"/>. The media type for the | The best way to determine the final representation of the | |||
JSON text MUST be set as application/json with an encoding of UTF-8 <xref targe | caller RCD to the user is to consider the insertion of the | |||
t="RFC8259"/>. This MAY be carried directly in the Call-Info header field URI us | RCD Call-Info header field a trusted action based on trusted information, | |||
ing the "data" URI scheme. A jCard also MAY be carried in the body of the SIP re | whereby the information MUST NOT be considered modifiable. | |||
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>Because the use and purpose of this specification is to provide a single pres entation of rich call data information, a call and its corresponding single RCD- related Call-Info header field MUST only contain a single jCard object represent ed by an array with two elements. The array MUST only include a single first ele ment with the string "vcard", and the second element is an array of jCard proper ties corresponding to the single entity jCard object.</t> | <t>The RCD framework defined both in this document as well as in <xref tar get="RFC9795"/> carries call-specific information. The insertion of RCD is inten ded to be singular in that the receiving party should not be required to make an y call-specific decisions based on redundant, duplicate, or conflicting RCD. The RCD information is either intended to be added by a party that is authoritative over that information or to have been translated from a verified STIR RCD PASSp orT and unmodified once in a trusted domain. Any additional parties involved in the call path <bcp14>MUST NOT</bcp14> modify the Call-Info header field or add a dditional Call-Info header fields related to RCD. The insertion of the RCD Call- Info header field should be considered a trusted action based on trusted informa tion, and the information <bcp14>MUST NOT</bcp14> be considered modifiable repre senting the best practice of determining the final representation of the caller RCD to the user. This specification acknowledges that without the use of STIR o r other mechanisms, detection of any modifications is not possible, so guidance for the use of this specification in a trusted UNI part of the network is import ant.</t> | |||
<t>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 154 ¶ | |||
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 193 ¶ | |||
--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 do not require an a | ||||
ssociated 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 274 ¶ | |||
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 311 ¶ | |||
"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 339 ¶ | |||
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 373 ¶ | |||
"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 "Caller ID" | ||||
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. 88 change blocks. | ||||
1818 lines changed or deleted | 1049 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |