idnits 2.17.1 draft-mahy-dispatch-immi-content-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-mls-protocol-12 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch R. Mahy 3 Internet-Draft Wire 4 Intended status: Informational 7 March 2022 5 Expires: 8 September 2022 7 Inside MLS Message Interop (IMMI) instant message content 8 draft-mahy-dispatch-immi-content-00 10 Abstract 12 This document defines a profile intended for instant messaging 13 interoperability of messages end-to-end encrypted inside the MLS 14 (Message Layer Security) Protocol. It adapts prior work (CPIM) to 15 work well in the MLS context. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 8 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Naming schemes . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Negotiation of MIME types . . . . . . . . . . . . . . . . 4 55 3.3. CPIM and MIME headers . . . . . . . . . . . . . . . . . . 5 56 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Original Message . . . . . . . . . . . . . . . . . . . . 6 58 4.2. Reply . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.3. Reaction . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.4. Mentions . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.5. Edit . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.6. Delete . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.7. Expiring . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.8. Knock . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.9. Read Receipt . . . . . . . . . . . . . . . . . . . . . . 10 66 4.10. Attachments . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.11. Conferencing . . . . . . . . . . . . . . . . . . . . . . 11 68 5. IMMI CPIM profile . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. CPIM headers . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. Definition of message/immi-disposition-notification . . . 12 71 5.3. Required and Recommended MIME types . . . . . . . . . . . 13 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. MIME subtype registration of message/ 74 immi-disposition-notification . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 77 9. Informative References . . . . . . . . . . . . . . . . . . . 14 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2219]. 86 The terms MLS client, MLS group, and KeyPackage have the same 87 meanings as in the MLS protocol [I-D.ietf-mls-protocol]. 89 2. Introduction 91 MLS [I-D.ietf-mls-protocol] is a group key establishment protocol 92 motivated by the desire for group chat with efficient end-to-end 93 encryption. While one of the motivations of MLS is interoperable 94 standards-based secure messaging, the MLS protocol does not define or 95 prescribe any format for the encrypted "application messages" encoded 96 by MLS. The development of MLS was strongly motivated by the needs 97 of a number of Instant Messaging (IM) systems, which encrypt messages 98 end-to-end using variations of the Double Ratchet protocol []. 100 End-to-end encrypted instant messaging was also a motivator for the 101 Common Protocol for Instant Messaging (CPIM) [RFC3862], however the 102 model used at the time assumed standalone encryption of each message 103 using a protocol such as S/MIME [RFC8551] or PGP [RFC3156] to 104 interoperate between IM protocols such as SIP [RFC3261] and XMPP 105 [RFC6120]. For a variety of practical reasons, interoperable end-to- 106 end encryption between IM systems was never deployed commercially. 108 There are now several vendors prepared to implement MLS. In order to 109 enable interoperable messaging conveyed "inside" MLS application 110 messages, some additional specification and some minor changes are 111 required. Also, the expectation of what constitutes basic features 112 common across multiple IM systems has grown. It would be beneficial 113 to provide an interoperable format for these additional features as 114 well. Most of these features can be implemented using a profile 115 which describes how to use already-defined URIs, message headers, and 116 MIME types. 118 This proposal assumes that MLS clients can advertise MIME types they 119 support and that MLS clients can determine what MIME types are 120 required to join a specific MLS group. A companion proposal 121 [I-D.mahy-dispatch-immi-mls-mime] defines two MLS extensions which 122 meets this requirement. It would allow implementations to define 123 groups with different MIME type requirements and it would allow MLS 124 clients to send extended or proprietary messages that would be 125 interpreted by some members of the group while assuring that an 126 interoperable end-to-end encrypted baseline is available to all 127 members, even when the group spans multiple systems or vendors. 129 Below is a list of some features commonly found in IM group chat 130 systems: 132 * plain text and rich text messaging 133 * delivery notifications 134 * read receipts 135 * replies 136 * reactions 137 * edit or delete previously sent messages 138 * expiring messages 139 * knock / ping 140 * shared files/audio/videos 141 * calling / conferencing 143 3. Overview 145 3.1. Naming schemes 147 IM systems have a number of types of identifiers. Not all systems 148 use every type: 150 * client/device identifier (internal representation) 151 * user identifier 152 * handle identifier (external, friendly representation) 153 * group conversation identifier 154 * group or or channel name (external, friendly representation) 155 * team identifier (less common) 157 One user may have multiple clients (for example a mobile and a 158 desktop client). A handle may refer to a single user or it may 159 redirect to multiple users. In some systems, the user identifier is 160 a handle. In other systems the user identifier is an internal 161 representation, for example a UUID. Handles may be changed/renamed, 162 but hopefully internal user identifiers do not. Unqualified handles 163 are often prefixed with a commercial at-sign ("@"). 165 Likewise, group conversation identifiers could be internal or 166 external representations, whereas group names or channel names are 167 often external friendly representations. Unqualified channel names 168 are often prefixed with a hash character ("#"). Some systems have an 169 additional level of hierarchy with a team identifier under which 170 groups/channels can be organized and authorized. 172 This proposal relies on URIs for naming and identifiers. All the 173 example use the im: URI scheme (defined in [RFC3862]), but any 174 instant messaging scheme is acceptable. 176 3.2. Negotiation of MIME types 178 As most IM systems are proprietary, standalone systems, it is useful 179 to allow clients to send and receive proprietary formats among 180 themselves. Using the multipart/alternative MIME wrapper, clients 181 can send a message using the basic functionality described in this 182 document AND a proprietary format for same-vendor clients 183 simultaneously over the same group with end-to-end encryption. 185 [I-D.mahy-dispatch-immi-mls-mime] contains the actual MLS extensions 186 useful for negotiating MIME types. The profile in this document 187 requires support for receiving message/cpim, text/plain, text/ 188 markdown, and multipart MIME. All other mime types (including some 189 recommended in this profile) are optional. 191 Example sending this profile and proprietary messaging protocol 192 simultaneously. 194 Content-type: multipart/alternative 196 3.3. CPIM and MIME headers 198 We assume that an MLS group is already established and that either 199 out-of-band or using the MLS protocol or MLS extensions that the 200 following is known to every member of the group: 202 * The membership of the group (via MLS). 203 * The identity of any MLS client which sends an application message 204 (via MLS). 205 * The MLS group ID (via MLS) 206 * The human readable name(s) of the MLS group, if any (out-of-band 207 or extension). 208 * Which MIME types are mandatory to implement (proposed extension). 209 * For each member, the MIME types each supports (proposed 210 extension). 212 For all messages the message header equivalent of To (the MLS group) 213 and Sender fields (MLS sender) is already known and is therefore 214 redundant. Every message contains a message/cpim header which 215 includes the From, DateTime, and Message-ID fields. The From field 216 contains the external, user-friendly representation of the Sender. 218 Messages sent to an MLS group are delivered to every member of the 219 group active during the epoch in which the message was sent. 221 It is also mandatory to understand are the following MIME headers: 223 * Content-Type 224 * Content-Disposition 225 * Content-Length 227 4. Example 228 4.1. Original Message 230 In this example, Alice Smith sends a rich-text (Markdown) [RFC7763] 231 message to the Engineering Team MLS group. The following values are 232 implied as if headers were present: 234 * Implied Sender header from MLS sender: im:3b52249d-68f9-45ce-8bf5- 235 c799f3cad7ec-0003@example.com (im:3b52249d-68f9-45ce-8bf5- 236 c799f3cad7ec-0003@example.com) 237 * Implied To header from MLS group: "Engineering Team" im:9dc867ca- 238 3a01-4385-bb69-1573601c3c0c@example.com (im:9dc867ca- 239 3a01-4385-bb69-1573601c3c0c@example.com) 241 Content-type: message/cpim 243 From: 244 DateTime: 2022-02-08T22:13:45-00:00 245 Message-ID: <28fd19857ad7@example.com> 247 Content-Type: text/markdown;charset=utf-8 249 Hi everyone, we just shipped release 2.0. __Good work__! 251 4.2. Reply 253 A reply message looks similar, but contains an In-Reply-To CPIM 254 header with the ID of the original message. The implied To header is 255 the same all example messages in this section. The implied Sender 256 header is always the MLS sender, and will not be shown in subsequent 257 example messages. 259 Content-type: message/cpim 261 From: 262 DateTime: 2022-02-08T22:13:57-00:00 263 Message-ID: 264 In-Reply-To: <28fd19857ad7@example.com> 266 Content-Type: text/markdown;charset=utf-8 268 Right on! _Congratulations_ 'all! 270 4.3. Reaction 272 A reaction, uses the reaction Content-Disposition token defined in 273 [RFC9078]. This Content-Disposition token indicates that the 274 intended disposition of the contents of the message is a reaction. 276 The content in the sample message is a single Unicode heart character 277 (U+2665). Discovering the range of characters each implementation 278 could render as a reaction can occur out-of-band and is not within 279 the scope of this proposal. However, an implementation which 280 receives a reaction character string it does not recognize could 281 render the reaction as a reply, possibly prefixing with a localized 282 string such as "Reaction: ". Note that a reaction could 283 theoretically even be another media type (ex: image, audio, or 284 video), although not currently implemented in major instant messaging 285 systems. 287 Content-type: message/cpim 289 From: 290 DateTime: 2022-02-08T22:13:57-00:00 291 Message-ID: <1a771ca1d84f@example.com> 292 In-Reply-To: <28fd19857ad7@example.com> 294 Content-Type: text/plain;charset=utf-8 295 Content-Disposition: reaction 297 ♥ 299 4.4. Mentions 301 In instant messaging systems and social media, a mention allows 302 special formatting and behavior when a name, handle, or tag 303 associated with a known group is encountered, often when prefixed 304 with a commercial-at "@" character for mentions of users or a hash 305 "#" character for groups or tags. A message which contains a mention 306 may trigger distinct notifications on the IM client. 308 We can convey a mention by linking the user, handle, or tag URI in 309 Markdown or HTML rich content. For example, a mention using Markdown 310 is indicated below. 312 Content-type: message/cpim 314 From: 315 DateTime: 2022-02-08T22:14:03-00:00 316 Message-ID: <4dcab7711a77@example.com> 318 Content-Type: text/markdown;charset=utf-8 320 Kudos to [@Alice Smith](im:alice-smith@example.com) 321 for making the release happen! 322 The same mention using HTML [W3C.CR-html52-20170808] is indicated 323 below. 325 Content-type: message/cpim 327 From: 328 DateTime: 2022-02-08T22:14:03-00:00 329 Message-ID: <4dcab7711a77@example.com> 331 Content-Type: text/html;charset=utf-8 333

