idnits 2.17.1 draft-wendt-sipcore-callinfo-rcd-03.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 6 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 (July 13, 2020) is 1383 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 643, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 652, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-stir-passport-rcd-06 ** 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: January 14, 2021 Neustar Inc. 6 July 13, 2020 8 SIP Call-Info Parameters for Rich Call Data 9 draft-wendt-sipcore-callinfo-rcd-03 11 Abstract 13 This document describes a SIP Call-Info header field usage defined to 14 include rich data associated with the identity of the calling party 15 that can be rendered to called party for providing more useful 16 information about the caller or the specific reason for the call. 17 This includes extended comprehensive information about the caller 18 such as what a jCard object can represent for describing the calling 19 party or other call specific information such as describing the 20 reason or intent of the call. The elements defined for this purpose 21 are intended to be extensible to accommodate related information 22 about calls that helps people decide whether to pick up the phone and 23 additionally, with the use of jCard and other elements, to be 24 compatible with the STIR/PASSporT Rich Call Data framework. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4 64 5. 'call-reason' Call-Info Parameter . . . . . . . . . . . . . . 6 65 6. Usage of jCard and property specific usage . . . . . . . . . 7 66 6.1. Identification properties . . . . . . . . . . . . . . . . 7 67 6.1.1. "fn" property . . . . . . . . . . . . . . . . . . . . 7 68 6.1.2. "n" property . . . . . . . . . . . . . . . . . . . . 8 69 6.1.3. "nickname" property . . . . . . . . . . . . . . . . . 8 70 6.1.4. "photo" property . . . . . . . . . . . . . . . . . . 8 71 6.2. Delivery Addressing Properties . . . . . . . . . . . . . 8 72 6.2.1. "adr" property . . . . . . . . . . . . . . . . . . . 8 73 6.3. Communications Properties . . . . . . . . . . . . . . . . 9 74 6.3.1. "tel" property . . . . . . . . . . . . . . . . . . . 9 75 6.3.2. "email" property . . . . . . . . . . . . . . . . . . 9 76 6.3.3. "lang" property . . . . . . . . . . . . . . . . . . . 9 77 6.4. Geographical Properties . . . . . . . . . . . . . . . . . 10 78 6.4.1. "tz" property . . . . . . . . . . . . . . . . . . . . 10 79 6.4.2. "geo" property . . . . . . . . . . . . . . . . . . . 10 80 6.5. Organizational Properties . . . . . . . . . . . . . . . . 10 81 6.5.1. "title" property . . . . . . . . . . . . . . . . . . 10 82 6.5.2. "role" property . . . . . . . . . . . . . . . . . . . 10 83 6.5.3. "logo" property . . . . . . . . . . . . . . . . . . . 11 84 6.5.4. "org" property . . . . . . . . . . . . . . . . . . . 11 85 6.6. Explanatory Properties . . . . . . . . . . . . . . . . . 11 86 6.6.1. "catagories" property . . . . . . . . . . . . . . . . 11 87 6.6.2. "note" property . . . . . . . . . . . . . . . . . . . 11 88 6.6.3. "sound" property . . . . . . . . . . . . . . . . . . 12 89 6.6.4. "uid" property . . . . . . . . . . . . . . . . . . . 12 90 6.6.5. "url" property . . . . . . . . . . . . . . . . . . . 12 91 6.6.6. "version" property . . . . . . . . . . . . . . . . . 12 92 7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 13 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 9.1. SIP Call-Info Header Field Purpose Token Request . . . . 13 96 9.2. SIP Call-Info Header Field Purpose Token Request . . . . 13 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 11.2. Informative References . . . . . . . . . . . . . . . . . 15 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 103 1. Introduction 105 Traditional telephone network signaling protocols have long supported 106 delivering a 'calling name' from the originating side, though in 107 practice, the terminating side is often left to derive a name from 108 the calling party number by consulting a local address book or an 109 external database. SIP similarly can carry a 'display-name' in the 110 From header field value from the originating to terminating side, 111 though it is an unsecured field that is not commonly trusted. The 112 same is true of information in the Call-Info header field. 114 To allow calling parties to initiate, and called parties to receive, 115 a more comprehensive, deterministic, and extensible rich call data 116 for incoming calls, we describe new tokens for the SIP [RFC3261] 117 Call-Info header field and a corresponding "purpose" parameter. We 118 also define a new parameter of Call-Info designed for carrying a 119 "reason" value. For this document, depending on the policies of the 120 communications system, calling parties could either be the end user 121 device or an originating service provider, and called parties could 122 also similarly be an end user device or the terminating service 123 provider acting on behalf of the recipient of the call. 125 Used on its own, this specification assumes that called party user 126 agent can trust the SIP network or the SIP provider to deliver the 127 correct rich call data (RCD) information. This may not always be the 128 case and thus, the entity inserting the Call-Info header field and 129 the UAS relying on it SHOULD be part of the same trust domain 130 [RFC3324]. Alternatively, and likely the recommended approach, is 131 that the entity inserting the call-info header should also sign the 132 caller information via STIR mechanisms [RFC8224] and specifically 133 through the [I-D.ietf-stir-passport-rcd]. This STIR signature would 134 likely be provided by the caller itself or the originating service 135 provider using an authoritative signature to authenticate the 136 information is from the originator and hasn't been tampered with in 137 transmission. 139 [RFC7852] provides a means of carrying additional data about callers 140 for the purposes of emergency services (especially its Section 4.4 141 "Owner/Subscriber" information). This specification provides an 142 overlapping functionality for non-emergency cases. Rather than 143 overloading its "EmergencyCallData" Call-Info "purpose" parameter 144 value, this document defines a separate "purpose" parameter for the 145 more generic delivery of information via jCard [RFC7095]. This 146 document borrows from [RFC7852] the capability to carry a data 147 structure as a body, through the use of the "cid" URI scheme 148 [RFC2392]. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119] [RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 3. Overview 160 The Call-Info header field, defined in [RFC3261] Section 20.9, 161 defines a purpose parameter currently with "info", "icon", and "card" 162 tokens. This document defines one new purpose value and one new 163 generic parameter for Call-Info. 165 The value "jcard" is to be used to associate rich call data related 166 to the identity of the calling party in the form of a jCard 167 [RFC7095]. While there is a "card" token that is already defined 168 with similar purpose, there are two primary reasons for the 169 definition and usage of jCard and the use of JSON over the XML based 170 vCard [RFC2426]. First, JSON has become the default and optimally 171 supported for transmission, parsing, and manipulation of data on IP 172 networks. Second, jCard has also been defined in 173 [I-D.ietf-stir-passport-rcd] and has been adopted by PASSporT 174 [RFC8225] because of the usage of JSON Web Tokens (JWT) [RFC7519]. 176 A generic parameter for "call-reason" is to be used to provide a 177 string or other object that is used to convey the intent or reason 178 the caller is calling to help the called party understand better the 179 context of the call and why they may want to answer the call. 181 4. "jcard" Call-Info Token 183 The use of the new Call-Info Token "jcard" is for the purpose of 184 supporting RCD associated with the identity of a calling party in a 185 SIP call [RFC3261] Section 20.9. The format of a Call-Info header 186 field when using the "jcard" is as follows. 188 The Call-Info header should include a URI where the resource pointed 189 to by the URI is a jCard JSON object defined in [RFC7095]. This MAY 190 be carried in the body of the SIP request bearing this Call-Info via 191 the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST define 192 the use HTTPS or a transport that can validate the integrity of the 193 source of the resource as well as the transport channel the resource 194 is retrieved. 196 An example of a Call-Info header field is: 198 Call-Info: 200 An example jCard JSON file is shown as follows: 202 ["vcard", 203 [ 204 ["version", {}, "text", "4.0"], 205 ["fn", {}, "text", "James Bond"], 206 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 207 ["adr", {"type":"work"}, "text", 208 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 209 "USA"] 210 ], 211 ["email", {}, "text", "007@mi6-hq.com"], 212 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 213 "tel:+1-202-555-1000"], 214 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 215 ["bday", {}, "date", "19241116"] 216 ["logo", {}, "uri", 217 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 218 ] 219 ] 221 An example SIP INVITE using the "cid" URI scheme is as follows. 223 INVITE sip:alice@example.com SIP/2.0 224 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 225 To: Alice 226 From: Bob ;tag=1928301774> 227 Call-ID: a84b4c76e66710 228 Call-Info: ;purpose=jcard;call-reason= \ 229 "For your ears only" 230 CSeq: 314159 INVITE 231 Max-Forwards: 70 232 Date: Fri, 25 Sep 2015 19:12:25 GMT 233 Contact: 234 Content-Type: multipart/mixed; boundary=boundary1 235 Content-Length: ... 237 --boundary1 239 Content-Type: application/sdp 241 v=0 242 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 243 s=Session SDP 244 c=IN IP4 pc33.atlanta.example.com 245 t=0 0 246 m=audio 49172 RTP/AVP 0 247 a=rtpmap:0 PCMU/8000 249 --boundary1 251 Content-Type: application/vcard+json 252 Content-ID: <12155551212@example.com> 254 ["vcard",[["version",{},"text","4.0"],["fn",{},"text","James Bond" 255 ],["n",{},"text",["Bond","James","","","Mr."]],["adr",{"type": 256 "work"},"text",["","","3100 Massachusetts Avenue NW","Washington", 257 "DC","20008","USA"]],["email",{},"text","007@mi6-hq.com"],["tel", 258 {"type":["voice","text","cell"],"pref":"1"},"uri","tel:+1-202-555-1000"], 259 ["tel",{"type":["fax"]},"uri","tel:+1-202-555-1001"],["bday",{},"date", 260 "19241116"]["logo",{},"uri","https://upload.wikimedia.org/wikipedia/en 261 /c/c5/Fleming007impression.jpg"]]] 263 5. 'call-reason' Call-Info Parameter 265 In addition to the jCard value defined here, this specification also 266 defines a generic parameter of the Call-Info header called "call- 267 reason". The "call-reason" parameter is intended to convey a short 268 textual message suitable for display to an end user during call 269 alerting. As a general guideline, this message SHOULD be no longer 270 than 160 characters; displays that support this specification may be 271 forced to truncate messages that cannot fit onto a screen. This 272 message conveys the caller's intention in contacting the callee. It 273 is an optional parameter, and the sender of a SIP request cannot 274 guarantee that its display will be supported by the terminating 275 endpoint. The manner in which this reason is set by the caller is 276 outside the scope of this specification. 278 One alternative approach would be to use the baseline [RFC3261] 279 Subject header field value to convey the reason for the call. 280 Because the Subject header has seen little historical use in SIP 281 implementations, however, and its specification describes its 282 potential use in filtering, it seems more prudent to define a new 283 means of carrying a call reason indication. 285 An example of a Call-Info header field value with the "call-reason" 286 parameter follows: 288 Call-Info: ;call-reason="For your ears only" 290 One can readily imagine a need for more structured call reason data 291 that could be reliably processed automatically. Future versions of 292 this specification may explore ways to provide a structured data 293 object in place of a textual string to support things like 294 internationalization or categories of reason that can be parsed by 295 machines. 297 6. Usage of jCard and property specific usage 299 Beyond the definition of the specific properties or JSON arrays 300 associated with each property. This specification defines a few 301 rules above and beyond [RFC7095] specific to making sure there is a 302 mimimum level of supported properties that every implementation of 303 this specification should adhere to. This includes the support of 304 intepreting the value of this property and the ability to render in 305 some form appropriate to the display capabilities of the device. 306 This includes requirements specific to either textual displays and 307 graphics capable displays. 309 6.1. Identification properties 311 These types are used to capture information associated with the 312 identification and naming of the entity associated with the jCard. 314 6.1.1. "fn" property 316 The "fn" property MUST be supported with the intent of providing a 317 formatted text corresponding to the name of the object the jCard 318 represents. Reference [RFC6350] Section 6.2.1. 320 Example: 321 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 323 6.1.2. "n" property 325 The "n" property SHOULD be supported with the intent of providing the 326 components of the name of the object the jCard represents. Reference 327 [RFC6350] Section 6.2.2. 329 Example: 330 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 331 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 333 6.1.3. "nickname" property 335 The "nickname" property SHOULD be supported with the intent of 336 providing the text corresponding to the nickname of the object the 337 jCard represents. Reference [RFC6350] Section 6.2.3. 339 Example: 340 ["nickname", {}, "text", "Robbie"] 341 ["nickname", {}, "text", "Jim,Jimmie"] 342 ["nickname", {}, "text", "TYPE=work:Boss"] 344 6.1.4. "photo" property 346 The "photo" property MUST be supported with the intent of an image or 347 photograph information that annotates some aspect of the object the 348 jCard represents. Reference [RFC6350] Section 6.2.4. 350 In addition to the definition of jCard, and to promote 351 interoperability and proper formatting and rendering of images, the 352 photo SHOULD correspond to a square image size of the sizes 128x128, 353 256x256, 512x512, or 1024x1024 pixels. 355 Example: 356 ["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"] 358 6.2. Delivery Addressing Properties 360 These properties are concerned with information related to the 361 delivery addressing or label for the jCard object. 363 6.2.1. "adr" property 365 The "adr" property MUST be supported with the intent of providing the 366 delivery address of the object the jCard represents. Reference 367 [RFC6350] Section 6.3.1. 369 Example: 370 ["adr", {"type":"work"}, "text", 371 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 372 "USA"] 374 6.3. Communications Properties 376 These properties describe information about how to communicate with 377 the object the jCard represents. 379 6.3.1. "tel" property 381 The "tel" property MUST be supported with the intent of providing the 382 telephone number for telephony communication of the object the jCard 383 represents. Reference [RFC6350] Section 6.4.1. 385 Relative to the SIP From header field this information may provide 386 alternate telephone number or other related telephone numbers for 387 other uses. 389 Example: 390 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 391 "tel:+1-202-555-1000"] 392 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 394 6.3.2. "email" property 396 The "email" property MUST be supported with the intent of providing 397 the electronic mail address for communication of the object the jCard 398 represents. Reference [RFC6350] Section 6.4.2. 400 Example: 401 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 402 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 404 6.3.3. "lang" property 406 The "lang" property MUST be supported with the intent of providing 407 the language(s) that may be used for contacting of the object the 408 jCard represents. Reference [RFC6350] Section 6.4.4. 410 Example: 411 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 412 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 413 ["lang", {"type":"home"}, "language-tag", "fr"] 415 6.4. Geographical Properties 417 These properties are concerned with information associated with 418 geographical positions or regions associated with the object the 419 jCard represents. 421 6.4.1. "tz" property 423 The "tz" property MUST be supported with the intent of providing the 424 time zone of the object the jCard represents. Reference [RFC6350] 425 Section 6.5.1. 427 Note: Seems the up-to-date reference for where time-zone names are 428 maintained is currently at this web address, https://www.iana.org/ 429 time-zones. 431 Example: 432 ["tz", {}, "text", "Raleigh/North America"] 434 6.4.2. "geo" property 436 The "geo" property MUST be supported with the intent of providing the 437 global positioning of the object the jCard represents. Reference 438 [RFC6350] Section 6.5.2. 440 Example: 441 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 443 6.5. Organizational Properties 445 These properties are concerned with information associated with 446 characteristics of the organization or organizational units of the 447 object that the jCard represents. 449 6.5.1. "title" property 451 The "title" property MUST be supported with the intent of providing 452 the position or job of the object the jCard represents. Reference 453 [RFC6350] Section 6.6.1. 455 Example: 456 ["title", {}, "text", "Research Scientist"] 458 6.5.2. "role" property 460 The "role" property MUST be supported with the intent of providing 461 the position or job of the object the jCard represents. Reference 462 [RFC6350] Section 6.6.2. 464 Example: 465 ["role", {}, "text", "Project Leader"] 467 6.5.3. "logo" property 469 The "logo" property MUST be supported with the intent of specifying a 470 graphic image of a logo associated with the object the jCard 471 represents. Reference [RFC6350] Section 6.6.3. 473 Example: 474 ["logo", {}, "uri", "http://www.example.com/pub/logos/abccorp.jpg"] 476 ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC 477 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 478 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 479 <...the remainder of base64-encoded data...>"] 481 6.5.4. "org" property 483 The "org" property MUST be supported with the intent of specifying 484 the organizational name and units of the object the jCard represents. 485 Reference [RFC6350] Section 6.6.2. 487 Example: 488 ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"] 490 6.6. Explanatory Properties 492 These properties are concerned with additional explanations, such as 493 that related to informational notes or revisions specific to the 494 jCard. 496 6.6.1. "catagories" property 498 The "catagories" property MUST be supported with the intent of 499 specifying application category information the object the jCard 500 represents. Reference [RFC6350] Section 6.7.1. 502 Example: 503 ["catagories", {}, "text", "TRAVEL AGENT"] 505 ["catagories", {}, "text", "INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY"] 507 6.6.2. "note" property 509 The "note" property MUST be supported with the intent of specifying 510 supplemental information or a comment the object the jCard 511 represents. Reference [RFC6350] Section 6.7.2. 513 Example: 514 ["note", {}, "text", "This fax number is operational 0800 to 1715 515 EST\, Mon-Fri."] 517 6.6.3. "sound" property 519 The "sound" property MUST be supported with the intent of specifying 520 a digital sound content information that annotates some aspect with 521 the object the jCard represents. This property is often used to 522 specify the proper pronunciation of the name property value of the 523 jCard. Reference [RFC6350] Section 6.7.5. 525 Example: 526 ["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"] 528 ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE 529 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 530 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 531 <...the remainder of base64-encoded data...>"] 533 6.6.4. "uid" property 535 The "uid" property MUST be supported with the intent of specifying a 536 globally unique identifier corresponding to the object the jCard 537 represents. Reference [RFC6350] Section 6.7.6. 539 Example: 540 ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"] 542 6.6.5. "url" property 544 The "url" property MUST be supported with the intent of specifying a 545 uniform resource locator associated to the object the jCard 546 represents. Reference [RFC6350] Section 6.7.8. 548 Example: 549 ["url", {}, "uri", "https://example.org/restaurant.french/~chezchic.html"] 551 6.6.6. "version" property 553 The "version" property MUST be included and is intended to specify 554 version of the vCard specification used to format this vCard. 555 Reference [RFC6350] Section 6.7.9. 557 Example: 558 ["version", {}, "text", "4.0"] 560 7. Extension of jCard 562 Part of the intent of the usage of jCard is that it has it's own 563 extensibility properties where new properties can be defined to relay 564 newly defined information related to a caller. This capability is 565 inherently supported as part of standard extensibility. However, 566 usage of those new properties should be published and registered 567 following [RFC7095] Section 3.6 or new specifications. 569 8. Acknowledgements 571 We would like to thank David Hancock and other members of the STIR 572 working group for helpful suggestions and comments for the creation 573 of this draft. 575 9. IANA Considerations 577 9.1. SIP Call-Info Header Field Purpose Token Request 579 [this RFC] defines the "jcard" token for use as a new token in the 580 Call-Info header in the "Header Field Parameters and Parameter 581 Values" registry defined by [RFC3968]. 583 +--------------+----------------+-------------------+------------+ 584 | Header Field | Parameter Name | Predefined Values | Reference | 585 +--------------+----------------+-------------------+------------+ 586 | Call-Info | jcard | No | [this RFC] | 587 +--------------+----------------+-------------------+------------+ 589 9.2. SIP Call-Info Header Field Purpose Token Request 591 [this RFC] defines the "call-reason" generic parameter for use as a 592 new parameter in the Call-Info header in the "Header Field Parameters 593 and Parameter Values" registry defined by [RFC3968]. The parameter's 594 token is "call-reason" and it takes the value of a quoted string. 596 10. Security Considerations 598 Revealing information such as the name, location, and affiliation of 599 a person necessarily entails certain privacy risks. SIP and Call- 600 Info has no particular confidentiality requirement, as the 601 information sent in SIP is in the clear anyway. Transport-level 602 security can be used to hide information from eavesdroppers, and the 603 same confidentiality mechanisms would protect any Call-Info or jCard 604 information carried or referred to in SIP. 606 11. References 608 11.1. Normative References 610 [I-D.ietf-stir-passport-rcd] 611 Peterson, J. and C. Wendt, "PASSporT Extension for Rich 612 Call Data", draft-ietf-stir-passport-rcd-06 (work in 613 progress), March 2020. 615 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 616 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 617 . 619 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 620 RFC 2426, DOI 10.17487/RFC2426, September 1998, 621 . 623 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 624 A., Peterson, J., Sparks, R., Handley, M., and E. 625 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 626 DOI 10.17487/RFC3261, June 2002, 627 . 629 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 630 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 631 . 633 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 634 (IANA) Header Field Parameter Registry for the Session 635 Initiation Protocol (SIP)", BCP 98, RFC 3968, 636 DOI 10.17487/RFC3968, December 2004, 637 . 639 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 640 DOI 10.17487/RFC6350, August 2011, 641 . 643 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 644 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 645 DOI 10.17487/RFC6919, April 2013, 646 . 648 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 649 DOI 10.17487/RFC7095, January 2014, 650 . 652 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 653 Telephone Identity Problem Statement and Requirements", 654 RFC 7340, DOI 10.17487/RFC7340, September 2014, 655 . 657 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 658 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 659 . 661 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 662 J. Winterbottom, "Additional Data Related to an Emergency 663 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 664 . 666 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 667 "Authenticated Identity Management in the Session 668 Initiation Protocol (SIP)", RFC 8224, 669 DOI 10.17487/RFC8224, February 2018, 670 . 672 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 673 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 674 . 676 11.2. Informative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 684 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 685 May 2017, . 687 Authors' Addresses 689 Chris Wendt 690 Comcast 691 Comcast Technology Center 692 Philadelphia, PA 19103 693 USA 695 Email: chris-ietf@chriswendt.net 696 Jon Peterson 697 Neustar Inc. 698 1800 Sutter St Suite 570 699 Concord, CA 94520 700 US 702 Email: jon.peterson@neustar.biz