Comcast

Comcast Technology Center Philadelphia, PA 19103 USA chris-ietf@chriswendt.net

Neustar Inc.

1800 Sutter St Suite 570 Concord, CA 94520 US jon.peterson@neustar.biz

art Identity This document describes a SIP Call-Info header field usage defined to include rich data associated with the identity of the calling party that can be rendered to a called party for providing more useful information about the caller or the specific reason for the call. This includes extended comprehensive information about the caller such as what a jCard object can represent for describing the calling party or other call specific information such as describing the reason or intent of the call. 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 additionally, with the use of jCard and other elements, to be compatible with the STIR/PASSporT Rich Call Data framework.

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 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. The same is true of information in the Call-Info header field. To allow calling parties to initiate, and called parties to receive, a more comprehensive, deterministic, and extensible rich call data for incoming calls, we describe new tokens for the SIP Call-Info header field and a corresponding “purpose” parameter. We also define a new parameter of Call-Info designed for carrying a “reason” value. For this document, depending on the policies of the communications system, calling parties could either be the end user device or an originating service provider, and called parties could also similarly be an end user device or the terminating 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 deliver the correct rich call data (RCD) information. This may not always be the case and thus, the entity inserting the Call-Info header field and the UAS relying on it SHOULD be part of the same trust domain . Alternatively, and likely the recommended approach, the entity inserting the Call-Info header field should also sign the caller information via STIR mechanisms and specifically through the . This STIR signature would likely be provided by the caller itself or the originating service provider using an authoritative signature to authenticate the information is from the originator and hasn’t been tampered with in transmission. 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 . This document borrows from the capability to carry a data structure as a body, through the use of the “cid” URI scheme .

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 when, and only when, they appear in all capitals, as shown here.

The Call-Info header field, defined in Section 20.9, defines a purpose parameter currently with “info”, “icon”, and “card” tokens. This document defines one new purpose value and one new generic parameter for Call-Info. The value “jcard” is to be used to associate rich call data related to the identity of the calling party in the form of a jCard . 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 . 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 and has been adopted by PASSporT because of the usage of JSON Web Tokens (JWT) . A generic 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.

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 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 . The web server serving this file MUST use the MIME media type for JSON text as application/json with a default encoding of UTF-8 . A jCard also MAY be carried in the body of the SIP request bearing this Call-Info via the “cid” URI scheme . 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:

;purpose=jcard ]]>

An example contents of a URL linked jCard JSON file is shown as follows:

An example SIP INVITE using the “cid” URI scheme is as follows.

From: Bob ;tag=1928301774> Call-ID: a84b4c76e66710 Call-Info: ;purpose=jcard;call-reason= \ "Rendezvous for Little Nellie" CSeq: 314159 INVITE Max-Forwards: 70 Date: Fri, 25 Sep 2015 19:12:25 GMT Contact: 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"]]] ]]>

In addition to the jCard value defined here, this specification also defines a generic 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 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 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:

;purpose=jcard; call-reason="For your ears only" ]]>

One can readily imagine a need for more structured call reason data that could be reliably processed automatically. Future versions of this specification may explore ways to provide a structured data object in place of a textual string to support things like internationalization or categories of reason that can be parsed by machines.

Beyond the definition of the specific properties or JSON arrays associated with each property. This specification defines a few rules above and beyond 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.

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 fail verification or not render 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 . 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 , .

There are a few 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 rendering of these images. 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 or 1-bit), also with potentially only grayscale or 1-bit black and white color displays. These exceptions are considered optional to support. 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. If the file is not to be rendered using the default 24-bit RGB pixel format, additionally the string can be extended to include bit depth and number of colors. That string should be formatted as “filename-HxW-bd-c”, where bd is the bit depth (e.g. 1, 8, 16) and c represents number of color channels which should either be 1 or 3. Note: 32-bit/RGBA color format is specifically not recommended for this document because transparency would not be clear how to render for display. 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.

Property cardinalities are indicated, for convenience, using the following notation and follow the guidance of jCard and vCard , which is based on ABNF (see , Section 3.6):

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 , 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.

