SIP Call-Info Parameters for Rich Call Data
draft-ietf-sipcore-callinfo-rcd-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Chris Wendt , Jon Peterson | ||
| Last updated | 2023-08-10 (Latest revision 2023-06-03) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sipcore-callinfo-rcd-06
Network Working Group C. Wendt
Internet-Draft Somos Inc.
Intended status: Standards Track J. Peterson
Expires: 5 December 2023 Neustar Inc.
3 June 2023
SIP Call-Info Parameters for Rich Call Data
draft-ietf-sipcore-callinfo-rcd-06
Abstract
This document describes a SIP Call-Info header field usage defined to
include Rich Call Data (RCD) associated with the identity of the
calling party that can be rendered to a called party for providing
more descriptive information about the caller or more details about
the reason for the call. This includes extended information about
the caller beyond the telephone number such as a calling name, a logo
or photo representing the caller or a jCard object representing the
calling party. The elements defined for this purpose are intended to
be extensible to accommodate related information about calls that
helps people decide whether to pick up the phone and with the use of
icon and newly defined jCard and other elements to be compatible and
complimentary with the STIR/PASSporT Rich Call Data framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 December 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wendt & Peterson Expires 5 December 2023 [Page 1]
Internet-Draft Call-Info Rich Call Data June 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. A Call-Info framework for carrying Rich Call Data . . . . . . 5
5. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 6
6. "call-reason" Call-Info Parameter . . . . . . . . . . . . . . 7
7. Examples and usage of Call-Info for Rich Call Data . . . . . 8
8. Usage of jCard and property specific usage . . . . . . . . . 9
8.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 9
8.2. Usage of multimedia data in jCard or with icon . . . . . 9
8.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 10
8.4. Identification properties . . . . . . . . . . . . . . . . 11
8.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 11
8.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 11
8.4.3. "nickname" property . . . . . . . . . . . . . . . . . 12
8.4.4. "photo" property . . . . . . . . . . . . . . . . . . 12
8.5. Delivery Addressing Properties . . . . . . . . . . . . . 12
8.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 12
8.6. Communications Properties . . . . . . . . . . . . . . . . 13
8.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 13
8.6.2. "email" property . . . . . . . . . . . . . . . . . . 14
8.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 14
8.7. Geographical Properties . . . . . . . . . . . . . . . . . 14
8.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 14
8.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 15
8.8. Organizational Properties . . . . . . . . . . . . . . . . 15
8.8.1. "title" property . . . . . . . . . . . . . . . . . . 15
8.8.2. "role" property . . . . . . . . . . . . . . . . . . . 15
8.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 16
8.8.4. "org" property . . . . . . . . . . . . . . . . . . . 16
8.9. Explanatory Properties . . . . . . . . . . . . . . . . . 16
8.9.1. "categories" property . . . . . . . . . . . . . . . . 16
8.9.2. "note" property . . . . . . . . . . . . . . . . . . . 17
8.9.3. "sound" property . . . . . . . . . . . . . . . . . . 17
8.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 17
8.9.5. "url" property . . . . . . . . . . . . . . . . . . . 18
8.9.6. "version" property . . . . . . . . . . . . . . . . . 18
Wendt & Peterson Expires 5 December 2023 [Page 2]
Internet-Draft Call-Info Rich Call Data June 2023
9. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. SIP Call-Info Header Field Purpose Token Request . . . . 19
11.2. SIP Call-Info Header Field Purpose Token Request . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Traditional telephone network signaling protocols have long supported
delivering a 'calling name' from the originating side, though in
practice, the terminating side is often left to derive a name from
the calling party number by consulting a local address book or an
external database. SIP [RFC3261] similarly can carry a 'display-
name' in the From header field value from the originating to
terminating side, though it is an unsecured field that is not
commonly trusted and often replaced or ignored. The same can be
considered true of information in the Call-Info header fields in SIP.
To allow calling parties to initiate and called parties to receive a
more comprehensive, deterministic, and extensible rich call data for
incoming calls, this document describes new tokens for the SIP
[RFC3261] Call-Info header field and a corresponding "purpose"
parameter. A new parameter of Call-Info designed for carrying a
"reason" value. For this document and depending on the policies of
the communications system, calling parties could either be considered
the end user device, (e.g. a SIP UA), or as a network service as part
of a telephone service provider. Similarly, called parties could
also similarly be an end user device or the network telephone service
provider acting on behalf of the recipient of the call.
Used on its own, this specification assumes that the called party
user agent can trust the SIP network or the SIP provider to assign,
deliver and protect the correct rich call data (RCD) information as
an end-to-end security policy. However, as is true in many
interconnected services, this end-to-end trust can not be guarenteed
and therefore as the recommended approach, the entity inserting the
Call-Info header field should also sign the caller information via
STIR [RFC7340] defined protocol tools for SIP [RFC8224] and
specifically through the use of Rich Call Data (RCD) or the "rcd"
PASSporT defined in [I-D.ietf-stir-passport-rcd].
Alternatively, this specification can be utilized in conjunction with
the protocols defined in [I-D.ietf-stir-passport-rcd] as part of the
communications signaling path, but specifically in the trusted UNI
device interface at the terminating side of the communications as
Wendt & Peterson Expires 5 December 2023 [Page 3]
Internet-Draft Call-Info Rich Call Data June 2023
part of an authenticated network to device trusted signaling where a
device may not have the ability to verify the "rcd" PASSporT, but can
receive the RCD information using Call-Info as defined in this
specification.
[RFC7852] provides a means of carrying additional data about callers
for the purposes of emergency services (especially its Section 4.4
"Owner/Subscriber" information). This specification provides an
overlapping functionality for non-emergency cases. Rather than
overloading its "EmergencyCallData" Call-Info "purpose" parameter
value, this document defines a separate "purpose" parameter for the
more generic delivery of information via jCard [RFC7095]. This
document borrows from [RFC7852] the capability to carry a data
structure as a body, through the use of the "cid" URI scheme
[RFC2392].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Overview
The Call-Info header field, defined in [RFC3261] Section 20.9,
defines a purpose parameter currently with "info", "icon", and "card"
tokens. This document defines two new purpose values and one new
generic parameter for Call-Info.
The first purpose value defined is "jcard" and is used to associate
rich call data related to the identity of the calling party in the
form of a jCard [RFC7095]. While there is a "card" token that is
already defined with similar purpose, there are two primary reasons
for the definition and usage of jCard and the use of JSON over the
XML based vCard [RFC2426]. First, JSON has become the default and is
generally the widely accepted optimally supported format for
transmission, parsing, and manipulation of data on IP networks.
Second, jCard has also been defined in [I-D.ietf-stir-passport-rcd]
and has been adopted by PASSporT [RFC8225] because of the usage of
JSON Web Tokens (JWT) [RFC7519].
A parameter for "call-reason" is to be used to provide a string or
other object that is used to convey the intent or reason the caller
is calling to help the called party understand better the context of
the call and why they may want to answer the call.
Wendt & Peterson Expires 5 December 2023 [Page 4]
Internet-Draft Call-Info Rich Call Data June 2023
4. A Call-Info framework for carrying Rich Call Data
This document is intended to extend the currently defined Call-Info
to be compatible and complimentary to the Rich Call Data framework
defined in [I-D.ietf-stir-passport-rcd]. In general, a SIP based
call involves multiple hops that transition between different trusted
and untrusted network relationships. The STIR framework [RFC7340] is
intended to address the protection of the carriage of different call
information and identities over untrusted network relationships that
wasn't addressed when the SIP specifications were originally defined.
Call-Info, as defined in [RFC3261] Section 20.9, is the defined
mechanism for carrying call and caller related information, currently
defining the "icon", "info", and "card" purpose tokens, and also
defines proceedures for defining new purpose tokens. This document
will discuss the use of both existing tokens and define new purpose
tokens to correspond to the Rich Call Data framework.
There are a number of Rich Call Data information that can use the
Call-Info header field to transmit the information in a SIP request.
The current STIR Rich Call Data specification
[I-D.ietf-stir-passport-rcd] defines calling name and a logo or icon
associated with the caller and a call reason string. It also
discusses a more extensible way of carrying caller information using
jCard [RFC7095]. It may be that future specifications may extend
more information types and similar to how this document discusses
extending Call-Info to provide corresponding functionality to STIR
RCD it is RECOMMENDED that future specifications also provide
corresponding Call-Info extensions.
As discussed in [I-D.ietf-stir-passport-rcd], calling name is already
covered in [RFC3261] using the display-name component of the From
header field value of the request, alternatively for some calls this
may come from the P-Asserted-ID header [RFC3325]. This is out of
scope for Call-Info header field so will not be covered in this
document further.
For logos or icons that can represent the calling party the "icon"
purpose token is defined in [RFC3261] and is intended to be used for
defining a URI to reference an image resource that can be displayed
to the user that receives the SIP request. For the purpose of this
document and the transmission of Rich Call Data, this purpose token
should be used as defined. There is some high level guidance
provided later in the document around some of the image formatting
and related information.
Call reason is a new purpose that this document defines as a string
with a new Call-Info header field parameter. jCard is another more
comprehensive and extensible mechanism defined in the STIR Rich Call
Wendt & Peterson Expires 5 December 2023 [Page 5]
Internet-Draft Call-Info Rich Call Data June 2023
Data framework. While [RFC3261] does have a "card" purpose token,
the intent of defining a new "jcard" purpose token is to specifically
use the JSON jCard [RFC7095] and provide specific guidance in this
document for the use and non-use of the attributes of the jCard
specification specific to describing the calling party in a
communications session as well as some of the security considerations
around that information. Both of these new purpose tokens are
defined in the next sections.
5. "jcard" Call-Info Token
The use of the new Call-Info Token "jcard" is for the purpose of
supporting RCD associated with the identity of a calling party in a
SIP call [RFC3261] Section 20.9. The format of a Call-Info header
field when using the "jcard" is as follows.
The Call-Info header field is defined to include a URI, where here
the resource pointed to by the URI is a jCard JSON object [RFC7095].
The MIME media type set for the JSON text MUST be set as application/
json with a default encoding of UTF-8 [RFC4627]. A jCard also MAY be
carried in the body of the SIP request bearing this Call-Info via the
"cid" URI scheme [RFC2392]. Alternatively, the URI MUST define the
use HTTPS or a transport that can validate the integrity of the
source of the resource as well as the transport channel through which
the resource is retrieved.
An example of a Call-Info header field is:
Call-Info: <https://example.com/qbranch.json>;purpose=jcard
An example contents of a URL linked jCard JSON file is shown as
follows:
["vcard",
[
["version",{},"text","4.0"],
["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri","https://example.com/photos/q-256x256.png"],
["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
]
]
An example SIP INVITE using the "cid" URI scheme is as follows.
Wendt & Peterson Expires 5 December 2023 [Page 6]
Internet-Draft Call-Info Rich Call Data June 2023
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551000@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710
Call-Info: <cid:12155551000@example.com>;purpose=jcard;call-reason= \
"Rendezvous for Little Nellie"
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551000@gateway.example.com>
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: application/sdp
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--boundary1
Content-Type: application/vcard+json
Content-ID: <12155551000@example.com>
["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"],
["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht
tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u
ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"]]]
6. "call-reason" Call-Info Parameter
This specification also defines a parameter of the Call-Info header
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 message SHOULD be
no longer than 64 characters; displays that support this
specification may be forced to truncate messages that cannot fit onto
a screen. This message conveys the caller's intention in contacting
the callee. It is an optional parameter, and the sender of a SIP
request cannot guarantee that its display will be supported by the
Wendt & Peterson Expires 5 December 2023 [Page 7]
Internet-Draft Call-Info Rich Call Data June 2023
terminating endpoint. The manner in which this reason is set by the
caller is outside the scope of this specification.
One alternative approach would be to use the baseline [RFC3261]
Subject header field value to convey the reason for the call.
Because the Subject header has seen little historical use in SIP
implementations, however, and its specification describes its
potential use in filtering, it seems more prudent to define a new
means of carrying a call reason indication.
An example of a Call-Info header field value with the "call-reason"
parameter follows:
Call-Info: <https://example.com/jbond.json>;purpose=jcard;
call-reason="For your ears only"
Refer to the next section that extends call-reason and, in
particular, discusses reasoning for the use of "call-reason"
parameter versus considering "jinfo" with an included "call-reason"
key value.
7. Examples and usage of Call-Info for Rich Call Data
The procedures for the usage of the purpose tokens and URIs should
generally follow the procedures defined in [RFC3261]. So, as an
example, if there is a jCard and icon with a call reason, the
following example shows the use of mulitple purpose and parameters in
the the Call-Info header field.
Call-Info: <https://example.com/jbond.json>;purpose=jcard,
<https://example.com/jbond.png>;purpose=icon;
call-reason="For your ears only"
There is the possible case where there may only be a call-reason
present and no other Rich Call Data related info. In this case, it
is RECOMMENDED to use the null data URI, "data:" as the URI with any
purpose parameter. As an example:
Call-Info: <data:>;purpose=icon;
call-reason="For your ears only"
Wendt & Peterson Expires 5 December 2023 [Page 8]
Internet-Draft Call-Info Rich Call Data June 2023
8. Usage of jCard and property specific usage
Beyond the definition of the specific properties or JSON arrays
associated with each property. This specification defines a few
rules above and beyond [RFC7095] specific to the use of jCard for
Call-Info and Rich Call Data making sure there is a minimum level of
supported properties that every implementation of this specification
should adhere to. This includes support for interpreting the value
of this property and the ability to render in some appropriate form
the display capabilities of common telephone devices, as well as
apps, and also includes requirements specific to either textual
displays and graphics capable displays.
8.1. Usage of URIs in jCard
When one or more URIs are used in a jCard, it is important to note
that any URI referenced data, with the exception of the top-level
usage of "jcl" as a URI to the jCard itself (unless updated by any
future extensions of this specification) MUST NOT contain any URI
references. In other words, the jCard can have URI references as
defined in the jCard specification and this document, but the content
referenced by those URIs MUST NOT have any URIs, and therefore MUST
be enforced by the client to not follow those URI references or not
render that content to the user if any URI are present in that
specific URI linked content. The purpose of this is to control the
security and more specifically align with the content integrity
mechanism defined in [I-D.ietf-stir-passport-rcd]. It is the belief
of the authors that there isn't a scenario that deeper URI references
would be required or even supported by the current set of properties
for the typical use of jCard properties, but because jCard is
extensible, this rule is set to restrict further extension without
the proper consideration of security and integrity properties of both
Call-Info usage as well as the Rich Call Data and STIR signing of the
data [I-D.ietf-stir-passport-rcd], [RFC8224].
8.2. Usage of multimedia data in jCard or with icon
With the use of the purpose token "icon" or for the cases where
jCards incorporate URIs or directly include via Base64 encoding of
digital images and sounds. We specify a few recommended conventions
to facilitate more consistent support of the successful decoding and
rendering of these images or media formats.
For images, such as for the photo and logo properties, the default
image formats SHOULD be png or jpg. These files are mostly commonly
used to support 24-bit RGB images which should consequently be the
default. There are some older telephone devices that may only
support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit
Wendt & Peterson Expires 5 December 2023 [Page 9]
Internet-Draft Call-Info Rich Call Data June 2023
or 1-bit), also with potentially only grayscale or 1-bit black and
white color displays. These exceptions are should considered
optional to support or even recommended not to support and at least
at the time of writing this document are becoming increasingly rare
(i.e. typically displays on devices are either color or color-aware
graphical displays that support png or jpg formats or exclusively
textual displays).
In addition, vector images are increasingly popular in their use for
icons and the need for scalable images without having to send
multiple resolutions. SVG format and a minimum of support for
[W3C-SVGTiny1.2] specifically appropriate for this specification has
gained wide support as of the writing of this document, as a common
format for vector images and should be supported as an additional
default format for devices that support this specification.
For the cases where image files are referenced by URIs as file
resources, this document defines a character string that SHOULD be
concatenated on to the end of a file name, before the file extension
that signals the height and width of the image to the end device for
the convenience of determining the appropriate resolution to retrieve
without the need to retrieve all the image files. It is also
recommended that images are square ratio formatted with equal height
and width and with a power of two value for the number of pixels
(e.g. 32x32, 128x128, 512x512). The format of the string should be
"filename-HxW" where filename represents the unique string
representing the file and H represents the height in pixels and W
represents the width in pixels.
Because this is a complex and often debated topic that has evolved
over the many years of advances in image coding and display
technologies, we likely suggest relying on either future
specifications or industry forum specifications that might correspond
to supporting particular classes of devices to further define how
URIs can reference appropriate image formats and files.
For audio files, the recommendation is to provide mp3, m4a, or wav
files, although the usage of sound is not well defined in this
specification as, for example, a special ring tone for a particular
caller, and future documents should consider both usage and potential
security risks of playing sounds that are not specifically authorized
by a device user.
8.3. Cardinality
Property cardinalities are indicated, for convenience, using the
following notation and follow the guidance of jCard [RFC7095] and
vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6):
Wendt & Peterson Expires 5 December 2023 [Page 10]
Internet-Draft Call-Info Rich Call Data June 2023
+-------------+--------------------------------------------------+
| Cardinality | Meaning |
+-------------+--------------------------------------------------+
| 1 | Exactly one instance per jCard MUST be present. |
| *1 | Exactly one instance per jCard MAY be present. |
| 1* | One or more instances per jCard MUST be present. |
| * | One or more instances per jCard MAY be present. |
+-------------+--------------------------------------------------+
8.4. Identification properties
These types are used to capture information associated with the
identification and naming of the entity associated with the jCard.
They are initially defined in [RFC6350], but the following list of
properties included and repeated in this Section is a subset of the
properties defined for jCard with properties selected for this
document that have relevance to telephone and messaging applications.
jCard is an extensible object and therefore, there may also be future
specifications that extend the set of properties that may be relevant
to the set of communications applications that utilize this
specification.
8.4.1. "fn" property
The "fn" property has the intent of providing a formatted text
corresponding to the name of the object the jCard represents.
Reference [RFC6350] Section 6.2.1.
Value type: A single text value.
Cardinality: 1*
Example:
["fn", {}, "text", "Mr. John Q. Public\, Esq."]
8.4.2. "n" property
The "n" property has the intent of providing the components of the
name of the object the jCard represents. Reference [RFC6350]
Section 6.2.2.
Value type: A single structured text value. Each component can have
multiple values.
Cardinality: *1
Wendt & Peterson Expires 5 December 2023 [Page 11]
Internet-Draft Call-Info Rich Call Data June 2023
Example:
["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."]
["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."]
8.4.3. "nickname" property
The "nickname" property has the intent of providing the text
corresponding to the nickname of the object the jCard represents.
Reference [RFC6350] Section 6.2.3.
Value type: One or more text values separated by a COMMA character
(U+002C).
Cardinality: *
Example:
["nickname", {}, "text", "Robbie"]
["nickname", {}, "text", "Jim,Jimmie"]
["nickname", {}, "text", "TYPE=work:Boss"]
8.4.4. "photo" property
The "photo" property has the intent of supplying an image or
photograph information that annotates some aspect of the object the
jCard represents. Reference [RFC6350] Section 6.2.4.
In addition to the definition of jCard, and to promote
interoperability and proper formatting and rendering of images, the
photo SHOULD correspond to a square image size of the sizes 128x128,
256x256, 512x512, or 1024x1024 pixels.
Value type: A single URI.
Cardinality: *
Example:
["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"]
8.5. Delivery Addressing Properties
These properties are concerned with information related to the
delivery addressing or label for the jCard object.
8.5.1. "adr" property
The "adr" property has the intent of providing the delivery address
of the object the jCard represents. Reference [RFC6350]
Section 6.3.1.
Wendt & Peterson Expires 5 December 2023 [Page 12]
Internet-Draft Call-Info Rich Call Data June 2023
Value type: A single structured text value, separated by the
SEMICOLON character (U+003B).
Cardinality: *
Example:
["adr", {"type":"work"}, "text",
["", "", "3100 Massachusetts Avenue NW", "Washington", "DC",
"20008", "USA"]
8.6. Communications Properties
These properties describe information about how to communicate with
the object the jCard represents.
8.6.1. "tel" property
The "tel" property has the intent of providing the telephone number
for telephony communication of the object the jCard represents.
Reference [RFC6350] Section 6.4.1.
Relative to the SIP From header field value this information may
provide alternate telephone number or other related telephone numbers
for other uses.
It is important to note that any of the potential instances of the
"tel" property should not be considered part of the authentication or
verification part of STIR [RFC8224] or required to match the "orig"
claim in the PASSporT [RFC8225]. These telephone numbers should be
considered for contact, fax, or other purposes aligned with the
general usage of jCard and vCard, although consideration of confusing
the caller with different contact telephone number information versus
the actual verified telephone number should be made from a general
policy point of view.
Value type: By default, it is a single free-form text value (for
backward compatibility 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 [RFC3966], but other schemes MAY be used.
Cardinality: *
Example:
["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri",
"tel:+1-202-555-1000"]
["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"]
Wendt & Peterson Expires 5 December 2023 [Page 13]
Internet-Draft Call-Info Rich Call Data June 2023
8.6.2. "email" property
The "email" property has the intent of providing the electronic mail
address for communication of the object the jCard represents.
Reference [RFC6350] Section 6.4.2.
Value type: A single text value.
Cardinality: *
Example:
["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"]
["email", {"pref":"1"}, "text", "jane_doe@example.com"]
8.6.3. "lang" property
The "lang" property has the intent of providing the language(s) that
may be used for contacting of the object the jCard represents.
Reference [RFC6350] Section 6.4.4.
Value type: A single language-tag value.
Cardinality: *
Example:
["lang", {"type":"work", "pref":"1"}, "language-tag", "en"]
["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"]
["lang", {"type":"home"}, "language-tag", "fr"]
8.7. Geographical Properties
These properties are concerned with information associated with
geographical positions or regions associated with the object the
jCard represents.
8.7.1. "tz" property
The "tz" property has the intent of providing the time zone of the
object the jCard represents. Reference [RFC6350] Section 6.5.1.
Note: the up-to-date reference for where time-zone names are
maintained is, at the authoring of this document, at this web
address, https://www.iana.org/time-zones.
Value type: The default is a single text value. It can also be reset
to a single URI or utc-offset value.
Cardinality: *
Wendt & Peterson Expires 5 December 2023 [Page 14]
Internet-Draft Call-Info Rich Call Data June 2023
Example:
["tz", {}, "text", "Raleigh/North America"]
8.7.2. "geo" property
The "geo" property has the intent of providing the global positioning
of the object the jCard represents. Reference [RFC6350]
Section 6.5.2.
Value type: A single URI.
Cardinality: *
Example:
["geo", {}, "uri", "geo:37.386013,-122.082932"]
8.8. Organizational Properties
These properties are concerned with information associated with
characteristics of the organization or organizational units of the
object that the jCard represents.
8.8.1. "title" property
The "title" property has the intent of providing the position or job
of the object the jCard represents. Reference [RFC6350]
Section 6.6.1.
Value type: A single text value.
Cardinality: *
Example:
["title", {}, "text", "Research Scientist"]
8.8.2. "role" property
The "role" property has the intent of providing the position or job
of the object the jCard represents. Reference [RFC6350]
Section 6.6.2.
Value type: A single text value.
Cardinality: *
Example:
["role", {}, "text", "Project Leader"]
Wendt & Peterson Expires 5 December 2023 [Page 15]
Internet-Draft Call-Info Rich Call Data June 2023
8.8.3. "logo" property
The "logo" property has the intent of specifying a graphic image of a
logo associated with the object the jCard represents. Reference
[RFC6350] Section 6.6.3.
Value type: A single URI.
Cardinality: *
Example:
["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"]
["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...>"]
8.8.4. "org" property
The "org" property has the intent of specifying the organizational
name and units of the object the jCard represents. Reference
[RFC6350] Section 6.6.2.
Value type: A single structured text value consisting of components
separated by the SEMICOLON character (U+003B).
Cardinality: *
Example:
["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"]
8.9. Explanatory Properties
These properties are concerned with additional explanations, such as
that related to informational notes or revisions specific to the
jCard.
8.9.1. "categories" property
The "categories" property has the intent of specifying application
category information about the object the jCard represents.
Reference [RFC6350] Section 6.7.1.
Value type: One or more text values separated by a COMMA character
(U+002C).
Cardinality: *
Wendt & Peterson Expires 5 December 2023 [Page 16]
Internet-Draft Call-Info Rich Call Data June 2023
Example:
["categories", {}, "text", "TRAVEL AGENT"]
["categories", {}, "text", "INTERNET,IETF,INDUSTRY"]
8.9.2. "note" property
The "note" property has the intent of specifying supplemental
information or a comment about the object the jCard represents.
Reference [RFC6350] Section 6.7.2.
Value type: A single text value.
Cardinality: *
Example:
["note", {}, "text", "This fax number is operational 0800 to 1715
EST\, Mon-Fri."]
8.9.3. "sound" property
The "sound" property has the intent of specifying a digital sound
content information that annotates some aspect of the object the
jCard represents. This property is often used to specify the proper
pronunciation of the name property value of the jCard. Reference
[RFC6350] Section 6.7.5.
Value type: A single URI.
Cardinality: *
Example:
["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"]
["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...>"]
8.9.4. "uid" property
The "uid" property has the intent of specifying a globally unique
identifier corresponding to the object the jCard represents.
Reference [RFC6350] Section 6.7.6.
Value type: A single URI value. It MAY also be reset to free-form
text.
Wendt & Peterson Expires 5 December 2023 [Page 17]
Internet-Draft Call-Info Rich Call Data June 2023
Cardinality: *1
Example:
["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"]
8.9.5. "url" property
The "url" property has the intent of specifying a uniform resource
locator associated with the object the jCard represents. Reference
[RFC6350] Section 6.7.8.
There is potential security and privacy implications of providing
URLs with telephone calls. The end client receiving a jCard with a
URL property MUST only display the URL and not automatically follow
the URL or provide automatic preview of the URL, and generally
provide good practices in making it clear to the user it is their
choice to follow the URL in a browser context consistent with all of
the common browser security and privacy practices available on most
consumer OS environments.
Value type: A single uri value.
Cardinality: *
Example:
["url", {}, "uri", "https://example.org/french-rest/chezchic.html"]
8.9.6. "version" property
The "version" property MUST be included and is intended to specify
the version of the vCard specification used to format this vCard.
Reference [RFC6350] Section 6.7.9.
Value type: A single text value.
Cardinality: 1
Example:
["version", {}, "text", "4.0"]
9. Extension of jCard
Part of the intent of the usage of jCard is that it has its own
extensibility properties where new properties can be defined to relay
newly defined information related to a caller. This capability is
inherently supported as part of standard extensibility. However,
usage of those new properties should be published and registered
following [RFC7095] Section 3.6 or new specifications.
Wendt & Peterson Expires 5 December 2023 [Page 18]
Internet-Draft Call-Info Rich Call Data June 2023
10. Acknowledgements
We would like to thank David Hancock, Alec Fenichel and other members
of the SIPCORE and STIR working group for helpful suggestions and
comments for the creation of this draft.
11. IANA Considerations
11.1. SIP Call-Info Header Field Purpose Token Request
[this RFC] defines the "jcard" as a new value for the "purpose"
parameter in the Call-Info header in the "Header Field Parameters and
Parameter Values" registry defined by [RFC3968].
+--------------+----------------+-------------------+----------------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+----------------+
| Call-Info | purpose | Yes | add:[this RFC] |
+--------------+----------------+-------------------+----------------+
11.2. SIP Call-Info Header Field Purpose Token Request
[this RFC] defines the "call-reason" generic parameter for use as a
new parameter in the Call-Info header in the "Header Field Parameters
and Parameter Values" registry defined by [RFC3968]. The parameter's
token is "call-reason" and it takes the value of a quoted string.
12. Security Considerations
Revealing information such as the name, location, and affiliation of
a person necessarily entails certain privacy risks. SIP and Call-
Info has no particular confidentiality requirement, as the
information sent in SIP is in the clear anyway. Transport-level
security can be used to hide information from eavesdroppers, and the
same confidentiality mechanisms would protect any Call-Info or jCard
information carried or referred to in SIP.
The security framework of signing and providing integrity to this
data should be followed [I-D.ietf-stir-passport-rcd], with the idea
that the use of constraints and other certificate based associations
should be considered. This includes considerations around
information about the calling party being generally constant vs per
call data being more temporal. This also includes the relationship
that certificates with constraints presents to how they relate to
each other and how that information is managed, protected, and
associated with the correct call corresponding to a calling party.
13. Normative References
Wendt & Peterson Expires 5 December 2023 [Page 19]
Internet-Draft Call-Info Rich Call Data June 2023
[I-D.ietf-stir-passport-rcd]
Wendt, C. and J. Peterson, "PASSporT Extension for Rich
Call Data", Work in Progress, Internet-Draft, draft-ietf-
stir-passport-rcd-24, 1 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-
passport-rcd-24>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, DOI 10.17487/RFC2426, September 1998,
<https://www.rfc-editor.org/info/rfc2426>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/info/rfc3966>.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
DOI 10.17487/RFC3968, December 2004,
<https://www.rfc-editor.org/info/rfc3968>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>.
Wendt & Peterson Expires 5 December 2023 [Page 20]
Internet-Draft Call-Info Rich Call Data June 2023
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[W3C-SVGTiny1.2]
W3C, "Scalable Vector Graphics (SVG) Tiny 1.2
<https://www.w3.org/TR/SVGMobile/>", 22 December 2008.
Authors' Addresses
Wendt & Peterson Expires 5 December 2023 [Page 21]
Internet-Draft Call-Info Rich Call Data June 2023
Chris Wendt
Somos Inc.
United States of America
Email: chris-ietf@chriswendt.net
Jon Peterson
Neustar Inc.
1800 Sutter St Suite 570
Concord, CA 94520,
United States of America
Email: jon.peterson@neustar.biz
Wendt & Peterson Expires 5 December 2023 [Page 22]