idnits 2.17.1 draft-ietf-sipcore-callinfo-rcd-02.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 (February 22, 2021) is 1158 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-09 ** 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: August 26, 2021 Neustar Inc. 6 February 22, 2021 8 SIP Call-Info Parameters for Rich Call Data 9 draft-ietf-sipcore-callinfo-rcd-02 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 August 26, 2021. 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 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. Usage of URIs in jCard . . . . . . . . . . . . . . . . . 7 67 6.2. Usage of multimedia data in jCard . . . . . . . . . . . . 8 68 6.3. Cardinality . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.4. Identification properties . . . . . . . . . . . . . . . . 9 70 6.4.1. "fn" property . . . . . . . . . . . . . . . . . . . . 9 71 6.4.2. "n" property . . . . . . . . . . . . . . . . . . . . 10 72 6.4.3. "nickname" property . . . . . . . . . . . . . . . . . 10 73 6.4.4. "photo" property . . . . . . . . . . . . . . . . . . 10 74 6.5. Delivery Addressing Properties . . . . . . . . . . . . . 11 75 6.5.1. "adr" property . . . . . . . . . . . . . . . . . . . 11 76 6.6. Communications Properties . . . . . . . . . . . . . . . . 11 77 6.6.1. "tel" property . . . . . . . . . . . . . . . . . . . 11 78 6.6.2. "email" property . . . . . . . . . . . . . . . . . . 12 79 6.6.3. "lang" property . . . . . . . . . . . . . . . . . . . 12 80 6.7. Geographical Properties . . . . . . . . . . . . . . . . . 12 81 6.7.1. "tz" property . . . . . . . . . . . . . . . . . . . . 13 82 6.7.2. "geo" property . . . . . . . . . . . . . . . . . . . 13 83 6.8. Organizational Properties . . . . . . . . . . . . . . . . 13 84 6.8.1. "title" property . . . . . . . . . . . . . . . . . . 13 85 6.8.2. "role" property . . . . . . . . . . . . . . . . . . . 14 86 6.8.3. "logo" property . . . . . . . . . . . . . . . . . . . 14 87 6.8.4. "org" property . . . . . . . . . . . . . . . . . . . 14 88 6.9. Explanatory Properties . . . . . . . . . . . . . . . . . 15 89 6.9.1. "categories" property . . . . . . . . . . . . . . . . 15 90 6.9.2. "note" property . . . . . . . . . . . . . . . . . . . 15 91 6.9.3. "sound" property . . . . . . . . . . . . . . . . . . 15 92 6.9.4. "uid" property . . . . . . . . . . . . . . . . . . . 16 93 6.9.5. "url" property . . . . . . . . . . . . . . . . . . . 16 94 6.9.6. "version" property . . . . . . . . . . . . . . . . . 17 95 7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 17 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 9.1. SIP Call-Info Header Field Purpose Token Request . . . . 17 99 9.2. SIP Call-Info Header Field Purpose Token Request . . . . 17 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 103 11.2. Informative References . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 Traditional telephone network signaling protocols have long supported 109 delivering a 'calling name' from the originating side, though in 110 practice, the terminating side is often left to derive a name from 111 the calling party number by consulting a local address book or an 112 external database. SIP similarly can carry a 'display-name' in the 113 From header field value from the originating to terminating side, 114 though it is an unsecured field that is not commonly trusted. The 115 same is true of information in the Call-Info header field. 117 To allow calling parties to initiate, and called parties to receive, 118 a more comprehensive, deterministic, and extensible rich call data 119 for incoming calls, we describe new tokens for the SIP [RFC3261] 120 Call-Info header field and a corresponding "purpose" parameter. We 121 also define a new parameter of Call-Info designed for carrying a 122 "reason" value. For this document, depending on the policies of the 123 communications system, calling parties could either be the end user 124 device or an originating service provider, and called parties could 125 also similarly be an end user device or the terminating service 126 provider acting on behalf of the recipient of the call. 128 Used on its own, this specification assumes that the called party 129 user agent can trust the SIP network or the SIP provider to deliver 130 the correct rich call data (RCD) information. This may not always be 131 the case and thus, the entity inserting the Call-Info header field 132 and the UAS relying on it SHOULD be part of the same trust domain 133 [RFC3324]. Alternatively, and likely the recommended approach, the 134 entity inserting the Call-Info header field should also sign the 135 caller information via STIR mechanisms [RFC8224] and specifically 136 through the [I-D.ietf-stir-passport-rcd]. This STIR signature would 137 likely be provided by the caller itself or the originating service 138 provider using an authoritative signature to authenticate the 139 information is from the originator and hasn't been tampered with in 140 transmission. 142 [RFC7852] provides a means of carrying additional data about callers 143 for the purposes of emergency services (especially its Section 4.4 144 "Owner/Subscriber" information). This specification provides an 145 overlapping functionality for non-emergency cases. Rather than 146 overloading its "EmergencyCallData" Call-Info "purpose" parameter 147 value, this document defines a separate "purpose" parameter for the 148 more generic delivery of information via jCard [RFC7095]. This 149 document borrows from [RFC7852] the capability to carry a data 150 structure as a body, through the use of the "cid" URI scheme 151 [RFC2392]. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 3. Overview 163 The Call-Info header field, defined in [RFC3261] Section 20.9, 164 defines a purpose parameter currently with "info", "icon", and "card" 165 tokens. This document defines one new purpose value and one new 166 generic parameter for Call-Info. 168 The value "jcard" is to be used to associate rich call data related 169 to the identity of the calling party in the form of a jCard 170 [RFC7095]. While there is a "card" token that is already defined 171 with similar purpose, there are two primary reasons for the 172 definition and usage of jCard and the use of JSON over the XML based 173 vCard [RFC2426]. First, JSON has become the default and is generally 174 the widely accepted optimally supported format for transmission, 175 parsing, and manipulation of data on IP networks. Second, jCard has 176 also been defined in [I-D.ietf-stir-passport-rcd] and has been 177 adopted by PASSporT [RFC8225] because of the usage of JSON Web Tokens 178 (JWT) [RFC7519]. 180 A generic parameter for "call-reason" is to be used to provide a 181 string or other object that is used to convey the intent or reason 182 the caller is calling to help the called party understand better the 183 context of the call and why they may want to answer the call. 185 4. "jcard" Call-Info Token 187 The use of the new Call-Info Token "jcard" is for the purpose of 188 supporting RCD associated with the identity of a calling party in a 189 SIP call [RFC3261] Section 20.9. The format of a Call-Info header 190 field when using the "jcard" is as follows. 192 The Call-Info header field is defined to include a URI, where here 193 the resource pointed to by the URI is a jCard JSON object [RFC7095]. 194 The web server serving this file MUST use the MIME media type for 195 JSON text as application/json with a default encoding of UTF-8 196 [RFC4627]. A jCard also MAY be carried in the body of the SIP 197 request bearing this Call-Info via the "cid" URI scheme [RFC2392]. 198 Alternatively, the URI MUST define the use HTTPS or a transport that 199 can validate the integrity of the source of the resource as well as 200 the transport channel through which the resource is retrieved. 202 An example of a Call-Info header field is: 204 Call-Info: ;purpose=jcard 206 An example contents of a URL linked jCard JSON file is shown as 207 follows: 209 ["vcard", 210 [ 211 ["version",{},"text","4.0"], 212 ["fn",{},"text","Q Branch"], 213 ["org",{},"text","MI6;Q Branch Spy Gadgets"], 214 ["photo",{},"uri","https://example.com/photos/q-256x256.png"], 215 ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"], 216 ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"] 217 ] 218 ] 220 An example SIP INVITE using the "cid" URI scheme is as follows. 222 INVITE sip:alice@example.com SIP/2.0 223 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 224 To: Alice 225 From: Bob ;tag=1928301774> 226 Call-ID: a84b4c76e66710 227 Call-Info: ;purpose=jcard;call-reason= \ 228 "Rendezvous for Little Nellie" 229 CSeq: 314159 INVITE 230 Max-Forwards: 70 231 Date: Fri, 25 Sep 2015 19:12:25 GMT 232 Contact: 233 Content-Type: multipart/mixed; boundary=boundary1 234 Content-Length: ... 236 --boundary1 238 Content-Type: application/sdp 240 v=0 241 o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 242 s=Session SDP 243 c=IN IP4 pc33.atlanta.example.com 244 t=0 0 245 m=audio 49172 RTP/AVP 0 246 a=rtpmap:0 PCMU/8000 248 --boundary1 250 Content-Type: application/vcard+json 251 Content-ID: <12155551000@example.com> 253 ["vcard",[["version",{},"text","4.0"],["fn",{},"text","Q Branch"], 254 ["org",{},"text","MI6;Q Branch Spy Gadgets"],["photo",{},"uri","ht 255 tps://example.com/photos/quartermaster-256x256.png"],["logo",{},"u 256 ri","https://example.com/logos/mi6-256x256.jpg"],["logo",{},"uri", 257 "https://example.com/logos/mi6-64x64.jpg"]]] 259 5. "call-reason" Call-Info Parameter 261 In addition to the jCard value defined here, this specification also 262 defines a generic parameter of the Call-Info header called "call- 263 reason". The "call-reason" parameter is intended to convey a short 264 textual message suitable for display to an end user during call 265 alerting. As a general guideline, this message SHOULD be no longer 266 than 64 characters; displays that support this specification may be 267 forced to truncate messages that cannot fit onto a screen. This 268 message conveys the caller's intention in contacting the callee. It 269 is an optional parameter, and the sender of a SIP request cannot 270 guarantee that its display will be supported by the terminating 271 endpoint. The manner in which this reason is set by the caller is 272 outside the scope of this specification. 274 One alternative approach would be to use the baseline [RFC3261] 275 Subject header field value to convey the reason for the call. 276 Because the Subject header has seen little historical use in SIP 277 implementations, however, and its specification describes its 278 potential use in filtering, it seems more prudent to define a new 279 means of carrying a call reason indication. 281 An example of a Call-Info header field value with the "call-reason" 282 parameter follows: 284 Call-Info: ;purpose=jcard; 285 call-reason="For your ears only" 287 One can readily imagine a need for more structured call reason data 288 that could be reliably processed automatically. Future versions of 289 this specification may explore ways to provide a structured data 290 object in place of a textual string to support things like 291 internationalization or categories of reason that can be parsed by 292 machines. 294 6. Usage of jCard and property specific usage 296 Beyond the definition of the specific properties or JSON arrays 297 associated with each property. This specification defines a few 298 rules above and beyond [RFC7095] specific to the use of jCard for 299 Call-Info and Rich Call Data making sure there is a minimum level of 300 supported properties that every implementation of this specification 301 should adhere to. This includes support for interpreting the value 302 of this property and the ability to render in some appropriate form 303 the display capabilities of common telephone devices, as well as 304 apps, and also includes requirements specific to either textual 305 displays and graphics capable displays. 307 6.1. Usage of URIs in jCard 309 When one or more URIs are used in a jCard, it is important to note 310 that any URI referenced data, with the exception of the top-level 311 usage of "jcl" as a URI to the jCard itself (unless updated by any 312 future extensions of this specification) MUST not contain any URI 313 references. In other words, the jCard can have URI references as 314 defined in the jCard specification and this document, but the content 315 referenced by those URIs MUST NOT have any URIs, and therefore MUST 316 be enforced by the client to fail verification or not render content 317 to the user if any URI are present in that specific URI linked 318 content. The purpose of this is to control the security and more 319 specifically align with the content integrity mechanism defined in 320 [I-D.ietf-stir-passport-rcd]. It is the belief of the authors that 321 there isn't a scenario that deeper URI references would be required 322 or even supported by the current set of properties for the typical 323 use of jCard properties, but because jCard is extensible, this rule 324 is set to restrict further extension without the proper consideration 325 of security and integrity properties of both Call-Info usage as well 326 as the Rich Call Data and STIR signing of the data 327 [I-D.ietf-stir-passport-rcd], [RFC8224]. 329 6.2. Usage of multimedia data in jCard 331 There are a few cases where jCards incorporate URIs or directly 332 include via Base64 encoding of digital images and sounds. We specify 333 a few recommended conventions to facilitate more consistent support 334 of the successful rendering of these images. 336 For images, such as for the photo and logo properties, the default 337 image formats should be png or jpg. These files are mostly commonly 338 used to support 24-bit RGB images which should consequently be the 339 default. There are some older telephone devices that may only 340 support bmp type of images with lower bit-range (e.g. 16-bit or 8-bit 341 or 1-bit), also with potentially only grayscale or 1-bit black and 342 white color displays. These exceptions are considered optional to 343 support. 345 For the cases where image files are referenced by URIs as file 346 resources, this document defines a character string that SHOULD be 347 concatenated on to the end of a file name, before the file extension 348 that signals the height and width of the image to the end device for 349 the convenience of determining the appropriate resolution to retrieve 350 without the need to retrieve all the image files. It is also 351 recommended that images are square ratio formatted with equal height 352 and width and with a power of two value for the number of pixels 353 (e.g. 32x32, 128x128, 512x512). The format of the string should be 354 "filename-HxW" where filename represents the unique string 355 representing the file and H represents the height in pixels and W 356 represents the width in pixels. If the file is not to be rendered 357 using the default 24-bit RGB pixel format, additionally the string 358 can be extended to include bit depth and number of colors. That 359 string should be formatted as "filename-HxW-bd-c", where bd is the 360 bit depth (e.g. 1, 8, 16) and c represents number of color channels 361 which should either be 1 or 3. Note: 32-bit/RGBA color format is 362 specifically not recommended for this document because transparency 363 would not be clear how to render for display. 365 For audio files, the recommendation is to provide mp3, m4a, or wav 366 files, although the usage of sound is not well defined in this 367 specification as, for example, a special ring tone for a particular 368 caller, and future documents should consider both usage and potential 369 security risks of playing sounds that are not specifically authorized 370 by a device user. 372 6.3. Cardinality 374 Property cardinalities are indicated, for convenience, using the 375 following notation and follow the guidance of jCard [RFC7095] and 376 vCard [RFC6350], which is based on ABNF (see [RFC5234], Section 3.6): 378 +-------------+--------------------------------------------------+ 379 | Cardinality | Meaning | 380 +-------------+--------------------------------------------------+ 381 | 1 | Exactly one instance per jCard MUST be present. | 382 | *1 | Exactly one instance per jCard MAY be present. | 383 | 1* | One or more instances per jCard MUST be present. | 384 | * | One or more instances per jCard MAY be present. | 385 +-------------+--------------------------------------------------+ 387 6.4. Identification properties 389 These types are used to capture information associated with the 390 identification and naming of the entity associated with the jCard. 391 They are initially defined in [RFC6350], but the following list of 392 properties included and repeated in this Section is a subset of the 393 properties defined for jCard with properties selected for this 394 document that have relevance to telephone and messaging applications. 395 jCard is an extensible object and therefore, there may also be future 396 specifications that extend the set of properties that may be relevant 397 to the set of communications applications that utilize this 398 specification. 400 6.4.1. "fn" property 402 The "fn" property has the intent of providing a formatted text 403 corresponding to the name of the object the jCard represents. 404 Reference [RFC6350] Section 6.2.1. 406 Value type: A single text value. 408 Cardinality: 1* 410 Example: 411 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 413 6.4.2. "n" property 415 The "n" property has the intent of providing the components of the 416 name of the object the jCard represents. Reference [RFC6350] 417 Section 6.2.2. 419 Value type: A single structured text value. Each component can have 420 multiple values. 422 Cardinality: *1 424 Example: 425 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 426 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 428 6.4.3. "nickname" property 430 The "nickname" property has the intent of providing the text 431 corresponding to the nickname of the object the jCard represents. 432 Reference [RFC6350] Section 6.2.3. 434 Value type: One or more text values separated by a COMMA character 435 (U+002C). 437 Cardinality: * 439 Example: 440 ["nickname", {}, "text", "Robbie"] 441 ["nickname", {}, "text", "Jim,Jimmie"] 442 ["nickname", {}, "text", "TYPE=work:Boss"] 444 6.4.4. "photo" property 446 The "photo" property has the intent of supplying an image or 447 photograph information that annotates some aspect of the object the 448 jCard represents. Reference [RFC6350] Section 6.2.4. 450 In addition to the definition of jCard, and to promote 451 interoperability and proper formatting and rendering of images, the 452 photo SHOULD correspond to a square image size of the sizes 128x128, 453 256x256, 512x512, or 1024x1024 pixels. 455 Value type: A single URI. 457 Cardinality: * 459 Example: 460 ["photo", {}, "uri", "http://www.example.com/jqpublic-256x256.png"] 462 6.5. Delivery Addressing Properties 464 These properties are concerned with information related to the 465 delivery addressing or label for the jCard object. 467 6.5.1. "adr" property 469 The "adr" property has the intent of providing the delivery address 470 of the object the jCard represents. Reference [RFC6350] 471 Section 6.3.1. 473 Value type: A single structured text value, separated by the 474 SEMICOLON character (U+003B). 476 Cardinality: * 478 Example: 479 ["adr", {"type":"work"}, "text", 480 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", 481 "20008", "USA"] 483 6.6. Communications Properties 485 These properties describe information about how to communicate with 486 the object the jCard represents. 488 6.6.1. "tel" property 490 The "tel" property has the intent of providing the telephone number 491 for telephony communication of the object the jCard represents. 492 Reference [RFC6350] Section 6.4.1. 494 Relative to the SIP From header field value this information may 495 provide alternate telephone number or other related telephone numbers 496 for other uses. 498 It is important to note that any of the potential instances of the 499 "tel" property should not be considered part of the authentication or 500 verification part of STIR [RFC8224] or required to match the "orig" 501 claim in the PASSporT [RFC8225]. These telephone numbers should be 502 considered for contact, fax, or other purposes aligned with the 503 general usage of jCard and vCard, although consideration of confusing 504 the caller with different contact telephone number information versus 505 the actual verified telephone number should be made from a general 506 policy point of view. 508 Value type: By default, it is a single free-form text value (for 509 backward compatibility with vCard 3), but it SHOULD be reset to a URI 510 value. It is expected that the URI scheme will be "tel", as 511 specified in [RFC3966], but other schemes MAY be used. 513 Cardinality: * 515 Example: 516 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 517 "tel:+1-202-555-1000"] 518 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 520 6.6.2. "email" property 522 The "email" property has the intent of providing the electronic mail 523 address for communication of the object the jCard represents. 524 Reference [RFC6350] Section 6.4.2. 526 Value type: A single text value. 528 Cardinality: * 530 Example: 531 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 532 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 534 6.6.3. "lang" property 536 The "lang" property has the intent of providing the language(s) that 537 may be used for contacting of the object the jCard represents. 538 Reference [RFC6350] Section 6.4.4. 540 Value type: A single language-tag value. 542 Cardinality: * 544 Example: 545 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 546 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 547 ["lang", {"type":"home"}, "language-tag", "fr"] 549 6.7. Geographical Properties 551 These properties are concerned with information associated with 552 geographical positions or regions associated with the object the 553 jCard represents. 555 6.7.1. "tz" property 557 The "tz" property has the intent of providing the time zone of the 558 object the jCard represents. Reference [RFC6350] Section 6.5.1. 560 Note: the up-to-date reference for where time-zone names are 561 maintained is, at the authoring of this document, at this web 562 address, https://www.iana.org/time-zones. 564 Value type: The default is a single text value. It can also be reset 565 to a single URI or utc-offset value. 567 Cardinality: * 569 Example: 570 ["tz", {}, "text", "Raleigh/North America"] 572 6.7.2. "geo" property 574 The "geo" property has the intent of providing the global positioning 575 of the object the jCard represents. Reference [RFC6350] 576 Section 6.5.2. 578 Value type: A single URI. 580 Cardinality: * 582 Example: 583 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 585 6.8. Organizational Properties 587 These properties are concerned with information associated with 588 characteristics of the organization or organizational units of the 589 object that the jCard represents. 591 6.8.1. "title" property 593 The "title" property has the intent of providing the position or job 594 of the object the jCard represents. Reference [RFC6350] 595 Section 6.6.1. 597 Value type: A single text value. 599 Cardinality: * 601 Example: 602 ["title", {}, "text", "Research Scientist"] 604 6.8.2. "role" property 606 The "role" property has the intent of providing the position or job 607 of the object the jCard represents. Reference [RFC6350] 608 Section 6.6.2. 610 Value type: A single text value. 612 Cardinality: * 614 Example: 615 ["role", {}, "text", "Project Leader"] 617 6.8.3. "logo" property 619 The "logo" property has the intent of specifying a graphic image of a 620 logo associated with the object the jCard represents. Reference 621 [RFC6350] Section 6.6.3. 623 Value type: A single URI. 625 Cardinality: * 627 Example: 628 ["logo", {}, "uri", "http://www.example.com/abccorp-512x512.jpg"] 630 ["logo", {}, "uri", "data:image/jpeg;base64,MIICajCCAdOgAwIBAgIC 631 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 632 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 633 <...the remainder of base64-encoded data...>"] 635 6.8.4. "org" property 637 The "org" property has the intent of specifying the organizational 638 name and units of the object the jCard represents. Reference 639 [RFC6350] Section 6.6.2. 641 Value type: A single structured text value consisting of components 642 separated by the SEMICOLON character (U+003B). 644 Cardinality: * 646 Example: 647 ["org", {}, "text", "ABC\, Inc.;North American Division;Marketing"] 649 6.9. Explanatory Properties 651 These properties are concerned with additional explanations, such as 652 that related to informational notes or revisions specific to the 653 jCard. 655 6.9.1. "categories" property 657 The "categories" property has the intent of specifying application 658 category information about the object the jCard represents. 659 Reference [RFC6350] Section 6.7.1. 661 Value type: One or more text values separated by a COMMA character 662 (U+002C). 664 Cardinality: * 666 Example: 667 ["categories", {}, "text", "TRAVEL AGENT"] 669 ["categories", {}, "text", "INTERNET,IETF,INDUSTRY"] 671 6.9.2. "note" property 673 The "note" property has the intent of specifying supplemental 674 information or a comment about the object the jCard represents. 675 Reference [RFC6350] Section 6.7.2. 677 Value type: A single text value. 679 Cardinality: * 681 Example: 682 ["note", {}, "text", "This fax number is operational 0800 to 1715 683 EST\, Mon-Fri."] 685 6.9.3. "sound" property 687 The "sound" property has the intent of specifying a digital sound 688 content information that annotates some aspect of the object the 689 jCard represents. This property is often used to specify the proper 690 pronunciation of the name property value of the jCard. Reference 691 [RFC6350] Section 6.7.5. 693 Value type: A single URI. 695 Cardinality: * 696 Example: 697 ["sound", {}, "uri", "http://www.example.com/pub/logos/abccorp.mp3"] 699 ["sound", {}, "uri", "data:audio/basic;base64,MIICajCCAdOgAwIBAgICBE 700 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 701 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 702 <...the remainder of base64-encoded data...>"] 704 6.9.4. "uid" property 706 The "uid" property has the intent of specifying a globally unique 707 identifier corresponding to the object the jCard represents. 708 Reference [RFC6350] Section 6.7.6. 710 Value type: A single URI value. It MAY also be reset to free-form 711 text. 713 Cardinality: *1 715 Example: 716 ["uid", {}, "uri", "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"] 718 6.9.5. "url" property 720 The "url" property has the intent of specifying a uniform resource 721 locator associated with the object the jCard represents. Reference 722 [RFC6350] Section 6.7.8. 724 There is potential security and privacy implications of providing 725 URLs with telephone calls. The end client receiving a jCard with a 726 URL property MUST only display the URL and not automatically follow 727 the URL or provide automatic preview of the URL, and generally 728 provide good practices in making it clear to the user it is their 729 choice to follow the URL in a browser context consistent with all of 730 the common browser security and privacy practices available on most 731 consumer OS environments. 733 Value type: A single uri value. 735 Cardinality: * 737 Example: 738 ["url", {}, "uri", "https://example.org/french-rest/chezchic.html"] 740 6.9.6. "version" property 742 The "version" property MUST be included and is intended to specify 743 the version of the vCard specification used to format this vCard. 744 Reference [RFC6350] Section 6.7.9. 746 Value type: A single text value. 748 Cardinality: 1 750 Example: 751 ["version", {}, "text", "4.0"] 753 7. Extension of jCard 755 Part of the intent of the usage of jCard is that it has its own 756 extensibility properties where new properties can be defined to relay 757 newly defined information related to a caller. This capability is 758 inherently supported as part of standard extensibility. However, 759 usage of those new properties should be published and registered 760 following [RFC7095] Section 3.6 or new specifications. 762 8. Acknowledgements 764 We would like to thank David Hancock and other members of the STIR 765 working group for helpful suggestions and comments for the creation 766 of this draft. 768 9. IANA Considerations 770 9.1. SIP Call-Info Header Field Purpose Token Request 772 [this RFC] defines the "jcard" token for use as a new token in the 773 Call-Info header in the "Header Field Parameters and Parameter 774 Values" registry defined by [RFC3968]. 776 +--------------+----------------+-------------------+------------+ 777 | Header Field | Parameter Name | Predefined Values | Reference | 778 +--------------+----------------+-------------------+------------+ 779 | Call-Info | jcard | No | [this RFC] | 780 +--------------+----------------+-------------------+------------+ 782 9.2. SIP Call-Info Header Field Purpose Token Request 784 [this RFC] defines the "call-reason" generic parameter for use as a 785 new parameter in the Call-Info header in the "Header Field Parameters 786 and Parameter Values" registry defined by [RFC3968]. The parameter's 787 token is "call-reason" and it takes the value of a quoted string. 789 10. Security Considerations 791 Revealing information such as the name, location, and affiliation of 792 a person necessarily entails certain privacy risks. SIP and Call- 793 Info has no particular confidentiality requirement, as the 794 information sent in SIP is in the clear anyway. Transport-level 795 security can be used to hide information from eavesdroppers, and the 796 same confidentiality mechanisms would protect any Call-Info or jCard 797 information carried or referred to in SIP. 799 11. References 801 11.1. Normative References 803 [I-D.ietf-stir-passport-rcd] 804 Peterson, J. and C. Wendt, "PASSporT Extension for Rich 805 Call Data", draft-ietf-stir-passport-rcd-09 (work in 806 progress), November 2020. 808 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 809 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 810 . 812 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 813 RFC 2426, DOI 10.17487/RFC2426, September 1998, 814 . 816 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 817 A., Peterson, J., Sparks, R., Handley, M., and E. 818 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 819 DOI 10.17487/RFC3261, June 2002, 820 . 822 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 823 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 824 . 826 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 827 RFC 3966, DOI 10.17487/RFC3966, December 2004, 828 . 830 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 831 (IANA) Header Field Parameter Registry for the Session 832 Initiation Protocol (SIP)", BCP 98, RFC 3968, 833 DOI 10.17487/RFC3968, December 2004, 834 . 836 [RFC4627] Crockford, D., "The application/json Media Type for 837 JavaScript Object Notation (JSON)", RFC 4627, 838 DOI 10.17487/RFC4627, July 2006, 839 . 841 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 842 Specifications: ABNF", STD 68, RFC 5234, 843 DOI 10.17487/RFC5234, January 2008, 844 . 846 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 847 DOI 10.17487/RFC6350, August 2011, 848 . 850 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 851 DOI 10.17487/RFC7095, January 2014, 852 . 854 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 855 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 856 . 858 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 859 J. Winterbottom, "Additional Data Related to an Emergency 860 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 861 . 863 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 864 "Authenticated Identity Management in the Session 865 Initiation Protocol (SIP)", RFC 8224, 866 DOI 10.17487/RFC8224, February 2018, 867 . 869 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 870 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 871 . 873 11.2. Informative References 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, 877 DOI 10.17487/RFC2119, March 1997, 878 . 880 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 881 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 882 May 2017, . 884 Authors' Addresses 886 Chris Wendt 887 Comcast 888 Comcast Technology Center 889 Philadelphia, PA 19103 890 USA 892 Email: chris-ietf@chriswendt.net 894 Jon Peterson 895 Neustar Inc. 896 1800 Sutter St Suite 570 897 Concord, CA 94520 898 US 900 Email: jon.peterson@neustar.biz