idnits 2.17.1 draft-wendt-sipcore-callinfo-rcd-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6919' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC7340' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-stir-passport-rcd-05 ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Downref: Normative reference to an Informational RFC: RFC 3324 ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wendt 3 Internet-Draft Comcast 4 Intended status: Standards Track J. Peterson 5 Expires: September 10, 2020 Neustar Inc. 6 March 09, 2020 8 SIP Call-Info Parameters for Rich Call Data 9 draft-wendt-sipcore-callinfo-rcd-01 11 Abstract 13 This document describes a SIP Call-Info usage defined to include rich 14 data associated with the identity of the calling party that can be 15 rendered to called party for providing more useful information about 16 the caller or the specific reason for the call. This includes 17 extended comprehensive information about the caller such as what a 18 jCard object can represent for describing the calling party or other 19 call specific information such as describing the reason or intent of 20 the call. The elements defined for this purpose are intended to be 21 extensible to accommodate related information about calls that helps 22 people decide whether to pick up the phone and additionally, with the 23 use of jCard and other elements, to be compatible with the STIR/ 24 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 September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. "jcard" Call-Info Token . . . . . . . . . . . . . . . . . . . 4 64 5. 'Reason' Call-Info Parameter . . . . . . . . . . . . . . . . 5 65 6. Usage of jCard and property specific usage . . . . . . . . . 6 66 6.1. Identification properties . . . . . . . . . . . . . . . . 6 67 6.1.1. "fn" property . . . . . . . . . . . . . . . . . . . . 6 68 6.1.2. "n" property . . . . . . . . . . . . . . . . . . . . 7 69 6.1.3. "nickname" property . . . . . . . . . . . . . . . . . 7 70 6.1.4. "photo" property . . . . . . . . . . . . . . . . . . 7 71 6.2. Delivery Addressing Properties . . . . . . . . . . . . . 7 72 6.2.1. "adr" property . . . . . . . . . . . . . . . . . . . 7 73 6.3. Communications Properties . . . . . . . . . . . . . . . . 8 74 6.3.1. "tel" property . . . . . . . . . . . . . . . . . . . 8 75 6.3.2. "email" property . . . . . . . . . . . . . . . . . . 8 76 6.3.3. "lang" property . . . . . . . . . . . . . . . . . . . 8 77 6.4. Geographical Properties . . . . . . . . . . . . . . . . . 9 78 6.4.1. "tz" property . . . . . . . . . . . . . . . . . . . . 9 79 6.4.2. "geo" property . . . . . . . . . . . . . . . . . . . 9 80 6.5. Organizational Properties . . . . . . . . . . . . . . . . 9 81 6.5.1. "title" property . . . . . . . . . . . . . . . . . . 9 82 6.5.2. "role" property . . . . . . . . . . . . . . . . . . . 9 83 6.5.3. "logo" property . . . . . . . . . . . . . . . . . . . 9 84 6.5.4. "org" property . . . . . . . . . . . . . . . . . . . 10 85 6.5.5. "member" property . . . . . . . . . . . . . . . . . . 10 86 6.5.6. "related" property . . . . . . . . . . . . . . . . . 10 87 6.6. Explanatory Properties . . . . . . . . . . . . . . . . . 10 88 6.6.1. "catagories" property . . . . . . . . . . . . . . . . 10 89 6.6.2. "note" property . . . . . . . . . . . . . . . . . . . 10 90 6.6.3. "sound" property . . . . . . . . . . . . . . . . . . 10 91 6.6.4. "uid" property . . . . . . . . . . . . . . . . . . . 10 92 6.6.5. "url" property . . . . . . . . . . . . . . . . . . . 10 93 7. Extension of jCard . . . . . . . . . . . . . . . . . . . . . 10 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 96 9.1. SIP Call-Info Header Field Purpose Token Request . . . . 11 97 9.2. SIP Call-Info Header Field Purpose Token Request . . . . 11 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 101 11.2. Informative References . . . . . . . . . . . . . . . . . 13 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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. The 113 same is true of information in the Call-Info header field. 115 To allow calling parties to initiate, and called parties to receive, 116 a more comprehensive, deterministic, and extensible rich call data 117 for incoming calls, we describe new tokens for the SIP [RFC3261] 118 Call-Info header field and a corresponding "purpose" parameter. We 119 also define a new parameter of Call-Info designed for carrying a 120 "reason" value. For this document, depending on the policies of the 121 communications system, calling parties could either be the end user 122 device or an originating service provider, and called parties could 123 also similarly be an end user device or the terminating service 124 provider acting on behalf of the recipient of the call. 126 Used on its own, this specification assumes that called party user 127 agent can trust the SIP network or the SIP provider to deliver the 128 correct rich call data (RCD) information. This may not always be the 129 case and thus, the entity inserting the Call-Info header field and 130 the UAS relying on it SHOULD be part of the same trust domain 131 [RFC3324]. Alternatively, and likely the recommended approach, is 132 that the entity inserting the call-info header should also sign the 133 caller information via STIR mechanisms [RFC8224] and specifically 134 through the [I-D.ietf-stir-passport-rcd]. This STIR signature would 135 likely be provided by the caller itself or the originating service 136 provider using an authoritative signature to authenticate the 137 information is from the originator and hasn't been tampered with in 138 transmission. 140 [RFC7852] provides a means of carrying additional data about callers 141 for the purposes of emergency services (especially its Section 4.4 142 "Owner/Subscriber" information). This specification provides an 143 overlapping functionality for non-emergency cases. Rather than 144 overloading its "EmergencyCallData" Call-Info "purpose" parameter 145 value, this document defines a separate "purpose" parameter for the 146 more generic delivery of information via jCard [RFC7095]. This 147 document borrows from [RFC7852] the capability to carry a data 148 structure as a body, through the use of the "cid" URI scheme 149 [RFC2392]. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Overview 161 The Call-Info header field, defined in [RFC3261] Section 20.9, 162 defines a purpose parameter currently with "info", "icon", and "card" 163 tokens. This document defines one new purpose value and one new 164 generic parameter for Call-Info. 166 First, the purpose value of "jcard" is to be used to associate rich 167 call data related to the identity of the calling party in the form of 168 a jCard [RFC7095]. While there is a "card" token that is already 169 defined with similar purpose, there are two primary reasons for the 170 definition and usage of jCard and the use of JSON over the XML based 171 vCard [RFC2426]. JSON has become the default and optimally supported 172 for transmission, parsing, and manipulation of data on IP networks. 173 jCard has also been defined in [I-D.ietf-stir-passport-rcd] and has 174 been adopted by PASSporT [RFC8225] because of the usage of JSON Web 175 Tokens (JWT) [RFC7519]. 177 Second, a generic parameter for "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 should include a URI where the resource pointed 190 to by the URI is a jCard JSON object defined in [RFC7095]. This MAY 191 be carried in the body of the SIP request bearing this Call-Info via 192 the "cid" URI scheme [RFC2392]. Alternatively, the URI MUST define 193 the use HTTPS or a transport that can validate the integrity of the 194 source of the resource as well as the transport channel the resource 195 is retrieved. 197 An example of a Call-Info header field is: 199 Call-Info: 201 An example jCard JSON file is shown as follows: 203 ["vcard", 204 [ 205 ["version", {}, "text", "4.0"], 206 ["fn", {}, "text", "James Bond"], 207 ["n", {}, "text", ["Bond", "James", "", "", "Mr."]], 208 ["adr", {"type":"work"}, "text", 209 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 210 "USA"] 211 ], 212 ["email", {}, "text", "007@mi6-hq.com"], 213 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 214 "tel:+1-202-555-1000"], 215 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"], 216 ["bday", {}, "date", "19241116"] 217 ["logo", {}, "uri", 218 "https://upload.wikimedia.org/wikipedia/en/c/c5/Fleming007impression.jpg"] 219 ] 220 ] 222 Examples using the "cid" URI scheme will follow in future versions of 223 this specification. 225 5. 'Reason' Call-Info Parameter 227 In addition to the jCard value defined here, this specification also 228 defines a generic parameter of the Call-Info header called "reason". 229 The "reason" parameter is intended to convey a short textual message 230 suitable for display to an end user during call alerting. As a 231 general guideline, this message SHOULD be no longer than ten words; 232 displays that support this specification may be forced to truncate 233 messages that cannot fit onto a screen. This message conveys the 234 caller's intention in contacting the callee. It is an optional 235 parameter, and the sender of a SIP request cannot guarantee that its 236 display will be supported by the terminating endpoint. The manner in 237 which this reason is set by the caller is outside the scope of this 238 specification. 240 One alternative approach would be to use the baseline [RFC3261] 241 Subject header field value to convey the reason for the call. 242 Because the Subject header has seen little historical use in SIP 243 implementations, however, and its specification describes its 244 potential use in filtering, it seems more prudent to define a new 245 means of carrying a call reason indication. 247 An example of a Call-Info header field value with the "reason" 248 parameter follows: 250 Call-Info: ;reason="Regarding your restaurant reservation" 252 One can readily imagine a need for more structured call reason data 253 that could be reliably processed automatically. Future versions of 254 this specification may explore ways to provide a structured data 255 object in place of a textual string to support things like 256 internationalization or categories of reason that can be parsed by 257 machines. 259 6. Usage of jCard and property specific usage 261 Beyond the definition of the specific properties or JSON arrays 262 associated with each property. This specification defines a few 263 rules above and beyond [RFC7095] specific to making sure there is a 264 mimimum level of supported properties that every implementation of 265 this specification should adhere to. This includes the support of 266 intepreting the value of this property and the ability to render in 267 some form appropriate to the display capabilities of the device. 268 This includes requirements specific to either textual displays and 269 graphics capable displays. 271 6.1. Identification properties 273 These types are used to capture information associated with the 274 identification and naming of the entity associated with the jCard. 276 6.1.1. "fn" property 278 The "fn" property MUST be supported with the intent of providing a 279 formatted text corresponding to the name of the object the jCard 280 represents. Reference [RFC6350] Section 6.2.1. 282 Example: 283 ["fn", {}, "text", "Mr. John Q. Public\, Esq."] 285 6.1.2. "n" property 287 The "n" property SHOULD be supported with the intent of providing the 288 components of the name of the object the jCard represents. Reference 289 [RFC6350] Section 6.2.2. 291 Example: 292 ["n", {}, "text", "Public;John;Quinlan;Mr.;Esq."] 293 ["n", {}, "text", "Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P."] 295 6.1.3. "nickname" property 297 The "nickname" property SHOULD be supported with the intent of 298 providing the text corresponding to the nickname of the object the 299 jCard represents. Reference [RFC6350] Section 6.2.3. 301 Example: 302 ["nickname", {}, "text", "Robbie"] 303 ["nickname", {}, "text", "Jim,Jimmie"] 304 ["nickname", {}, "text", "TYPE=work:Boss"] 306 6.1.4. "photo" property 308 The "photo" property MUST be supported with the intent of an image or 309 photograph information that annotates some aspect of the object the 310 jCard represents. Reference [RFC6350] Section 6.2.4. 312 In addition to the definition of jCard, and to promote 313 interoperability and proper formating and rendering of images, the 314 photo SHOULD correspond to a square image size of the sizes 128x128, 315 256x256, 512x512, or 1024x1024 pixels. 317 Example: 318 ["photo", {}, "uri", "http://www.example.com/pub/photos/jqpublic.gif"] 320 6.2. Delivery Addressing Properties 322 These properties are concerned with information related to the 323 delivery addressing or label for the jCard object. 325 6.2.1. "adr" property 327 The "adr" property MUST be supported with the intent of providing the 328 delivery address of the object the jCard represents. Reference 329 [RFC6350] Section 6.3.1. 331 Example: 332 ["adr", {"type":"work"}, "text", 333 ["", "", "3100 Massachusetts Avenue NW", "Washington", "DC", "20008", 334 "USA"] 336 6.3. Communications Properties 338 These properties describe information about how to communicate with 339 the object the jCard represents. 341 6.3.1. "tel" property 343 The "tel" property MUST be supported with the intent of providing the 344 telephone number for telephony communication of the object the jCard 345 represents. Reference [RFC6350] Section 6.4.1. 347 Relative to the SIP From header field this information may provide 348 alternate telephone number or other related telephone numbers for 349 other uses. 351 Example: 352 ["tel", { "type": ["voice", "text", "cell"], "pref": "1" }, "uri", 353 "tel:+1-202-555-1000"] 354 ["tel", { "type": ["fax"] }, "uri", "tel:+1-202-555-1001"] 356 6.3.2. "email" property 358 The "email" property MUST be supported with the intent of providing 359 the electronic mail address for communication of the object the jCard 360 represents. Reference [RFC6350] Section 6.4.2. 362 Example: 363 ["email", {"type":"work"}, "text", "jqpublic@xyz.example.com"] 364 ["email", {"pref":"1"}, "text", "jane_doe@example.com"] 366 6.3.3. "lang" property 368 The "lang" property MUST be supported with the intent of providing 369 the language(s) that may be used for contacting of the object the 370 jCard represents. Reference [RFC6350] Section 6.4.4. 372 Example: 373 ["lang", {"type":"work", "pref":"1"}, "language-tag", "en"] 374 ["lang", {"type":"work", "pref":"2"}, "language-tag", "fr"] 375 ["lang", {"type":"home"}, "language-tag", "fr"] 377 6.4. Geographical Properties 379 These properties are concerned with information associated with 380 geographical positions or regions associated with the object the 381 jCard represents. 383 6.4.1. "tz" property 385 The "tz" property MUST be supported with the intent of providing the 386 time zone of the object the jCard represents. Reference [RFC6350] 387 Section 6.5.1. 389 Editor Note: recommendations of representing Time Zone don't seem to 390 be clear. TBD. 392 Example: 393 ["tz", {}, "text", "Raleigh/North America"] 395 6.4.2. "geo" property 397 The "geo" property MUST be supported with the intent of providing the 398 global positioning of the object the jCard represents. Reference 399 [RFC6350] Section 6.5.2. 401 Example: 402 ["geo", {}, "uri", "geo:37.386013,-122.082932"] 404 6.5. Organizational Properties 406 These properties are concerned with information associated with 407 characteristics of the organization or organizational units of the 408 object that the jCard represents. 410 6.5.1. "title" property 412 text 414 6.5.2. "role" property 416 text 418 6.5.3. "logo" property 420 text 422 6.5.4. "org" property 424 text 426 6.5.5. "member" property 428 text 430 6.5.6. "related" property 432 text 434 6.6. Explanatory Properties 436 These properties are concerned with additional explanations, such as 437 that related to informational notes or revisions specific to the 438 jCard. 440 6.6.1. "catagories" property 442 ref 6.7.1 444 6.6.2. "note" property 446 ref 6.7.2 448 6.6.3. "sound" property 450 ref 6.7.5 (ringtone?) 452 6.6.4. "uid" property 454 ref 6.7.6 (origID like value?) 456 6.6.5. "url" property 458 ref 6.7.8 460 7. Extension of jCard 462 Part of the intent of the usage of jCard is that it has it's own 463 extensibility properties where new properties can be defined to relay 464 newly defined information related to a caller. This capability is 465 inherently supported as part of standard extensibility. However, 466 usage of those new properties should be published and registered 467 following [RFC7095] Section 3.6 or new specifications. 469 8. Acknowledgements 471 We would like to thank members of the STIR working group for helpful 472 suggestions and comments for the creation of this draft. 474 9. IANA Considerations 476 9.1. SIP Call-Info Header Field Purpose Token Request 478 [this RFC] defines the "jcard" token for use as a new token in the 479 Call-Info header in the "Header Field Parameters and Parameter 480 Values" registry defined by [RFC3968]. 482 +--------------+----------------+-------------------+------------+ 483 | Header Field | Parameter Name | Predefined Values | Reference | 484 +--------------+----------------+-------------------+------------+ 485 | Call-Info | jcard | No | [this RFC] | 486 +--------------+----------------+-------------------+------------+ 488 9.2. SIP Call-Info Header Field Purpose Token Request 490 [this RFC] defines the "reason" generic parameter for use as a new 491 parameter in the Call-Info header in the "Header Field Parameters and 492 Parameter Values" registry defined by [RFC3968]. The parameter's 493 token is "reason" and it takes the value of a quoted string. 495 10. Security Considerations 497 Revealing information such as the name, location, and affiliation of 498 a person necessarily entails certain privacy risks. SIP and Call- 499 Info has no particular confidentiality requirement, as the 500 information sent in SIP is in the clear anyway. Transport-level 501 security can be used to hide information from eavesdroppers, and the 502 same confidentiality mechanisms would protect any Call-Info or jCard 503 information carried or referred to in SIP. 505 11. References 507 11.1. Normative References 509 [I-D.ietf-stir-passport-rcd] 510 Peterson, J. and C. Wendt, "PASSporT Extension for Rich 511 Call Data", draft-ietf-stir-passport-rcd-05 (work in 512 progress), November 2019. 514 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 515 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 516 . 518 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 519 RFC 2426, DOI 10.17487/RFC2426, September 1998, 520 . 522 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 523 A., Peterson, J., Sparks, R., Handley, M., and E. 524 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 525 DOI 10.17487/RFC3261, June 2002, 526 . 528 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 529 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 530 . 532 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 533 (IANA) Header Field Parameter Registry for the Session 534 Initiation Protocol (SIP)", BCP 98, RFC 3968, 535 DOI 10.17487/RFC3968, December 2004, 536 . 538 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 539 DOI 10.17487/RFC6350, August 2011, 540 . 542 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 543 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 544 DOI 10.17487/RFC6919, April 2013, 545 . 547 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 548 DOI 10.17487/RFC7095, January 2014, 549 . 551 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 552 Telephone Identity Problem Statement and Requirements", 553 RFC 7340, DOI 10.17487/RFC7340, September 2014, 554 . 556 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 557 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 558 . 560 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 561 J. Winterbottom, "Additional Data Related to an Emergency 562 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 563 . 565 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 566 "Authenticated Identity Management in the Session 567 Initiation Protocol (SIP)", RFC 8224, 568 DOI 10.17487/RFC8224, February 2018, 569 . 571 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 572 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 573 . 575 11.2. Informative References 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, 579 DOI 10.17487/RFC2119, March 1997, 580 . 582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 584 May 2017, . 586 Authors' Addresses 588 Chris Wendt 589 Comcast 590 Comcast Technology Center 591 Philadelphia, PA 19103 592 USA 594 Email: chris-ietf@chriswendt.net 596 Jon Peterson 597 Neustar Inc. 598 1800 Sutter St Suite 570 599 Concord, CA 94520 600 US 602 Email: jon.peterson@neustar.biz