Kudos to @Alice 334 Smith for making the release happen!

336 4.5. Edit 338 Unlike with email messages, it is common in IM systems to allow the 339 sender of a message to edit or delete the message after the fact. 340 Typically the message is replaced in the user interface of the 341 receivers (even after the original message is read) but shows a 342 visual indication that it has been edited. 344 We reuse the Supersedes header from MIXER [RFC2156], because the 345 semantics are correct: the message included in the body is a 346 replacement for the message with the superseded message ID. 348 Here Bob Jones corrects a typo in his original message: 350 Content-type: message/cpim 352 From: 353 DateTime: 2022-02-08T22:13:57-00:00 354 Message-ID: <89d3472622a4@example.com> 355 Supersedes: 357 Content-Type: text/markdown;charset=utf-8 359 Right on! _Congratulations_ y'all! 361 4.6. Delete 363 In IM systems, a delete means that the author of a specific message 364 has retracted the message, regardless if other users have read the 365 message or not. Typically a placeholder remains in the user 366 interface showing that a message was deleted. Replies which 367 reference a deleted message typically hide the quoted portion and 368 reflect that the original message was deleted. 370 If Bob deleted his message instead of modifying it, we would 371 represent it using the Supersedes header with an empty body, as shown 372 below. 374 Content-type: message/cpim 376 From: 377 DateTime: 2022-02-08T22:13:57-00:00 378 Message-ID: <89d3472622a4@example.com> 379 Supersedes: 381 Content-Length: 0 383 4.7. Expiring 385 Expiring messages are designed to be deleted automatically by the 386 receiving client at a certain time whether they have been read or 387 not. As with manually deleted messages, there is no guarantee that a 388 uncooperative client or a determined user will not save the content 389 of the message, however most clients respect the convention. 391 MIXER defines an Expires header which is also used sent simply by 392 including an Expires header in the CPIM message body. 394 To avoid using two different date header syntaxes, we define an 395 ExpiresDateTime header, which uses the same date/time format as 396 CPIM's DateTime header. The semantics of the header are that the 397 message is automatically deleted by the receiving clients at the 398 indicated time without user interaction or network connectivity 399 necessary. 401 Content-type: message/cpim 403 From: 404 DateTime: 2022-02-08T22:49:03-00:00 405 Message-ID: <5c95a4dfddab@example.com> 406 ExpiresDateTime: 2022-02-08T22:59:03-00:00 408 Content-Type: text/markdown;charset=utf-8 410 __*VPN GOING DOWN*__ 411 I'm rebooting the VPN in ten minutes unless anyone objects. 413 4.8. Knock 415 A knock or ping is message sent to get the attention of a user or a 416 group of users. It might be sent when a user has not responded to 417 direct messages or mentions, or in a group when something requires 418 the attention of everyone quickly (ex: a serious unusual situation 419 like a major system outage). 421 We represent a knock as a text/plain body containing a single CRLF 422 with the alert Content-Disposition token (defined in [RFC3261]). 424 Content-type: message/cpim 426 From: 427 DateTime: 2022-02-08T22:13:45-00:00 428 Message-ID: 430 Content-Type: text/plain 431 Content-Disposition: alert 433 4.9. Read Receipt 435 In instant messaging systems, read receipts typically generate a 436 distinct indicator for each message. In some systems, the number of 437 users in a group who have read the message is subtly displayed and 438 the list of users who read the message is available on further 439 inspection. 441 Of course, Internet mail has support for read receipts as well, but 442 the existing message disposition notification mechanism defined for 443 email in [RFC8098] is unfortunately inappropriate in this context. 445 * notifications can be sent by intermediaries 446 * only one notification can be sent about a single message per 447 recipient 448 * a human-readable version of the notification is expected 449 * each notification can refer to only one message 450 * it is extremely verbose 452 The proposed format below, message/immi-disposition-notification is 453 sent by one member of an MLS group to the entire group and can refer 454 to multiple messages. There is one IMMI-Disposition line per 455 message, with the disposition of the original message in a parameter. 456 As the disposition at the recipient changes, the disposition can be 457 updated in a subsequent notification. 459 Content-type: message/cpim 461 From: 462 DateTime: 2022-02-09T07:57:13-00:00 463 Message-ID: <7e924c2e6ee5@example.com> 465 Content-Disposition: notification 466 Content-type: message/immi-disposition-notification 468 IMMI-Disposition: <4dcab7711a77@example.com>;dispo=read 469 IMMI-Disposition: <285f75c46430@example.com>;dispo=read 470 IMMI-Disposition: ;dispo=read 471 IMMI-Disposition: <5c95a4dfddab@example.com>;dispo=expired 473 4.10. Attachments 475 The message/external-body MIME Type is a convenient way to present a 476 URL to download an attachment which should not be rendered inline. 478 Content-Type: message/external-body; access-type="URL"; 479 URL="https://example.com/storage/bigfile.m4v"; 480 size=708234961 482 4.11. Conferencing 484 Joining a conference via URL is also possible. The link could be 485 rendered to the user, requiring a click. Alternatively another 486 Content-Disposition could be specified to more automatic actions. 487 However further calling and conferencing functionality is out-of- 488 scope of this document. 490 Content-Type: message/external-body; access-type="URL"; 491 URL="https://example.com/join/12345" 493 5. IMMI CPIM profile 495 We define a profile of CPIM for instant messaging within MLS. The 496 grammar uses Augmented Backus-Naur Form (BNF) [RFC5234]. 498 5.1. CPIM headers 500 The following CPIM headers are required: 502 * From: the identity of message sender. for example 503 im:alice@example.com this identity could be pseudonymous or 504 anonymous if the group policy allows. 505 * DateTime: the date and time in a reasonable format, as specified 506 in CPIM. 508 * Message-ID: a message ID which is unique across domains. 509 * Content-type: As is from CPIM. 510 * In-Reply-To: Refers to the previous Message-ID. Same semantics as 511 in [RFC5322]. 512 * Supersedes: Refers to the previous Messsage-ID. Similar semantics 513 to header of the same name in MIXER. Content-Disposition: The 514 intended handling of the message. The two required dispositions 515 are render and reaction. 516 * Content-Length: 518 For clarity the grammar for the headers not already included in CPIM 519 are formulated below. 521 msg-id-header-line = msg-id-header ":" SP msg-id CRLF 522 msg-id-header = "Message-ID" ; case-sensitive 524 in-reply-to-header-line = in-reply-to-header ":" SP msg-id CRLF 525 in-reply-to-header = "In-Reply-To" ; case-sensitive 527 supersedes-header-line = supersedes-header ":" SP msg-id CRLF 528 supersedes-header = "Supersedes" ; case-sensitive 530 msg-id = "<" id-left "@" id-right ">" 532 id-left = dot-atom-text 533 id-right = dot-atom-text / no-fold-literal 535 dot-atom-text = 1*atext *("." 1*atext) 537 atext = ALPHA / DIGIT / atom-symbol 539 atom-symbol = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / 540 "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" 542 no-fold-literal = "[" *dtext "]" 544 dtext = %d33-90 / %d94-126 ; Printable US-ASCII 545 ; excluding "[", "]", and "\" 547 5.2. Definition of message/immi-disposition-notification 549 The grammar below defines the syntax. 551 immi-disposition-notification-body = 1*immi-header-line 553 immi-header-line = immi-header ":" SP msg-id ";" status CRLF 555 imm-header = "IMMI-Disposition" ; case-sensitive 557 status = "dispo" "=" status-value 559 status-value = "read" / 560 "error" / 561 "delivered" / 562 "expired" / 563 "deleted" / 564 "hidden" 566 5.3. Required and Recommended MIME types 568 The following MIME types are REQUIRED: 570 * message/cpim 571 * multipart/alternative 572 * multipart/mixed 573 * multipart/parallel 574 * text/plain 575 * text/markdown 577 The following MIME types are RECOMMENDED: 579 * text/html 580 * message/external-body 581 * message/immi-disposition-notification 582 * image/jpeg 583 * image/png 585 6. IANA Considerations 587 6.1. MIME subtype registration of message/immi-disposition-notification 589 This document proposes registration of a MIME subtype with IANA. 591 TBC 593 7. Security Considerations 595 TBC 597 8. Normative References 599 [I-D.ietf-mls-protocol] 600 Barnes, R., Beurdouche, B., Robert, R., Millican, J., 601 Omara, E., and K. Cohn-Gordon, "The Messaging Layer 602 Security (MLS) Protocol", Work in Progress, Internet- 603 Draft, draft-ietf-mls-protocol-12, 11 October 2021, 604 . 607 [I-D.mahy-dispatch-immi-mls-mime] 608 Mahy, R., "Inside MLS Message Interop (IMMI) MIME type 609 extensions", Work in Progress, Internet-Draft, draft-mahy- 610 dispatch-immi-mls-mime-00, 7 March 2022, 611 . 614 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 615 Mapping between X.400 and RFC 822/MIME", RFC 2156, 616 DOI 10.17487/RFC2156, January 1998, 617 . 619 [RFC2219] Hamilton, M. and R. Wright, "Use of DNS Aliases for 620 Network Services", BCP 17, RFC 2219, DOI 10.17487/RFC2219, 621 October 1997, . 623 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 624 A., Peterson, J., Sparks, R., Handley, M., and E. 625 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 626 DOI 10.17487/RFC3261, June 2002, 627 . 629 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 630 Messaging (CPIM): Message Format", RFC 3862, 631 DOI 10.17487/RFC3862, August 2004, 632 . 634 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 635 Specifications: ABNF", STD 68, RFC 5234, 636 DOI 10.17487/RFC5234, January 2008, 637 . 639 [RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763, 640 DOI 10.17487/RFC7763, March 2016, 641 . 643 9. Informative References 645 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 646 "MIME Security with OpenPGP", RFC 3156, 647 DOI 10.17487/RFC3156, August 2001, 648 . 650 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 651 DOI 10.17487/RFC5322, October 2008, 652 . 654 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 655 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 656 March 2011, . 658 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition 659 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, 660 February 2017, . 662 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 663 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 664 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 665 April 2019, . 667 [RFC9078] Crocker, D., Signes, R., and N. Freed, "Reaction: 668 Indicating Summary Reaction to a Message", RFC 9078, 669 DOI 10.17487/RFC9078, August 2021, 670 . 672 [W3C.CR-html52-20170808] 673 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 674 S. Moon, "HTML 5.2", World Wide Web Consortium CR CR- 675 html52-20170808, 8 August 2017, 676 . 678 Author's Address 680 Rohan Mahy 681 Wire 682 Email: rohan.mahy@wire.com