idnits 2.17.1 draft-wendt-sipcore-callinfo-rcd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6919' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 476, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-stir-passport-rcd-04 ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Downref: Normative reference to an Informational RFC: RFC 3324 ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wendt 3 Internet-Draft Comcast 4 Intended status: Standards Track J. Peterson 5 Expires: May 7, 2020 Neustar Inc. 6 November 04, 2019 8 SIP Call-Info Parameters for Rich Call Data 9 draft-wendt-sipcore-callinfo-rcd-00 11 Abstract 13 This document describes a SIP Call-Info parameter defined to include 14 rich data associated with the identity of the calling party that can 15 be rendered to called party for providing more useful information 16 about the caller or the specific reason for the call. This includes 17 extended comprehensive information about the caller such as what a 18 jCard object can represent for describing the calling party. The 19 element defined for this purpose is intended to be extensible to 20 accommodate related information about calls that helps people decide 21 whether to pick up the phone and additionally with the use of jCard 22 be compatible with the STIR/PASSporT Rich Call Data framework. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4 62 5. Usage of jCard and property specific usage . . . . . . . . . 5 63 5.1. Identification properties . . . . . . . . . . . . . . . . 5 64 5.1.1. "fn" property . . . . . . . . . . . . . . . . . . . . 5 65 5.1.2. "n" property . . . . . . . . . . . . . . . . . . . . 6 66 5.1.3. "nickname" property . . . . . . . . . . . . . . . . . 6 67 5.1.4. "photo" property . . . . . . . . . . . . . . . . . . 6 68 5.2. Delivery Addressing Properties . . . . . . . . . . . . . 6 69 5.2.1. "adr" property . . . . . . . . . . . . . . . . . . . 6 70 5.3. Communications Properties . . . . . . . . . . . . . . . . 7 71 5.3.1. "tel" property . . . . . . . . . . . . . . . . . . . 7 72 5.3.2. "email" property . . . . . . . . . . . . . . . . . . 7 73 5.3.3. "lang" property . . . . . . . . . . . . . . . . . . . 7 74 5.4. Geographical Properties . . . . . . . . . . . . . . . . . 8 75 5.4.1. "tz" property . . . . . . . . . . . . . . . . . . . . 8 76 5.4.2. "geo" property . . . . . . . . . . . . . . . . . . . 8 77 5.5. Organizational Properties . . . . . . . . . . . . . . . . 8 78 5.5.1. "title" property . . . . . . . . . . . . . . . . . . 8 79 5.5.2. "role" property . . . . . . . . . . . . . . . . . . . 8 80 5.5.3. "logo" property . . . . . . . . . . . . . . . . . . . 8 81 5.5.4. "org" property . . . . . . . . . . . . . . . . . . . 9 82 5.5.5. "member" property . . . . . . . . . . . . . . . . . . 9 83 5.5.6. "related" property . . . . . . . . . . . . . . . . . 9 84 5.6. Explanatory Properties . . . . . . . . . . . . . . . . . 9 85 5.6.1. "catagories" property . . . . . . . . . . . . . . . . 9 86 5.6.2. "note" property . . . . . . . . . . . . . . . . . . . 9 87 5.6.3. "sound" property . . . . . . . . . . . . . . . . . . 9 88 5.6.4. "uid" property . . . . . . . . . . . . . . . . . . . 9 89 5.6.5. "url" property . . . . . . . . . . . . . . . . . . . 9 90 6. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 9 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 93 8.1. SIP Call-Info Header Field Purpose Token Request . . . . 10 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 97 10.2. Informative References . . . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 100 1. Introduction 102 Traditional telephone network signaling protocols have long supported 103 delivering a 'calling name' from the originating side, though in 104 practice, the terminating side is often left to derive a name from 105 the calling party number by consulting a local address book or an 106 external database. SIP similarly can carry a 'display-name' in the 107 From header field value from the originating to terminating side, 108 though it is an unsecured field that is not commonly trusted. The 109 same is true of information in the Call-Info header field. 111 To allow calling parties to initiate and called parties to receive a 112 more comprehensive deterministic and extensible rich call data for 113 incoming calls, we describe a new token for the SIP [RFC3261] Call- 114 Info header field and purpose parameter. For this document and 115 depending on the policies of the communications system, calling 116 parties could either be the end user device or an originating service 117 provider and called parties could also similarly be an end user 118 device or the terminating service provider acting on behalf of the 119 recipient of the call. 121 This specification, on it's own, inherently assumes that called party 122 user agent can trust the SIP network or the SIP provider to deliver 123 the correct rich call data (RCD) information. This may not always be 124 the case and thus, the entity inserting the Call-Info header field 125 and the UAS relying on it SHOULD be part of the same trust domain 126 [RFC3324]. Alternatively, and likely the recommended approach is the 127 entity inserting the call-info header should also sign the caller 128 information via STIR mechanisms [RFC8224] and specifically through 129 the [I-D.ietf-stir-passport-rcd] is likely either to be the caller 130 itself or the originating service provider using an authoritative 131 signature to authenticate the information is from the originator and 132 hasn't been tampered with in transmission. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Overview 144 The Call-Info header field, defined in [RFC3261] Section 20.9, 145 defines a purpose parameter currently with "info", "icon", and "card" 146 tokens. This document defines the purpose value of "jcard" which is 147 used to associate rich call data related to the identity of the 148 calling party in the form of a jCard [RFC7095]. While there is a 149 "card" token that is already defined with similar purpose, there are 150 two primary reasons for the definition and usage of jCard and the use 151 of JSON over the XML based vCard [RFC2426]. JSON has become the 152 default and optimally supported for transmission, parsing, and 153 manipulation of data on IP networks. jCard has also been defined in 154 [I-D.ietf-stir-passport-rcd] and has been adopted by PASSporT 155 [RFC8225] because of the usage of JSON Web Tokens (JWT) [RFC7519]. 157 4. "jcard" Call-Info Token 159 The use of the new Call-Info Token "jcard" is for the purpose of 160 supporting RCD associated with the identity of a calling party in a 161 SIP call [RFC3261] Section 20.9. The format of a Call-Info header 162 field when using the "jcard" is as follows. 164 The Call-Info header should include a URI where the resource pointed 165 to by the URI is a jCard JSON object defined in [RFC7095]. The URI 166 MUST define the use HTTPS or a transport that can validate the 167 integrity of the source of the resource as well as the transport 168 channel the resource is retrieved. 170 An example of a Call-Info header field is: 172 Call-Info: 174 An example jCard JSON file is shown as follows: 176 ["vcard", 177 [ 178 ["version", {}, "text", "4.0"], 179 ["fn", {}, "text", "James Bond"], 180 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 181 ["adr", {"type":"work"}, "text", 182 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 183 "USA"] 184 ], 185 ["email", {}, "text", "007@mi6-hq.com"], 186 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 187 "tel:+1-202-555-1000"], 188 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 189 ["bday", {}, "date", "19241116"] 190 ["logo", {}, "uri", 191 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 192 ] 193 ] 195 5. Usage of jCard and property specific usage 197 Beyond the definition of the specific properties or JSON arrays 198 associated with each property. This specification defines a few 199 rules above and beyond [RFC7095] specific to making sure there is a 200 mimimum level of supported properties that every implementation of 201 this specification should adhere to. This includes the support of 202 intepreting the value of this property and the ability to render in 203 some form appropriate to the display capabilities of the device. 204 This includes requirements specific to either textual displays and 205 graphics capable displays. 207 5.1. Identification properties 209 These types are used to capture information associated with the 210 identification and naming of the entity associated with the jCard. 212 5.1.1. "fn" property 214 The "fn" property MUST be supported with the intent of providing a 215 formatted text corresponding to the name of the object the jCard 216 represents. Reference [RFC6350] Section 6.2.1. 218 Example: 219 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 221 5.1.2. "n" property 223 The "n" property SHOULD be supported with the intent of providing the 224 components of the name of the object the jCard represents. Reference 225 [RFC6350] Section 6.2.2. 227 Example: 228 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 229 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 231 5.1.3. "nickname" property 233 The "nickname" property SHOULD be supported with the intent of 234 providing the text corresponding to the nickname of the object the 235 jCard represents. Reference [RFC6350] Section 6.2.3. 237 Example: 238 ["nickname", {}, "text", "Robbie"] 239 ["nickname", {}, "text", "Jim,Jimmie"] 240 ["nickname", {}, "text", "TYPE=work:Boss"] 242 5.1.4. "photo" property 244 The "photo" property MUST be supported with the intent of an image or 245 photograph information that annotates some aspect of the object the 246 jCard represents. Reference [RFC6350] Section 6.2.4. 248 In addition to the definition of jCard, and to promote 249 interoperability and proper formating and rendering of images, the 250 photo SHOULD correspond to a square image size of the sizes 128x128, 251 256x256, 512x512, or 1024x1024 pixels. 253 Example: 254 ["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"] 256 5.2. Delivery Addressing Properties 258 These properties are concerned with information related to the 259 delivery addressing or label for the jCard object. 261 5.2.1. "adr" property 263 The "adr" property MUST be supported with the intent of providing the 264 delivery address of the object the jCard represents. Reference 265 [RFC6350] Section 6.3.1. 267 Example: 268 ["adr", {"type":"work"}, "text", 269 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 270 "USA"] 272 5.3. Communications Properties 274 These properties describe information about how to communicate with 275 the object the jCard represents. 277 5.3.1. "tel" property 279 The "tel" property MUST be supported with the intent of providing the 280 telephone number for telephony communication of the object the jCard 281 represents. Reference [RFC6350] Section 6.4.1. 283 Relative to the SIP From header field this information may provide 284 alternate telephone number or other related telephone numbers for 285 other uses. 287 Example: 288 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 289 "tel:+1-202-555-1000"] 290 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 292 5.3.2. "email" property 294 The "email" property MUST be supported with the intent of providing 295 the electronic mail address for communication of the object the jCard 296 represents. Reference [RFC6350] Section 6.4.2. 298 Example: 299 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 300 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 302 5.3.3. "lang" property 304 The "lang" property MUST be supported with the intent of providing 305 the language(s) that may be used for contacting of the object the 306 jCard represents. Reference [RFC6350] Section 6.4.4. 308 Example: 309 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 310 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 311 ["lang", {"type":"home"}, "language-tag", "fr"] 313 5.4. Geographical Properties 315 These properties are concerned with information associated with 316 geographical positions or regions associated with the object the 317 jCard represents. 319 5.4.1. "tz" property 321 The "tz" property MUST be supported with the intent of providing the 322 time zone of the object the jCard represents. Reference [RFC6350] 323 Section 6.5.1. 325 Editor Note: recommendations of representing Time Zone don't seem to 326 be clear. TBD. 328 Example: 329 ["tz", {}, "text", "Raleigh/North America"] 331 5.4.2. "geo" property 333 The "geo" property MUST be supported with the intent of providing the 334 global positioning of the object the jCard represents. Reference 335 [RFC6350] Section 6.5.2. 337 Example: 338 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 340 5.5. Organizational Properties 342 These properties are concerned with information associated with 343 characteristics of the organization or organizational units of the 344 object that the jCard represents. 346 5.5.1. "title" property 348 text 350 5.5.2. "role" property 352 text 354 5.5.3. "logo" property 356 text 358 5.5.4. "org" property 360 text 362 5.5.5. "member" property 364 text 366 5.5.6. "related" property 368 text 370 5.6. Explanatory Properties 372 These properties are concerned with additional explanations, such as 373 that related to informational notes or revisions specific to the 374 jCard. 376 5.6.1. "catagories" property 378 ref 6.7.1 380 5.6.2. "note" property 382 ref 6.7.2 384 5.6.3. "sound" property 386 ref 6.7.5 (ringtone?) 388 5.6.4. "uid" property 390 ref 6.7.6 (origID like value?) 392 5.6.5. "url" property 394 ref 6.7.8 396 6. Extension of jCard 398 Part of the intent of the usage of jCard is that it has it's own 399 extensibility properties where new properties can be defined to relay 400 newly defined information related to a caller. This capability is 401 inherently supported as part of standard extensibility. However, 402 usage of those new properties should be published and registered 403 following [RFC7095] Section 3.6 or new specifications. 405 7. Acknowledgements 407 We would like to thank members of the STIR working group for helpful 408 suggestions and comments for the creation of this draft. 410 8. IANA Considerations 412 8.1. SIP Call-Info Header Field Purpose Token Request 414 [this RFC] defines the "jcard" token for use as a new token in the 415 Call-Info header in the "Header Field Parameters and Parameter 416 Values" registry defined by [RFC3968]. 418 +--------------+----------------+-------------------+------------+ 419 | Header Field | Parameter Name | Predefined Values | Reference | 420 +--------------+----------------+-------------------+------------+ 421 | Call-Info | jcard | No | [this RFC] | 422 +--------------+----------------+-------------------+------------+ 424 9. Security Considerations 426 Revealing information such as the name, location, and affiliation of 427 a person necessarily entails certain privacy risks. SIP and Call- 428 Info has no particular confidentiality requirement, as the 429 information sent in SIP is in the clear anyway. Transport-level 430 security can be used to hide information from eavesdroppers, and the 431 same confidentiality mechanisms would protect any Call-Info or jCard 432 information carried or referred to in SIP. 434 10. References 436 10.1. Normative References 438 [I-D.ietf-stir-passport-rcd] 439 Peterson, J. and C. Wendt, "PASSporT Extension for Rich 440 Call Data", draft-ietf-stir-passport-rcd-04 (work in 441 progress), July 2019. 443 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 444 RFC 2426, DOI 10.17487/RFC2426, September 1998, 445 . 447 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 448 A., Peterson, J., Sparks, R., Handley, M., and E. 449 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 450 DOI 10.17487/RFC3261, June 2002, 451 . 453 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 454 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 455 . 457 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 458 (IANA) Header Field Parameter Registry for the Session 459 Initiation Protocol (SIP)", BCP 98, RFC 3968, 460 DOI 10.17487/RFC3968, December 2004, 461 . 463 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 464 DOI 10.17487/RFC6350, August 2011, 465 . 467 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 468 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 469 DOI 10.17487/RFC6919, April 2013, 470 . 472 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 473 DOI 10.17487/RFC7095, January 2014, 474 . 476 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 477 Telephone Identity Problem Statement and Requirements", 478 RFC 7340, DOI 10.17487/RFC7340, September 2014, 479 . 481 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 482 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 483 . 485 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 486 "Authenticated Identity Management in the Session 487 Initiation Protocol (SIP)", RFC 8224, 488 DOI 10.17487/RFC8224, February 2018, 489 . 491 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 492 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 493 . 495 10.2. Informative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 Authors' Addresses 508 Chris Wendt 509 Comcast 510 Comcast Technology Center 511 Philadelphia, PA 19103 512 USA 514 Email: chris-ietf@chriswendt.net 516 Jon Peterson 517 Neustar Inc. 518 1800 Sutter St Suite 570 519 Concord, CA 94520 520 US 522 Email: jon.peterson@neustar.biz