The “fn” property has the intent of providing a formatted text corresponding to the name of the object the jCard represents. Reference Section 6.2.1. Value type: A single text value. Cardinality: 1*

The “n” property has the intent of providing the components of the name of the object the jCard represents. Reference Section 6.2.2. Value type: A single structured text value. Each component can have multiple values. Cardinality: *1

The “nickname” property has the intent of providing the text corresponding to the nickname of the object the jCard represents. Reference Section 6.2.3. Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *

The “photo” property has the intent of supplying an image or photograph information that annotates some aspect of the object the jCard represents. Reference 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: *

These properties are concerned with information related to the delivery addressing or label for the jCard object.

The “adr” property has the intent of providing the delivery address of the object the jCard represents. Reference Section 6.3.1. Value type: A single structured text value, separated by the SEMICOLON character (U+003B). Cardinality: *

These properties describe information about how to communicate with the object the jCard represents.

The “tel” property has the intent of providing the telephone number for telephony communication of the object the jCard represents. Reference 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 or required to match the “orig” claim in the PASSporT . 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 , but other schemes MAY be used. Cardinality: *

The “email” property has the intent of providing the electronic mail address for communication of the object the jCard represents. Reference Section 6.4.2. Value type: A single text value. Cardinality: *

The “lang” property has the intent of providing the language(s) that may be used for contacting of the object the jCard represents. Reference Section 6.4.4. Value type: A single language-tag value. Cardinality: *

These properties are concerned with information associated with geographical positions or regions associated with the object the jCard represents.

The “tz” property has the intent of providing the time zone of the object the jCard represents. Reference 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: *

The “geo” property has the intent of providing the global positioning of the object the jCard represents. Reference Section 6.5.2. Value type: A single URI. Cardinality: *

These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the jCard represents.

The “title” property has the intent of providing the position or job of the object the jCard represents. Reference Section 6.6.1. Value type: A single text value. Cardinality: *

The “role” property has the intent of providing the position or job of the object the jCard represents. Reference Section 6.6.2. Value type: A single text value. Cardinality: *

The “logo” property has the intent of specifying a graphic image of a logo associated with the object the jCard represents. Reference Section 6.6.3. Value type: A single URI. Cardinality: *

"] ]]>

The “org” property has the intent of specifying the organizational name and units of the object the jCard represents. Reference Section 6.6.2. Value type: A single structured text value consisting of components separated by the SEMICOLON character (U+003B). Cardinality: *

These properties are concerned with additional explanations, such as that related to informational notes or revisions specific to the jCard.

The “categories” property has the intent of specifying application category information about the object the jCard represents. Reference Section 6.7.1. Value type: One or more text values separated by a COMMA character (U+002C). Cardinality: *

The “note” property has the intent of specifying supplemental information or a comment about the object the jCard represents. Reference Section 6.7.2. Value type: A single text value. Cardinality: *

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 Section 6.7.5. Value type: A single URI. Cardinality: *

"] ]]>

The “uid” property has the intent of specifying a globally unique identifier corresponding to the object the jCard represents. Reference Section 6.7.6. Value type: A single URI value. It MAY also be reset to free-form text. Cardinality: *1

The “url” property has the intent of specifying a uniform resource locator associated with the object the jCard represents. Reference 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: *

The “version” property MUST be included and is intended to specify the version of the vCard specification used to format this vCard. Reference Section 6.7.9. Value type: A single text value. Cardinality: 1

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 Section 3.6 or new specifications.

We would like to thank David Hancock and other members of the STIR working group for helpful suggestions and comments for the creation of this draft.

[this RFC] defines the “jcard” token for use as a new token in the Call-Info header in the “Header Field Parameters and Parameter Values” registry defined by .

[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 . The parameter’s token is “call-reason” and it takes the value of a quoted string.

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 Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK] This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK] This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter 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 discussion and suggestions for improvements. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK] This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. 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 users. This framework is intended to extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network. The JSON element defined for this purpose, Rich Call Data (RCD), is an extensible object defined to either be used as part of STIR or with SIP Call-Info to include related information about calls that helps people decide whether to pick up the phone. This signing of the RCD information is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information between authoritative and non-authoritative parties authoring and signing the Rich Call Data for support of different usage and content policies. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.