idnits 2.17.1 draft-ietf-sipcore-callinfo-rcd-04.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 -- The document date (7 March 2022) is 774 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-14 ** 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 (~~), 2 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 Somos Inc. 4 Intended status: Standards Track J. Peterson 5 Expires: 8 September 2022 Neustar Inc. 6 7 March 2022 8 SIP Call-Info Parameters for Rich Call Data 9 draft-ietf-sipcore-callinfo-rcd-04 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 8 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 5 63 5. "call-reason" Call-Info Parameter . . . . . . . . . . . . . . 6 64 6. "jmin" Call-Info Token . . . . . . . . . . . . . . . . . . . 7 65 7. Usage of jCard and property specific usage . . . . . . . . . 9 66 7.1. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 9 67 7.2. Usage of multimedia data in jCard . . . . . . . . . . . . 9 68 7.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.4. Identification properties . . . . . . . . . . . . . . . . 11 70 7.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 11 71 7.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 11 72 7.4.3. "nickname" property . . . . . . . . . . . . . . . . . 12 73 7.4.4. "photo" property . . . . . . . . . . . . . . . . . . 12 74 7.5. Delivery Addressing Properties . . . . . . . . . . . . . 12 75 7.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 12 76 7.6. Communications Properties . . . . . . . . . . . . . . . . 13 77 7.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 13 78 7.6.2. "email" property . . . . . . . . . . . . . . . . . . 14 79 7.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 14 80 7.7. Geographical Properties . . . . . . . . . . . . . . . . . 14 81 7.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 14 82 7.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 15 83 7.8. Organizational Properties . . . . . . . . . . . . . . . . 15 84 7.8.1. "title" property . . . . . . . . . . . . . . . . . . 15 85 7.8.2. "role" property . . . . . . . . . . . . . . . . . . . 15 86 7.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 16 87 7.8.4. "org" property . . . . . . . . . . . . . . . . . . . 16 88 7.9. Explanatory Properties . . . . . . . . . . . . . . . . . 16 89 7.9.1. "categories" property . . . . . . . . . . . . . . . . 16 90 7.9.2. "note" property . . . . . . . . . . . . . . . . . . . 17 91 7.9.3. "sound" property . . . . . . . . . . . . . . . . . . 17 92 7.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 17 93 7.9.5. "url" property . . . . . . . . . . . . . . . . . . . 18 94 7.9.6. "version" property . . . . . . . . . . . . . . . . . 18 95 8. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 18 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 10.1. SIP Call-Info Header Field Purpose Token Request . . . . 19 99 10.2. SIP Call-Info Header Field Purpose Token Request . . . . 19 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 12. Normative References . . . . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 Traditional telephone network signaling protocols have long supported 107 delivering a 'calling name' from the originating side, though in 108 practice, the terminating side is often left to derive a name from 109 the calling party number by consulting a local address book or an 110 external database. SIP similarly can carry a 'display-name' in the 111 From header field value from the originating to terminating side, 112 though it is an unsecured field that is not commonly trusted and 113 often replaced or ignored. The same is often true of information in 114 the Call-Info header fields. 116 To allow calling parties to initiate, and called parties to receive, 117 a more comprehensive, deterministic, and extensible rich call data 118 for incoming calls, we describe new tokens for the SIP [RFC3261] 119 Call-Info header field and a corresponding "purpose" parameter. We 120 also define a new parameter of Call-Info designed for carrying a 121 "reason" value. For this document, depending on the policies of the 122 communications system, calling parties could either be the end user 123 device or an originating service provider, and called parties could 124 also similarly be an end user device or the terminating service 125 provider acting on behalf of the recipient of the call. 127 Used on its own, this specification assumes that the called party 128 user agent can trust the SIP network or the SIP provider to deliver 129 the correct rich call data (RCD) information. This may not always be 130 the case and thus, the entity inserting the Call-Info header field 131 and the UAS relying on it SHOULD be part of the same trust domain 132 [RFC3324]. Alternatively, and likely the recommended approach, the 133 entity inserting the Call-Info header field should also sign the 134 caller information via STIR mechanisms [RFC8224] and specifically 135 through the [I-D.ietf-stir-passport-rcd]. This STIR signature would 136 likely be provided by the caller itself or the originating service 137 provider using an authoritative signature to authenticate the 138 information is from the originator and hasn't been tampered with in 139 transmission. 141 [RFC7852] provides a means of carrying additional data about callers 142 for the purposes of emergency services (especially its Section 4.4 143 "Owner/Subscriber" information). This specification provides an 144 overlapping functionality for non-emergency cases. Rather than 145 overloading its "EmergencyCallData" Call-Info "purpose" parameter 146 value, this document defines a separate "purpose" parameter for the 147 more generic delivery of information via jCard [RFC7095]. This 148 document borrows from [RFC7852] the capability to carry a data 149 structure as a body, through the use of the "cid" URI scheme 150 [RFC2392]. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Overview 162 The Call-Info header field, defined in [RFC3261] Section 20.9, 163 defines a purpose parameter currently with "info", "icon", and "card" 164 tokens. This document defines two new purpose values and one new 165 generic parameter for Call-Info. 167 The first purpose value defined is "jcard" and is used to associate 168 rich call data related to the identity of the calling party in the 169 form of a jCard [RFC7095]. While there is a "card" token that is 170 already defined with similar purpose, there are two primary reasons 171 for the definition and usage of jCard and the use of JSON over the 172 XML based vCard [RFC2426]. First, JSON has become the default and is 173 generally the widely accepted optimally supported format for 174 transmission, parsing, and manipulation of data on IP networks. 175 Second, jCard has also been defined in [I-D.ietf-stir-passport-rcd] 176 and has been adopted by PASSporT [RFC8225] because of the usage of 177 JSON Web Tokens (JWT) [RFC7519]. 179 A generic parameter for "call-reason" is to be used to provide a 180 string or other object that is used to convey the intent or reason 181 the caller is calling to help the called party understand better the 182 context of the call and why they may want to answer the call. 184 The second purpose value defined is "jmin" and is intended to be a 185 minimal call-info URI specifically for purposes where call-info does 186 not point to any structured information via URI, but is used to carry 187 parameters either defined in this document or future documents. 189 4. "jcard" Call-Info Token 191 The use of the new Call-Info Token "jcard" is for the purpose of 192 supporting RCD associated with the identity of a calling party in a 193 SIP call [RFC3261] Section 20.9. The format of a Call-Info header 194 field when using the "jcard" is as follows. 196 The Call-Info header field is defined to include a URI, where here 197 the resource pointed to by the URI is a jCard JSON object [RFC7095]. 198 The MIME media type set for the JSON text MUST be set as application/ 199 json with a default encoding of UTF-8 [RFC4627]. A jCard also MAY be 200 carried in the body of the SIP request bearing this Call-Info via the 201 "cid" URI scheme [RFC2392]. Alternatively, the URI MUST define the 202 use HTTPS or a transport that can validate the integrity of the 203 source of the resource as well as the transport channel through which 204 the resource is retrieved. 206 An example of a Call-Info header field is: 208 Call-Info: ;purpose=jcard 210 An example contents of a URL linked jCard JSON file is shown as 211 follows: 213 ["vcard", 214 [ 215 ["version",{},"text","4.0"], 216 ["fn",{},"text","Q Branch"], 217 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 218 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 219 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 220 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 221 ] 222 ] 224 An example SIP INVITE using the "cid" URI scheme is as follows. 226 INVITE sip:alice@example.com SIP/2.0 227 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 228 To: Alice 229 From: Bob ;tag=1928301774> 230 Call-ID: a84b4c76e66710 231 Call-Info: ;purpose=jcard;call-reason= \ 232 "Rendezvous for Little Nellie" 233 CSeq: 314159 INVITE 234 Max-Forwards: 70 235 Date: Fri, 25 Sep 2015 19:12:25 GMT 236 Contact: 237 Content-Type: multipart/mixed; boundary=boundary1 238 Content-Length: ... 240 --boundary1 242 Content-Type: application/sdp 244 v=0 245 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 246 s=Session SDP 247 c=IN IP4 pc33.atlanta.example.com 248 t=0 0 249 m=audio 49172 RTP/AVP 0 250 a=rtpmap:0 PCMU/8000 252 --boundary1 254 Content-Type: application/vcard+json 255 Content-ID: <12155551000@example.com> 257 ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"], 258 ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht 259 tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u 260 ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri", 261 "https://example.com/logos/mi6-64x64.jpg"]]] 263 5. "call-reason" Call-Info Parameter 265 This specification also defines a parameter of the Call-Info header 266 called "call-reason". The "call-reason" parameter is intended to 267 convey a short textual message suitable for display to an end user 268 during call alerting. As a general guideline, this message SHOULD be 269 no longer than 64 characters; displays that support this 270 specification may be forced to truncate messages that cannot fit onto 271 a screen. This message conveys the caller's intention in contacting 272 the callee. It is an optional parameter, and the sender of a SIP 273 request cannot guarantee that its display will be supported by the 274 terminating endpoint. The manner in which this reason is set by the 275 caller is outside the scope of this specification. 277 One alternative approach would be to use the baseline [RFC3261] 278 Subject header field value to convey the reason for the call. 279 Because the Subject header has seen little historical use in SIP 280 implementations, however, and its specification describes its 281 potential use in filtering, it seems more prudent to define a new 282 means of carrying a call reason indication. 284 An example of a Call-Info header field value with the "call-reason" 285 parameter follows: 287 Call-Info: ;purpose=jcard; 288 call-reason="For your ears only" 290 Refer to the next section that extends call-reason and, in 291 particular, discusses reasoning for the use of "call-reason" 292 parameter versus considering "jinfo" with an included "call-reason" 293 key value. 295 6. "jmin" Call-Info Token 297 This specification defines a token for the Call-Info header field 298 called "jmin". The "jmin" call-info URI is intended to address the 299 need for scenarios where there it is not needed to use the URI value 300 of call-info but only necessary to use defined call-info parameters, 301 one example being the "call-reason" parameter defined in this 302 document. The URI referenced value by "jmin" is defined as a minimal 303 JSON formatted object that MUST be the specific value "{}". The JSON 304 object "{}" is a valid JSON object per [RFC8259] but specifically 305 contains no keys or values. The MIME media type for this minimal 306 JSON object text MUST be set as application/json with a default 307 encoding of UTF-8 [RFC4627]. The "jmin" minimal JSON object string 308 MAY be carried in the body of the SIP request bearing this Call-Info 309 via the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST 310 define the use HTTPS or a transport that can validate the integrity 311 of the source of the resource as well as the transport channel 312 through which the resource is retrieved. 314 We define this minimal JSON object for the express purpose of being a 315 valid URI that will not break implementations that are not 316 implementing this specification that reference the URI per procedures 317 defined in [RFC3261] Section 20.9. However, for implementations that 318 do support this specification, because the value referenced by the 319 URI MUST be "{}", as an optimization, implementations of this 320 specification MAY consider it a shortcut to not reference the URI and 321 trust that the value referenced will always be "{}". 323 An example of a Call-Info header field using "jmin" purpose and call- 324 reason parameter is: 326 Call-Info: ;purpose=jmin; 327 call-reason="For your ears only" 329 The resource referenced by the URL for the above example would be a 330 file containing: 332 {} 334 An example SIP INVITE using the "cid" URI scheme equivalent to the 335 above example is as follows. 337 INVITE sip:alice@example.com SIP/2.0 338 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 339 To: Alice 340 From: Bob ;tag=1928301774> 341 Call-ID: a84b4c76e66710 342 Call-Info: ;purpose=jmin;call-reason= 343 "For your ears only" 344 CSeq: 314159 INVITE 345 Max-Forwards: 70 346 Date: Fri, 25 Sep 2015 19:12:25 GMT 347 Contact: 348 Content-Type: multipart/mixed; boundary=boundary1 349 Content-Length: ... 351 --boundary1 353 Content-Type: application/sdp 355 v=0 356 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 357 s=Session SDP 358 c=IN IP4 pc33.atlanta.example.com 359 t=0 0 360 m=audio 49172 RTP/AVP 0 361 a=rtpmap:0 PCMU/8000 363 --boundary1 365 Content-Type: application/json 366 Content-ID: <12155551000@example.com> 368 {} 370 7. Usage of jCard and property specific usage 372 Beyond the definition of the specific properties or JSON arrays 373 associated with each property. This specification defines a few 374 rules above and beyond [RFC7095] specific to the use of jCard for 375 Call-Info and Rich Call Data making sure there is a minimum level of 376 supported properties that every implementation of this specification 377 should adhere to. This includes support for interpreting the value 378 of this property and the ability to render in some appropriate form 379 the display capabilities of common telephone devices, as well as 380 apps, and also includes requirements specific to either textual 381 displays and graphics capable displays. 383 7.1. Usage of URIs in jCard 385 When one or more URIs are used in a jCard, it is important to note 386 that any URI referenced data, with the exception of the top-level 387 usage of "jcl" as a URI to the jCard itself (unless updated by any 388 future extensions of this specification) MUST NOT contain any URI 389 references. In other words, the jCard can have URI references as 390 defined in the jCard specification and this document, but the content 391 referenced by those URIs MUST NOT have any URIs, and therefore MUST 392 be enforced by the client to not follow those URI references or not 393 render that content to the user if any URI are present in that 394 specific URI linked content. The purpose of this is to control the 395 security and more specifically align with the content integrity 396 mechanism defined in [I-D.ietf-stir-passport-rcd]. It is the belief 397 of the authors that there isn't a scenario that deeper URI references 398 would be required or even supported by the current set of properties 399 for the typical use of jCard properties, but because jCard is 400 extensible, this rule is set to restrict further extension without 401 the proper consideration of security and integrity properties of both 402 Call-Info usage as well as the Rich Call Data and STIR signing of the 403 data [I-D.ietf-stir-passport-rcd], [RFC8224]. 405 7.2. Usage of multimedia data in jCard 407 There are a few cases where jCards incorporate URIs or directly 408 include via Base64 encoding of digital images and sounds. We specify 409 a few recommended conventions to facilitate more consistent support 410 of the successful rendering of these images. 412 For images, such as for the photo and logo properties, the default 413 image formats SHOULD be png or jpg. These files are mostly commonly 414 used to support 24-bit RGB images which should consequently be the 415 default. There are some older telephone devices that may only 416 support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit 417 or 1-bit), also with potentially only grayscale or 1-bit black and 418 white color displays. These exceptions are should considered 419 optional to support or even recommended not to support and at least 420 at the time of writing this document are becoming increasingly rare 421 (i.e. typically displays on devices are either color or color-aware 422 graphical displays that support png or jpg formats or exclusively 423 textual displays). 425 In addition, vector images are increasingly popular in their use for 426 icons and the need for scalable images without having to send 427 multiple resolutions. SVG format and [W3C SVG 1.2 Tiny or higher] 428 specifically appropriate for this specification has gained wide 429 support as of the writing of this document, as a common format for 430 vector images and should be supported as an additional default format 431 for devices that support this specification. 433 For the cases where image files are referenced by URIs as file 434 resources, this document defines a character string that SHOULD be 435 concatenated on to the end of a file name, before the file extension 436 that signals the height and width of the image to the end device for 437 the convenience of determining the appropriate resolution to retrieve 438 without the need to retrieve all the image files. It is also 439 recommended that images are square ratio formatted with equal height 440 and width and with a power of two value for the number of pixels 441 (e.g. 32x32, 128x128, 512x512). The format of the string should be 442 "filename-HxW" where filename represents the unique string 443 representing the file and H represents the height in pixels and W 444 represents the width in pixels. 446 Because this is a complex and often debated topic that has evolved 447 over the many years of advances in image coding and display 448 technologies, we likely suggest relying on either future 449 specifications or industry forum specifications that might correspond 450 to supporting particular classes of devices to further define how 451 URIs can reference appropriate image formats and files. 453 For audio files, the recommendation is to provide mp3, m4a, or wav 454 files, although the usage of sound is not well defined in this 455 specification as, for example, a special ring tone for a particular 456 caller, and future documents should consider both usage and potential 457 security risks of playing sounds that are not specifically authorized 458 by a device user. 460 7.3. Cardinality 462 Property cardinalities are indicated, for convenience, using the 463 following notation and follow the guidance of jCard [RFC7095] and 464 vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6): 466 +-------------+--------------------------------------------------+ 467 | Cardinality | Meaning | 468 +-------------+--------------------------------------------------+ 469 | 1 | Exactly one instance per jCard MUST be present. | 470 | *1 | Exactly one instance per jCard MAY be present. | 471 | 1* | One or more instances per jCard MUST be present. | 472 | * | One or more instances per jCard MAY be present. | 473 +-------------+--------------------------------------------------+ 475 7.4. Identification properties 477 These types are used to capture information associated with the 478 identification and naming of the entity associated with the jCard. 479 They are initially defined in [RFC6350], but the following list of 480 properties included and repeated in this Section is a subset of the 481 properties defined for jCard with properties selected for this 482 document that have relevance to telephone and messaging applications. 483 jCard is an extensible object and therefore, there may also be future 484 specifications that extend the set of properties that may be relevant 485 to the set of communications applications that utilize this 486 specification. 488 7.4.1. "fn" property 490 The "fn" property has the intent of providing a formatted text 491 corresponding to the name of the object the jCard represents. 492 Reference [RFC6350] Section 6.2.1. 494 Value type: A single text value. 496 Cardinality: 1* 498 Example: 499 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 501 7.4.2. "n" property 503 The "n" property has the intent of providing the components of the 504 name of the object the jCard represents. Reference [RFC6350] 505 Section 6.2.2. 507 Value type: A single structured text value. Each component can have 508 multiple values. 510 Cardinality: *1 511 Example: 512 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 513 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 515 7.4.3. "nickname" property 517 The "nickname" property has the intent of providing the text 518 corresponding to the nickname of the object the jCard represents. 519 Reference [RFC6350] Section 6.2.3. 521 Value type: One or more text values separated by a COMMA character 522 (U+002C). 524 Cardinality: * 526 Example: 527 ["nickname", {}, "text", "Robbie"] 528 ["nickname", {}, "text", "Jim,Jimmie"] 529 ["nickname", {}, "text", "TYPE=work:Boss"] 531 7.4.4. "photo" property 533 The "photo" property has the intent of supplying an image or 534 photograph information that annotates some aspect of the object the 535 jCard represents. Reference [RFC6350] Section 6.2.4. 537 In addition to the definition of jCard, and to promote 538 interoperability and proper formatting and rendering of images, the 539 photo SHOULD correspond to a square image size of the sizes 128x128, 540 256x256, 512x512, or 1024x1024 pixels. 542 Value type: A single URI. 544 Cardinality: * 546 Example: 547 ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"] 549 7.5. Delivery Addressing Properties 551 These properties are concerned with information related to the 552 delivery addressing or label for the jCard object. 554 7.5.1. "adr" property 556 The "adr" property has the intent of providing the delivery address 557 of the object the jCard represents. Reference [RFC6350] 558 Section 6.3.1. 560 Value type: A single structured text value, separated by the 561 SEMICOLON character (U+003B). 563 Cardinality: * 565 Example: 566 ["adr", {"type":"work"}, "text", 567 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", 568 "20008", "USA"] 570 7.6. Communications Properties 572 These properties describe information about how to communicate with 573 the object the jCard represents. 575 7.6.1. "tel" property 577 The "tel" property has the intent of providing the telephone number 578 for telephony communication of the object the jCard represents. 579 Reference [RFC6350] Section 6.4.1. 581 Relative to the SIP From header field value this information may 582 provide alternate telephone number or other related telephone numbers 583 for other uses. 585 It is important to note that any of the potential instances of the 586 "tel" property should not be considered part of the authentication or 587 verification part of STIR [RFC8224] or required to match the "orig" 588 claim in the PASSporT [RFC8225]. These telephone numbers should be 589 considered for contact, fax, or other purposes aligned with the 590 general usage of jCard and vCard, although consideration of confusing 591 the caller with different contact telephone number information versus 592 the actual verified telephone number should be made from a general 593 policy point of view. 595 Value type: By default, it is a single free-form text value (for 596 backward compatibility with vCard 3), but it SHOULD be reset to a URI 597 value. It is expected that the URI scheme will be "tel", as 598 specified in [RFC3966], but other schemes MAY be used. 600 Cardinality: * 602 Example: 603 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 604 "tel:+1-202-555-1000"] 605 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 607 7.6.2. "email" property 609 The "email" property has the intent of providing the electronic mail 610 address for communication of the object the jCard represents. 611 Reference [RFC6350] Section 6.4.2. 613 Value type: A single text value. 615 Cardinality: * 617 Example: 618 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 619 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 621 7.6.3. "lang" property 623 The "lang" property has the intent of providing the language(s) that 624 may be used for contacting of the object the jCard represents. 625 Reference [RFC6350] Section 6.4.4. 627 Value type: A single language-tag value. 629 Cardinality: * 631 Example: 632 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 633 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 634 ["lang", {"type":"home"}, "language-tag", "fr"] 636 7.7. Geographical Properties 638 These properties are concerned with information associated with 639 geographical positions or regions associated with the object the 640 jCard represents. 642 7.7.1. "tz" property 644 The "tz" property has the intent of providing the time zone of the 645 object the jCard represents. Reference [RFC6350] Section 6.5.1. 647 Note: the up-to-date reference for where time-zone names are 648 maintained is, at the authoring of this document, at this web 649 address, https://www.iana.org/time-zones. 651 Value type: The default is a single text value. It can also be reset 652 to a single URI or utc-offset value. 654 Cardinality: * 655 Example: 656 ["tz", {}, "text", "Raleigh/North America"] 658 7.7.2. "geo" property 660 The "geo" property has the intent of providing the global positioning 661 of the object the jCard represents. Reference [RFC6350] 662 Section 6.5.2. 664 Value type: A single URI. 666 Cardinality: * 668 Example: 669 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 671 7.8. Organizational Properties 673 These properties are concerned with information associated with 674 characteristics of the organization or organizational units of the 675 object that the jCard represents. 677 7.8.1. "title" property 679 The "title" property has the intent of providing the position or job 680 of the object the jCard represents. Reference [RFC6350] 681 Section 6.6.1. 683 Value type: A single text value. 685 Cardinality: * 687 Example: 688 ["title", {}, "text", "Research Scientist"] 690 7.8.2. "role" property 692 The "role" property has the intent of providing the position or job 693 of the object the jCard represents. Reference [RFC6350] 694 Section 6.6.2. 696 Value type: A single text value. 698 Cardinality: * 700 Example: 701 ["role", {}, "text", "Project Leader"] 703 7.8.3. "logo" property 705 The "logo" property has the intent of specifying a graphic image of a 706 logo associated with the object the jCard represents. Reference 707 [RFC6350] Section 6.6.3. 709 Value type: A single URI. 711 Cardinality: * 713 Example: 714 ["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"] 716 ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC 717 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 718 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 719 <...the remainder of base64-encoded data...>"] 721 7.8.4. "org" property 723 The "org" property has the intent of specifying the organizational 724 name and units of the object the jCard represents. Reference 725 [RFC6350] Section 6.6.2. 727 Value type: A single structured text value consisting of components 728 separated by the SEMICOLON character (U+003B). 730 Cardinality: * 732 Example: 733 ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"] 735 7.9. Explanatory Properties 737 These properties are concerned with additional explanations, such as 738 that related to informational notes or revisions specific to the 739 jCard. 741 7.9.1. "categories" property 743 The "categories" property has the intent of specifying application 744 category information about the object the jCard represents. 745 Reference [RFC6350] Section 6.7.1. 747 Value type: One or more text values separated by a COMMA character 748 (U+002C). 750 Cardinality: * 751 Example: 752 ["categories", {}, "text", "TRAVEL AGENT"] 754 ["categories", {}, "text", "INTERNET,IETF,INDUSTRY"] 756 7.9.2. "note" property 758 The "note" property has the intent of specifying supplemental 759 information or a comment about the object the jCard represents. 760 Reference [RFC6350] Section 6.7.2. 762 Value type: A single text value. 764 Cardinality: * 766 Example: 767 ["note", {}, "text", "This fax number is operational 0800 to 1715 768 EST\, Mon-Fri."] 770 7.9.3. "sound" property 772 The "sound" property has the intent of specifying a digital sound 773 content information that annotates some aspect of the object the 774 jCard represents. This property is often used to specify the proper 775 pronunciation of the name property value of the jCard. Reference 776 [RFC6350] Section 6.7.5. 778 Value type: A single URI. 780 Cardinality: * 782 Example: 783 ["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"] 785 ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE 786 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 787 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 788 <...the remainder of base64-encoded data...>"] 790 7.9.4. "uid" property 792 The "uid" property has the intent of specifying a globally unique 793 identifier corresponding to the object the jCard represents. 794 Reference [RFC6350] Section 6.7.6. 796 Value type: A single URI value. It MAY also be reset to free-form 797 text. 799 Cardinality: *1 801 Example: 802 ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"] 804 7.9.5. "url" property 806 The "url" property has the intent of specifying a uniform resource 807 locator associated with the object the jCard represents. Reference 808 [RFC6350] Section 6.7.8. 810 There is potential security and privacy implications of providing 811 URLs with telephone calls. The end client receiving a jCard with a 812 URL property MUST only display the URL and not automatically follow 813 the URL or provide automatic preview of the URL, and generally 814 provide good practices in making it clear to the user it is their 815 choice to follow the URL in a browser context consistent with all of 816 the common browser security and privacy practices available on most 817 consumer OS environments. 819 Value type: A single uri value. 821 Cardinality: * 823 Example: 824 ["url", {}, "uri", "https://example.org/french-rest/chezchic.html"] 826 7.9.6. "version" property 828 The "version" property MUST be included and is intended to specify 829 the version of the vCard specification used to format this vCard. 830 Reference [RFC6350] Section 6.7.9. 832 Value type: A single text value. 834 Cardinality: 1 836 Example: 837 ["version", {}, "text", "4.0"] 839 8. Extension of jCard 841 Part of the intent of the usage of jCard is that it has its own 842 extensibility properties where new properties can be defined to relay 843 newly defined information related to a caller. This capability is 844 inherently supported as part of standard extensibility. However, 845 usage of those new properties should be published and registered 846 following [RFC7095] Section 3.6 or new specifications. 848 9. Acknowledgements 850 We would like to thank David Hancock, Alec Fenichel and other members 851 of the SIPCORE and STIR working group for helpful suggestions and 852 comments for the creation of this draft. 854 10. IANA Considerations 856 10.1. SIP Call-Info Header Field Purpose Token Request 858 [this RFC] defines the "jcard" token for use as a new token in the 859 Call-Info header in the "Header Field Parameters and Parameter 860 Values" registry defined by [RFC3968]. 862 +--------------+----------------+-------------------+------------+ 863 | Header Field | Parameter Name | Predefined Values | Reference | 864 +--------------+----------------+-------------------+------------+ 865 | Call-Info | jcard | No | [this RFC] | 866 +--------------+----------------+-------------------+------------+ 868 10.2. SIP Call-Info Header Field Purpose Token Request 870 [this RFC] defines the "call-reason" generic parameter for use as a 871 new parameter in the Call-Info header in the "Header Field Parameters 872 and Parameter Values" registry defined by [RFC3968]. The parameter's 873 token is "call-reason" and it takes the value of a quoted string. 875 11. Security Considerations 877 Revealing information such as the name, location, and affiliation of 878 a person necessarily entails certain privacy risks. SIP and Call- 879 Info has no particular confidentiality requirement, as the 880 information sent in SIP is in the clear anyway. Transport-level 881 security can be used to hide information from eavesdroppers, and the 882 same confidentiality mechanisms would protect any Call-Info or jCard 883 information carried or referred to in SIP. 885 The security framework of signing and providing integrity to this 886 data should be followed [I-D.ietf-stir-passport-rcd], with the idea 887 that the use of constraints and other certificate based associations 888 should be considered. This includes considerations around 889 information about the calling party being generally constant vs per 890 call data being more temporal. This also includes the relationship 891 that certificates with constraints presents to how they relate to 892 each other and how that information is managed, protected, and 893 associated with the correct call corresponding to a calling party. 895 12. Normative References 897 [I-D.ietf-stir-passport-rcd] 898 Wendt, C. and J. Peterson, "PASSporT Extension for Rich 899 Call Data", Work in Progress, Internet-Draft, draft-ietf- 900 stir-passport-rcd-14, 25 October 2021, 901 . 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, 906 DOI 10.17487/RFC2119, March 1997, 907 . 909 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 910 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 911 . 913 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 914 RFC 2426, DOI 10.17487/RFC2426, September 1998, 915 . 917 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 918 A., Peterson, J., Sparks, R., Handley, M., and E. 919 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 920 DOI 10.17487/RFC3261, June 2002, 921 . 923 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 924 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 925 . 927 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 928 RFC 3966, DOI 10.17487/RFC3966, December 2004, 929 . 931 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 932 (IANA) Header Field Parameter Registry for the Session 933 Initiation Protocol (SIP)", BCP 98, RFC 3968, 934 DOI 10.17487/RFC3968, December 2004, 935 . 937 [RFC4627] Crockford, D., "The application/json Media Type for 938 JavaScript Object Notation (JSON)", RFC 4627, 939 DOI 10.17487/RFC4627, July 2006, 940 . 942 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 943 Specifications: ABNF", STD 68, RFC 5234, 944 DOI 10.17487/RFC5234, January 2008, 945 . 947 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 948 DOI 10.17487/RFC6350, August 2011, 949 . 951 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 952 DOI 10.17487/RFC7095, January 2014, 953 . 955 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 956 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 957 . 959 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 960 J. Winterbottom, "Additional Data Related to an Emergency 961 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 962 . 964 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 965 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 966 May 2017, . 968 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 969 "Authenticated Identity Management in the Session 970 Initiation Protocol (SIP)", RFC 8224, 971 DOI 10.17487/RFC8224, February 2018, 972 . 974 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 975 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 976 . 978 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 979 Interchange Format", STD 90, RFC 8259, 980 DOI 10.17487/RFC8259, December 2017, 981 . 983 Authors' Addresses 985 Chris Wendt 986 Somos Inc. 987 United States of America 988 Email: chris-ietf@chriswendt.net 989 Jon Peterson 990 Neustar Inc. 991 1800 Sutter St Suite 570 992 Concord, CA 94520, 993 United States of America 994 Email: jon.peterson@neustar.biz