idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 [I-D.ietf-stir-passport-rcd]. It is the belief of the authors that there isn't a scenario that deeper URI references would be required or even supported by the current set of properties for the typical use of jCard properties, but because jCard is extensible, this rule is set to restrict further extension without the proper consideration of security and integrity properties of both Call-Info usage as well as the Rich Call Data and STIR signing of the data [I-D.ietf-stir-passport-rcd], [RFC8224]. -- The document date (25 October 2021) is 907 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) == Outdated reference: A later version (-26) exists of draft-ietf-stir-passport-rcd-13 ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Downref: Normative reference to an Informational RFC: RFC 3324 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 3 errors (**), 0 flaws (~~), 3 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: 28 April 2022 Neustar Inc. 6 25 October 2021 8 SIP Call-Info Parameters for Rich Call Data 9 draft-ietf-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 a 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 28 April 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4 63 5. "call-reason" Call-Info Parameter . . . . . . . . . . . . . . 6 64 6. Usage of jCard and property specific usage . . . . . . . . . 7 65 6.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 7 66 6.2. Usage of multimedia data in jCard . . . . . . . . . . . . 8 67 6.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.4. Identification properties . . . . . . . . . . . . . . . . 9 69 6.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 9 70 6.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 10 71 6.4.3. "nickname" property . . . . . . . . . . . . . . . . . 10 72 6.4.4. "photo" property . . . . . . . . . . . . . . . . . . 10 73 6.5. Delivery Addressing Properties . . . . . . . . . . . . . 11 74 6.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 11 75 6.6. Communications Properties . . . . . . . . . . . . . . . . 11 76 6.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 11 77 6.6.2. "email" property . . . . . . . . . . . . . . . . . . 12 78 6.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 12 79 6.7. Geographical Properties . . . . . . . . . . . . . . . . . 13 80 6.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 13 81 6.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 13 82 6.8. Organizational Properties . . . . . . . . . . . . . . . . 13 83 6.8.1. "title" property . . . . . . . . . . . . . . . . . . 14 84 6.8.2. "role" property . . . . . . . . . . . . . . . . . . . 14 85 6.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 14 86 6.8.4. "org" property . . . . . . . . . . . . . . . . . . . 15 87 6.9. Explanatory Properties . . . . . . . . . . . . . . . . . 15 88 6.9.1. "categories" property . . . . . . . . . . . . . . . . 15 89 6.9.2. "note" property . . . . . . . . . . . . . . . . . . . 15 90 6.9.3. "sound" property . . . . . . . . . . . . . . . . . . 16 91 6.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 16 92 6.9.5. "url" property . . . . . . . . . . . . . . . . . . . 16 93 6.9.6. "version" property . . . . . . . . . . . . . . . . . 17 94 7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 17 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 97 9.1. SIP Call-Info Header Field Purpose Token Request . . . . 17 98 9.2. SIP Call-Info Header Field Purpose Token Request . . . . 18 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 the called party 126 user agent can trust the SIP network or the SIP provider to deliver 127 the correct rich call data (RCD) information. This may not always be 128 the case and thus, the entity inserting the Call-Info header field 129 and the UAS relying on it SHOULD be part of the same trust domain 130 [RFC3324]. Alternatively, and likely the recommended approach, the 131 entity inserting the Call-Info header field 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 is generally 171 the widely accepted optimally supported format for transmission, 172 parsing, and manipulation of data on IP networks. Second, jCard has 173 also been defined in [I-D.ietf-stir-passport-rcd] and has been 174 adopted by PASSporT [RFC8225] because of the usage of JSON Web Tokens 175 (JWT) [RFC7519]. 177 A generic parameter for "call-reason" is to be used to provide a 178 string or other object that is used to convey the intent or reason 179 the caller is calling to help the called party understand better the 180 context of the call and why they may want to answer the call. 182 4. "jcard" Call-Info Token 184 The use of the new Call-Info Token "jcard" is for the purpose of 185 supporting RCD associated with the identity of a calling party in a 186 SIP call [RFC3261] Section 20.9. The format of a Call-Info header 187 field when using the "jcard" is as follows. 189 The Call-Info header field is defined to include a URI, where here 190 the resource pointed to by the URI is a jCard JSON object [RFC7095]. 191 The web server serving this file MUST use the MIME media type for 192 JSON text as application/json with a default encoding of UTF-8 193 [RFC4627]. A jCard also MAY be carried in the body of the SIP 194 request bearing this Call-Info via the "cid" URI scheme [RFC2392]. 195 Alternatively, the URI MUST define the use HTTPS or a transport that 196 can validate the integrity of the source of the resource as well as 197 the transport channel through which the resource is retrieved. 199 An example of a Call-Info header field is: 201 Call-Info: ;purpose=jcard 203 An example contents of a URL linked jCard JSON file is shown as 204 follows: 206 ["vcard", 207 [ 208 ["version",{},"text","4.0"], 209 ["fn",{},"text","Q Branch"], 210 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 211 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 212 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 213 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 214 ] 215 ] 217 An example SIP INVITE using the "cid" URI scheme is as follows. 219 INVITE sip:alice@example.com SIP/2.0 220 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 221 To: Alice 222 From: Bob ;tag=1928301774> 223 Call-ID: a84b4c76e66710 224 Call-Info: ;purpose=jcard;call-reason= \ 225 "Rendezvous for Little Nellie" 226 CSeq: 314159 INVITE 227 Max-Forwards: 70 228 Date: Fri, 25 Sep 2015 19:12:25 GMT 229 Contact: 230 Content-Type: multipart/mixed; boundary=boundary1 231 Content-Length: ... 233 --boundary1 235 Content-Type: application/sdp 237 v=0 238 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 239 s=Session SDP 240 c=IN IP4 pc33.atlanta.example.com 241 t=0 0 242 m=audio 49172 RTP/AVP 0 243 a=rtpmap:0 PCMU/8000 245 --boundary1 247 Content-Type: application/vcard+json 248 Content-ID: <12155551000@example.com> 250 ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"], 251 ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht 252 tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u 253 ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri", 254 "https://example.com/logos/mi6-64x64.jpg"]]] 256 5. "call-reason" Call-Info Parameter 258 In addition to the jCard value defined here, this specification also 259 defines a generic parameter of the Call-Info header called "call- 260 reason". The "call-reason" parameter is intended to convey a short 261 textual message suitable for display to an end user during call 262 alerting. As a general guideline, this message SHOULD be no longer 263 than 64 characters; displays that support this specification may be 264 forced to truncate messages that cannot fit onto a screen. This 265 message conveys the caller's intention in contacting the callee. It 266 is an optional parameter, and the sender of a SIP request cannot 267 guarantee that its display will be supported by the terminating 268 endpoint. The manner in which this reason is set by the caller is 269 outside the scope of this specification. 271 One alternative approach would be to use the baseline [RFC3261] 272 Subject header field value to convey the reason for the call. 273 Because the Subject header has seen little historical use in SIP 274 implementations, however, and its specification describes its 275 potential use in filtering, it seems more prudent to define a new 276 means of carrying a call reason indication. 278 An example of a Call-Info header field value with the "call-reason" 279 parameter follows: 281 Call-Info: ;purpose=jcard; 282 call-reason="For your ears only" 284 One can readily imagine a need for more structured call reason data 285 that could be reliably processed automatically. Future versions of 286 this specification may explore ways to provide a structured data 287 object in place of a textual string to support things like 288 internationalization or categories of reason that can be parsed by 289 machines. 291 6. Usage of jCard and property specific usage 293 Beyond the definition of the specific properties or JSON arrays 294 associated with each property. This specification defines a few 295 rules above and beyond [RFC7095] specific to the use of jCard for 296 Call-Info and Rich Call Data making sure there is a minimum level of 297 supported properties that every implementation of this specification 298 should adhere to. This includes support for interpreting the value 299 of this property and the ability to render in some appropriate form 300 the display capabilities of common telephone devices, as well as 301 apps, and also includes requirements specific to either textual 302 displays and graphics capable displays. 304 6.1. Usage of URIs in jCard 306 When one or more URIs are used in a jCard, it is important to note 307 that any URI referenced data, with the exception of the top-level 308 usage of "jcl" as a URI to the jCard itself (unless updated by any 309 future extensions of this specification) MUST not contain any URI 310 references. In other words, the jCard can have URI references as 311 defined in the jCard specification and this document, but the content 312 referenced by those URIs MUST NOT have any URIs, and therefore MUST 313 be enforced by the client to fail verification or not render content 314 to the user if any URI are present in that specific URI linked 315 content. The purpose of this is to control the security and more 316 specifically align with the content integrity mechanism defined in 317 [I-D.ietf-stir-passport-rcd]. It is the belief of the authors that 318 there isn't a scenario that deeper URI references would be required 319 or even supported by the current set of properties for the typical 320 use of jCard properties, but because jCard is extensible, this rule 321 is set to restrict further extension without the proper consideration 322 of security and integrity properties of both Call-Info usage as well 323 as the Rich Call Data and STIR signing of the data 324 [I-D.ietf-stir-passport-rcd], [RFC8224]. 326 6.2. Usage of multimedia data in jCard 328 There are a few cases where jCards incorporate URIs or directly 329 include via Base64 encoding of digital images and sounds. We specify 330 a few recommended conventions to facilitate more consistent support 331 of the successful rendering of these images. 333 For images, such as for the photo and logo properties, the default 334 image formats should be png or jpg. These files are mostly commonly 335 used to support 24-bit RGB images which should consequently be the 336 default. There are some older telephone devices that may only 337 support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit 338 or 1-bit), also with potentially only grayscale or 1-bit black and 339 white color displays. These exceptions are considered optional to 340 support. 342 In addition, vector images are increasingly popular in their use for 343 icons and the need for scalable images without having to send 344 multiple resolutions. SVG format [W3C SVG 1.1 or higher] has gained 345 wide support, as of the writing of this document, as a common format 346 for vector images and should be supported as an additional default 347 format supported by devices that support this specification. 349 For the cases where image files are referenced by URIs as file 350 resources, this document defines a character string that SHOULD be 351 concatenated on to the end of a file name, before the file extension 352 that signals the height and width of the image to the end device for 353 the convenience of determining the appropriate resolution to retrieve 354 without the need to retrieve all the image files. It is also 355 recommended that images are square ratio formatted with equal height 356 and width and with a power of two value for the number of pixels 357 (e.g. 32x32, 128x128, 512x512). The format of the string should be 358 "filename-HxW" where filename represents the unique string 359 representing the file and H represents the height in pixels and W 360 represents the width in pixels. If the file is not to be rendered 361 using the default 24-bit RGB pixel format, additionally the string 362 can be extended to include bit depth and number of colors. That 363 string should be formatted as "filename-HxW-bd-c", where bd is the 364 bit depth (e.g. 1, 8, 16) and c represents number of color channels 365 which should either be 1 or 3. Note: 32-bit/RGBA color format is 366 specifically not recommended for this document because transparency 367 would not be clear how to render for display. 369 For audio files, the recommendation is to provide mp3, m4a, or wav 370 files, although the usage of sound is not well defined in this 371 specification as, for example, a special ring tone for a particular 372 caller, and future documents should consider both usage and potential 373 security risks of playing sounds that are not specifically authorized 374 by a device user. 376 6.3. Cardinality 378 Property cardinalities are indicated, for convenience, using the 379 following notation and follow the guidance of jCard [RFC7095] and 380 vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6): 382 +-------------+--------------------------------------------------+ 383 | Cardinality | Meaning | 384 +-------------+--------------------------------------------------+ 385 | 1 | Exactly one instance per jCard MUST be present. | 386 | *1 | Exactly one instance per jCard MAY be present. | 387 | 1* | One or more instances per jCard MUST be present. | 388 | * | One or more instances per jCard MAY be present. | 389 +-------------+--------------------------------------------------+ 391 6.4. Identification properties 393 These types are used to capture information associated with the 394 identification and naming of the entity associated with the jCard. 395 They are initially defined in [RFC6350], but the following list of 396 properties included and repeated in this Section is a subset of the 397 properties defined for jCard with properties selected for this 398 document that have relevance to telephone and messaging applications. 399 jCard is an extensible object and therefore, there may also be future 400 specifications that extend the set of properties that may be relevant 401 to the set of communications applications that utilize this 402 specification. 404 6.4.1. "fn" property 406 The "fn" property has the intent of providing a formatted text 407 corresponding to the name of the object the jCard represents. 408 Reference [RFC6350] Section 6.2.1. 410 Value type: A single text value. 412 Cardinality: 1* 414 Example: 415 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 417 6.4.2. "n" property 419 The "n" property has the intent of providing the components of the 420 name of the object the jCard represents. Reference [RFC6350] 421 Section 6.2.2. 423 Value type: A single structured text value. Each component can have 424 multiple values. 426 Cardinality: *1 428 Example: 429 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 430 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 432 6.4.3. "nickname" property 434 The "nickname" property has the intent of providing the text 435 corresponding to the nickname of the object the jCard represents. 436 Reference [RFC6350] Section 6.2.3. 438 Value type: One or more text values separated by a COMMA character 439 (U+002C). 441 Cardinality: * 443 Example: 444 ["nickname", {}, "text", "Robbie"] 445 ["nickname", {}, "text", "Jim,Jimmie"] 446 ["nickname", {}, "text", "TYPE=work:Boss"] 448 6.4.4. "photo" property 450 The "photo" property has the intent of supplying an image or 451 photograph information that annotates some aspect of the object the 452 jCard represents. Reference [RFC6350] Section 6.2.4. 454 In addition to the definition of jCard, and to promote 455 interoperability and proper formatting and rendering of images, the 456 photo SHOULD correspond to a square image size of the sizes 128x128, 457 256x256, 512x512, or 1024x1024 pixels. 459 Value type: A single URI. 461 Cardinality: * 463 Example: 464 ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"] 466 6.5. Delivery Addressing Properties 468 These properties are concerned with information related to the 469 delivery addressing or label for the jCard object. 471 6.5.1. "adr" property 473 The "adr" property has the intent of providing the delivery address 474 of the object the jCard represents. Reference [RFC6350] 475 Section 6.3.1. 477 Value type: A single structured text value, separated by the 478 SEMICOLON character (U+003B). 480 Cardinality: * 482 Example: 483 ["adr", {"type":"work"}, "text", 484 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", 485 "20008", "USA"] 487 6.6. Communications Properties 489 These properties describe information about how to communicate with 490 the object the jCard represents. 492 6.6.1. "tel" property 494 The "tel" property has the intent of providing the telephone number 495 for telephony communication of the object the jCard represents. 496 Reference [RFC6350] Section 6.4.1. 498 Relative to the SIP From header field value this information may 499 provide alternate telephone number or other related telephone numbers 500 for other uses. 502 It is important to note that any of the potential instances of the 503 "tel" property should not be considered part of the authentication or 504 verification part of STIR [RFC8224] or required to match the "orig" 505 claim in the PASSporT [RFC8225]. These telephone numbers should be 506 considered for contact, fax, or other purposes aligned with the 507 general usage of jCard and vCard, although consideration of confusing 508 the caller with different contact telephone number information versus 509 the actual verified telephone number should be made from a general 510 policy point of view. 512 Value type: By default, it is a single free-form text value (for 513 backward compatibility with vCard 3), but it SHOULD be reset to a URI 514 value. It is expected that the URI scheme will be "tel", as 515 specified in [RFC3966], but other schemes MAY be used. 517 Cardinality: * 519 Example: 520 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 521 "tel:+1-202-555-1000"] 522 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 524 6.6.2. "email" property 526 The "email" property has the intent of providing the electronic mail 527 address for communication of the object the jCard represents. 528 Reference [RFC6350] Section 6.4.2. 530 Value type: A single text value. 532 Cardinality: * 534 Example: 535 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 536 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 538 6.6.3. "lang" property 540 The "lang" property has the intent of providing the language(s) that 541 may be used for contacting of the object the jCard represents. 542 Reference [RFC6350] Section 6.4.4. 544 Value type: A single language-tag value. 546 Cardinality: * 547 Example: 548 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 549 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 550 ["lang", {"type":"home"}, "language-tag", "fr"] 552 6.7. Geographical Properties 554 These properties are concerned with information associated with 555 geographical positions or regions associated with the object the 556 jCard represents. 558 6.7.1. "tz" property 560 The "tz" property has the intent of providing the time zone of the 561 object the jCard represents. Reference [RFC6350] Section 6.5.1. 563 Note: the up-to-date reference for where time-zone names are 564 maintained is, at the authoring of this document, at this web 565 address, https://www.iana.org/time-zones. 567 Value type: The default is a single text value. It can also be reset 568 to a single URI or utc-offset value. 570 Cardinality: * 572 Example: 573 ["tz", {}, "text", "Raleigh/North America"] 575 6.7.2. "geo" property 577 The "geo" property has the intent of providing the global positioning 578 of the object the jCard represents. Reference [RFC6350] 579 Section 6.5.2. 581 Value type: A single URI. 583 Cardinality: * 585 Example: 586 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 588 6.8. Organizational Properties 590 These properties are concerned with information associated with 591 characteristics of the organization or organizational units of the 592 object that the jCard represents. 594 6.8.1. "title" property 596 The "title" property has the intent of providing the position or job 597 of the object the jCard represents. Reference [RFC6350] 598 Section 6.6.1. 600 Value type: A single text value. 602 Cardinality: * 604 Example: 605 ["title", {}, "text", "Research Scientist"] 607 6.8.2. "role" property 609 The "role" property has the intent of providing the position or job 610 of the object the jCard represents. Reference [RFC6350] 611 Section 6.6.2. 613 Value type: A single text value. 615 Cardinality: * 617 Example: 618 ["role", {}, "text", "Project Leader"] 620 6.8.3. "logo" property 622 The "logo" property has the intent of specifying a graphic image of a 623 logo associated with the object the jCard represents. Reference 624 [RFC6350] Section 6.6.3. 626 Value type: A single URI. 628 Cardinality: * 630 Example: 631 ["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"] 633 ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC 634 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 635 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 636 <...the remainder of base64-encoded data...>"] 638 6.8.4. "org" property 640 The "org" property has the intent of specifying the organizational 641 name and units of the object the jCard represents. Reference 642 [RFC6350] Section 6.6.2. 644 Value type: A single structured text value consisting of components 645 separated by the SEMICOLON character (U+003B). 647 Cardinality: * 649 Example: 650 ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"] 652 6.9. Explanatory Properties 654 These properties are concerned with additional explanations, such as 655 that related to informational notes or revisions specific to the 656 jCard. 658 6.9.1. "categories" property 660 The "categories" property has the intent of specifying application 661 category information about the object the jCard represents. 662 Reference [RFC6350] Section 6.7.1. 664 Value type: One or more text values separated by a COMMA character 665 (U+002C). 667 Cardinality: * 669 Example: 670 ["categories", {}, "text", "TRAVEL AGENT"] 672 ["categories", {}, "text", "INTERNET,IETF,INDUSTRY"] 674 6.9.2. "note" property 676 The "note" property has the intent of specifying supplemental 677 information or a comment about the object the jCard represents. 678 Reference [RFC6350] Section 6.7.2. 680 Value type: A single text value. 682 Cardinality: * 683 Example: 684 ["note", {}, "text", "This fax number is operational 0800 to 1715 685 EST\, Mon-Fri."] 687 6.9.3. "sound" property 689 The "sound" property has the intent of specifying a digital sound 690 content information that annotates some aspect of the object the 691 jCard represents. This property is often used to specify the proper 692 pronunciation of the name property value of the jCard. Reference 693 [RFC6350] Section 6.7.5. 695 Value type: A single URI. 697 Cardinality: * 699 Example: 700 ["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"] 702 ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE 703 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 704 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 705 <...the remainder of base64-encoded data...>"] 707 6.9.4. "uid" property 709 The "uid" property has the intent of specifying a globally unique 710 identifier corresponding to the object the jCard represents. 711 Reference [RFC6350] Section 6.7.6. 713 Value type: A single URI value. It MAY also be reset to free-form 714 text. 716 Cardinality: *1 718 Example: 719 ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"] 721 6.9.5. "url" property 723 The "url" property has the intent of specifying a uniform resource 724 locator associated with the object the jCard represents. Reference 725 [RFC6350] Section 6.7.8. 727 There is potential security and privacy implications of providing 728 URLs with telephone calls. The end client receiving a jCard with a 729 URL property MUST only display the URL and not automatically follow 730 the URL or provide automatic preview of the URL, and generally 731 provide good practices in making it clear to the user it is their 732 choice to follow the URL in a browser context consistent with all of 733 the common browser security and privacy practices available on most 734 consumer OS environments. 736 Value type: A single uri value. 738 Cardinality: * 740 Example: 741 ["url", {}, "uri", "https://example.org/french-rest/chezchic.html"] 743 6.9.6. "version" property 745 The "version" property MUST be included and is intended to specify 746 the version of the vCard specification used to format this vCard. 747 Reference [RFC6350] Section 6.7.9. 749 Value type: A single text value. 751 Cardinality: 1 753 Example: 754 ["version", {}, "text", "4.0"] 756 7. Extension of jCard 758 Part of the intent of the usage of jCard is that it has its own 759 extensibility properties where new properties can be defined to relay 760 newly defined information related to a caller. This capability is 761 inherently supported as part of standard extensibility. However, 762 usage of those new properties should be published and registered 763 following [RFC7095] Section 3.6 or new specifications. 765 8. Acknowledgements 767 We would like to thank David Hancock and other members of the STIR 768 working group for helpful suggestions and comments for the creation 769 of this draft. 771 9. IANA Considerations 773 9.1. SIP Call-Info Header Field Purpose Token Request 775 [this RFC] defines the "jcard" token for use as a new token in the 776 Call-Info header in the "Header Field Parameters and Parameter 777 Values" registry defined by [RFC3968]. 779 +--------------+----------------+-------------------+------------+ 780 | Header Field | Parameter Name | Predefined Values | Reference | 781 +--------------+----------------+-------------------+------------+ 782 | Call-Info | jcard | No | [this RFC] | 783 +--------------+----------------+-------------------+------------+ 785 9.2. SIP Call-Info Header Field Purpose Token Request 787 [this RFC] defines the "call-reason" generic parameter for use as a 788 new parameter in the Call-Info header in the "Header Field Parameters 789 and Parameter Values" registry defined by [RFC3968]. The parameter's 790 token is "call-reason" and it takes the value of a quoted string. 792 10. Security Considerations 794 Revealing information such as the name, location, and affiliation of 795 a person necessarily entails certain privacy risks. SIP and Call- 796 Info has no particular confidentiality requirement, as the 797 information sent in SIP is in the clear anyway. Transport-level 798 security can be used to hide information from eavesdroppers, and the 799 same confidentiality mechanisms would protect any Call-Info or jCard 800 information carried or referred to in SIP. 802 11. Normative References 804 [I-D.ietf-stir-passport-rcd] 805 Wendt, C. and J. Peterson, "PASSporT Extension for Rich 806 Call Data", Work in Progress, Internet-Draft, draft-ietf- 807 stir-passport-rcd-13, 9 September 2021, 808 . 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, 813 DOI 10.17487/RFC2119, March 1997, 814 . 816 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 817 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 818 . 820 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 821 RFC 2426, DOI 10.17487/RFC2426, September 1998, 822 . 824 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 825 A., Peterson, J., Sparks, R., Handley, M., and E. 826 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 827 DOI 10.17487/RFC3261, June 2002, 828 . 830 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 831 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 832 . 834 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 835 RFC 3966, DOI 10.17487/RFC3966, December 2004, 836 . 838 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 839 (IANA) Header Field Parameter Registry for the Session 840 Initiation Protocol (SIP)", BCP 98, RFC 3968, 841 DOI 10.17487/RFC3968, December 2004, 842 . 844 [RFC4627] Crockford, D., "The application/json Media Type for 845 JavaScript Object Notation (JSON)", RFC 4627, 846 DOI 10.17487/RFC4627, July 2006, 847 . 849 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 850 Specifications: ABNF", STD 68, RFC 5234, 851 DOI 10.17487/RFC5234, January 2008, 852 . 854 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 855 DOI 10.17487/RFC6350, August 2011, 856 . 858 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 859 DOI 10.17487/RFC7095, January 2014, 860 . 862 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 863 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 864 . 866 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 867 J. Winterbottom, "Additional Data Related to an Emergency 868 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 869 . 871 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 872 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 873 May 2017, . 875 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 876 "Authenticated Identity Management in the Session 877 Initiation Protocol (SIP)", RFC 8224, 878 DOI 10.17487/RFC8224, February 2018, 879 . 881 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 882 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 883 . 885 Authors' Addresses 887 Chris Wendt 888 Comcast 889 Comcast Technology Center 890 Philadelphia, PA 19103, 891 United States of America 893 Email: chris-ietf@chriswendt.net 895 Jon Peterson 896 Neustar Inc. 897 1800 Sutter St Suite 570 898 Concord, CA 94520, 899 United States of America 901 Email: jon.peterson@neustar.biz