Network Working Group C. Wendt Internet-Draft Comcast Intended status: Standards Track J. Peterson Expires: May 7, 2020 Neustar Inc. November 04, 2019 SIP Call-Info Parameters for Rich Call Data draft-wendt-sipcore-callinfo-rcd-00 Abstract This document describes a SIP Call-Info parameter defined to include rich data associated with the identity of the calling party that can be rendered to 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. The element defined for this purpose is 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 be compatible 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 May 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Wendt & Peterson Expires May 7, 2020 [Page 1] Internet-Draft Call-Info Rich Call Data November 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4 5. Usage of jCard and property specific usage . . . . . . . . . 5 5.1. Identification properties . . . . . . . . . . . . . . . . 5 5.1.1. "fn" property . . . . . . . . . . . . . . . . . . . . 5 5.1.2. "n" property . . . . . . . . . . . . . . . . . . . . 6 5.1.3. "nickname" property . . . . . . . . . . . . . . . . . 6 5.1.4. "photo" property . . . . . . . . . . . . . . . . . . 6 5.2. Delivery Addressing Properties . . . . . . . . . . . . . 6 5.2.1. "adr" property . . . . . . . . . . . . . . . . . . . 6 5.3. Communications Properties . . . . . . . . . . . . . . . . 7 5.3.1. "tel" property . . . . . . . . . . . . . . . . . . . 7 5.3.2. "email" property . . . . . . . . . . . . . . . . . . 7 5.3.3. "lang" property . . . . . . . . . . . . . . . . . . . 7 5.4. Geographical Properties . . . . . . . . . . . . . . . . . 8 5.4.1. "tz" property . . . . . . . . . . . . . . . . . . . . 8 5.4.2. "geo" property . . . . . . . . . . . . . . . . . . . 8 5.5. Organizational Properties . . . . . . . . . . . . . . . . 8 5.5.1. "title" property . . . . . . . . . . . . . . . . . . 8 5.5.2. "role" property . . . . . . . . . . . . . . . . . . . 8 5.5.3. "logo" property . . . . . . . . . . . . . . . . . . . 8 5.5.4. "org" property . . . . . . . . . . . . . . . . . . . 9 5.5.5. "member" property . . . . . . . . . . . . . . . . . . 9 5.5.6. "related" property . . . . . . . . . . . . . . . . . 9 5.6. Explanatory Properties . . . . . . . . . . . . . . . . . 9 5.6.1. "catagories" property . . . . . . . . . . . . . . . . 9 5.6.2. "note" property . . . . . . . . . . . . . . . . . . . 9 5.6.3. "sound" property . . . . . . . . . . . . . . . . . . 9 5.6.4. "uid" property . . . . . . . . . . . . . . . . . . . 9 5.6.5. "url" property . . . . . . . . . . . . . . . . . . . 9 6. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8.1. SIP Call-Info Header Field Purpose Token Request . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 Wendt & Peterson Expires May 7, 2020 [Page 2] Internet-Draft Call-Info Rich Call Data November 2019 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 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 a new token for the SIP [RFC3261] Call- Info header field and purpose parameter. For this document and 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. This specification, on it's own, inherently assumes that 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 [RFC3324]. Alternatively, and likely the recommended approach is the entity inserting the call-info header should also sign the caller information via STIR mechanisms [RFC8224] and specifically through the [I-D.ietf-stir-passport-rcd] is likely either to be 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. 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. Wendt & Peterson Expires May 7, 2020 [Page 3] Internet-Draft Call-Info Rich Call Data November 2019 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 the purpose value of "jcard" which 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]. JSON has become the default and optimally supported for transmission, parsing, and manipulation of data on IP networks. 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]. 4. "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 should include a URI where the resource pointed to by the URI is a jCard JSON object defined in [RFC7095]. 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 the resource is retrieved. An example of a Call-Info header field is: Call-Info: An example jCard JSON file is shown as follows: Wendt & Peterson Expires May 7, 2020 [Page 4] Internet-Draft Call-Info Rich Call Data November 2019 ["vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "James Bond"], ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], ["adr", {"type":"work"}, "text", ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", "USA"] ], ["email", {}, "text", "007@mi6-hq.com"], ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", "tel:+1-202-555-1000"], ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], ["bday", {}, "date", "19241116"] ["logo", {}, "uri", "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] ] ] 5. 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 making sure there is a mimimum level of supported properties that every implementation of this specification should adhere to. This includes the support of intepreting the value of this property and the ability to render in some form appropriate to the display capabilities of the device. This includes requirements specific to either textual displays and graphics capable displays. 5.1. Identification properties These types are used to capture information associated with the identification and naming of the entity associated with the jCard. 5.1.1. "fn" property The "fn" property MUST be supported with the intent of providing a formatted text corresponding to the name of the object the jCard represents. Reference [RFC6350] Section 6.2.1. Example: ["fn", {}, "text", "Mr. John Q. Public\, Esq."] Wendt & Peterson Expires May 7, 2020 [Page 5] Internet-Draft Call-Info Rich Call Data November 2019 5.1.2. "n" property The "n" property SHOULD be supported with the intent of providing the components of the name of the object the jCard represents. Reference [RFC6350] Section 6.2.2. Example: ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 5.1.3. "nickname" property The "nickname" property SHOULD be supported with the intent of providing the text corresponding to the nickname of the object the jCard represents. Reference [RFC6350] Section 6.2.3. Example: ["nickname", {}, "text", "Robbie"] ["nickname", {}, "text", "Jim,Jimmie"] ["nickname", {}, "text", "TYPE=work:Boss"] 5.1.4. "photo" property The "photo" property MUST be supported with the intent of 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 formating and rendering of images, the photo SHOULD correspond to a square image size of the sizes 128x128, 256x256, 512x512, or 1024x1024 pixels. Example: ["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"] 5.2. Delivery Addressing Properties These properties are concerned with information related to the delivery addressing or label for the jCard object. 5.2.1. "adr" property The "adr" property MUST be supported with the intent of providing the delivery address of the object the jCard represents. Reference [RFC6350] Section 6.3.1. Wendt & Peterson Expires May 7, 2020 [Page 6] Internet-Draft Call-Info Rich Call Data November 2019 Example: ["adr", {"type":"work"}, "text", ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", "USA"] 5.3. Communications Properties These properties describe information about how to communicate with the object the jCard represents. 5.3.1. "tel" property The "tel" property MUST be supported with 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 this information may provide alternate telephone number or other related telephone numbers for other uses. Example: ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", "tel:+1-202-555-1000"] ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 5.3.2. "email" property The "email" property MUST be supported with the intent of providing the electronic mail address for communication of the object the jCard represents. Reference [RFC6350] Section 6.4.2. Example: ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 5.3.3. "lang" property The "lang" property MUST be supported with 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. Example: ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] ["lang", {"type":"home"}, "language-tag", "fr"] Wendt & Peterson Expires May 7, 2020 [Page 7] Internet-Draft Call-Info Rich Call Data November 2019 5.4. Geographical Properties These properties are concerned with information associated with geographical positions or regions associated with the object the jCard represents. 5.4.1. "tz" property The "tz" property MUST be supported with the intent of providing the time zone of the object the jCard represents. Reference [RFC6350] Section 6.5.1. Editor Note: recommendations of representing Time Zone don't seem to be clear. TBD. Example: ["tz", {}, "text", "Raleigh/North America"] 5.4.2. "geo" property The "geo" property MUST be supported with the intent of providing the global positioning of the object the jCard represents. Reference [RFC6350] Section 6.5.2. Example: ["geo", {}, "uri", "geo:37.386013,-122.082932"] 5.5. Organizational Properties These properties are concerned with information associated with characteristics of the organization or organizational units of the object that the jCard represents. 5.5.1. "title" property text 5.5.2. "role" property text 5.5.3. "logo" property text Wendt & Peterson Expires May 7, 2020 [Page 8] Internet-Draft Call-Info Rich Call Data November 2019 5.5.4. "org" property text 5.5.5. "member" property text 5.5.6. "related" property text 5.6. Explanatory Properties These properties are concerned with additional explanations, such as that related to informational notes or revisions specific to the jCard. 5.6.1. "catagories" property ref 6.7.1 5.6.2. "note" property ref 6.7.2 5.6.3. "sound" property ref 6.7.5 (ringtone?) 5.6.4. "uid" property ref 6.7.6 (origID like value?) 5.6.5. "url" property ref 6.7.8 6. Extension of jCard Part of the intent of the usage of jCard is that it has it's 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 May 7, 2020 [Page 9] Internet-Draft Call-Info Rich Call Data November 2019 7. Acknowledgements We would like to thank members of the STIR working group for helpful suggestions and comments for the creation of this draft. 8. IANA Considerations 8.1. SIP Call-Info Header Field Purpose Token Request [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 [RFC3968]. +--------------+----------------+-------------------+------------+ | Header Field | Parameter Name | Predefined Values | Reference | +--------------+----------------+-------------------+------------+ | Call-Info | jcard | No | [this RFC] | +--------------+----------------+-------------------+------------+ 9. 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. 10. References 10.1. Normative References [I-D.ietf-stir-passport-rcd] Peterson, J. and C. Wendt, "PASSporT Extension for Rich Call Data", draft-ietf-stir-passport-rcd-04 (work in progress), July 2019. [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, DOI 10.17487/RFC2426, September 1998, . [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, . Wendt & Peterson Expires May 7, 2020 [Page 10] Internet-Draft Call-Info Rich Call Data November 2019 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, . [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, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, . [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . 10.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wendt & Peterson Expires May 7, 2020 [Page 11] Internet-Draft Call-Info Rich Call Data November 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Chris Wendt Comcast Comcast Technology Center Philadelphia, PA 19103 USA Email: chris-ietf@chriswendt.net Jon Peterson Neustar Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@neustar.biz Wendt & Peterson Expires May 7, 2020 [Page 12]