idnits 2.17.1 draft-crocker-inreply-react-07.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 is 1 instance of too long lines in the document, the longest one being 11 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 (January 18, 2021) is 1192 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Experimental R. Signes 5 Expires: July 22, 2021 Fastmail 6 N. Freed 7 Oracle 8 January 18, 2021 10 React: Indicating Summary Reaction to a Message 11 draft-crocker-inreply-react-07 13 Abstract 15 The popularity of social media has led to user comfort with easily 16 signaling basic reactions to an author's posting, such as with a 17 'thumbs up' or 'smiley' graphic. This specification permits a 18 similar facility for Internet Mail. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 22, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Reaction Content-Disposition . . . . . . . . . . . . . . . . 3 56 3. Reaction Message Processing . . . . . . . . . . . . . . . . . 4 57 4. Usability Considerations . . . . . . . . . . . . . . . . . . 5 58 4.1. Example Message . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Example Display . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 7 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 The popularity of social media has led to user comfort with easily 70 signaling summary reactions to an author's posting, by marking basic 71 emoji graphics, such as with a 'thumbs up', 'heart', or 'smiley' 72 indication. Sometimes the permitted repertoire is constrained to a 73 small set and sometimes a more extensive range of indicators is 74 supported. 76 This specification defines a similar facility for Internet Mail. 78 While it is already possible to include symbols and graphics as part 79 of an email reply's content, there has not been an established means 80 of signalling the semantic substance that such data are to be taken 81 as a summary 'reaction' to the original message. That is, a 82 mechanism to identify symbols as specifically providing a summary 83 reaction to the cited message, rather than merely being part of the 84 free text in the body of a response. Such a structured use of the 85 symbol(s) allows recipient MUAs to correlate this reaction to the 86 original message and possibly to display the information 87 distinctively. 89 This facility defines a new MIME Content-Disposition, to be used in 90 conjunction with the In-Reply-To header field, to specify that a part 91 of a message containing one or more emojis be treated as a summary 92 reaction to a previous message. 94 Unless provided here, terminology, architecture and specification 95 notation used in this document are incorporated from [Mail-Arch], 97 [Mail-Fmt], [MIME], and [ABNF]. The ABNF rule Emoji-Seq is inherited 98 from [Emoji-Seq]. 100 Normative language, per [RFC8174]: 102 In many IETF documents, several words, when they are in all 103 capitals as shown below, are used to signify the requirements in 104 the specification. These capitalized words can bring significant 105 clarity and consistency to documents because their meanings are 106 well defined. This document defines how those words are 107 interpreted in IETF documents when the words are in all capitals. 109 * These words can be used as defined here, but using them is not 110 required. Specifically, normative text does not require the 111 use of these key words. They are used for clarity and 112 consistency when that is what's wanted, but a lot of normative 113 text does not use them and is still normative. 115 * The words have the meanings specified herein only when they are 116 in all capitals. 118 * When these words are not capitalized, they have their normal 119 English meanings and are not affected by this document. 121 Authors who follow these guidelines should incorporate this phrase 122 near the beginning of their document: 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 125 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 126 "MAY", and "OPTIONAL" in this document are to be interpreted as 127 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 128 appear in all capitals, as shown here. 130 2. Reaction Content-Disposition 132 A message sent as a reply MAY include a part containing: 134 Content-Disposition: Reaction 136 If such a field is specified the content-type of the part MUST be: 138 Content-Type: text/plain; charset=utf-8 139 The content of this part is restricted to single line of emoji. The 140 [ABNF] is: 142 part-content = emoji *(lwsp emoji) CRLF 144 emoji = emoji_sequence 145 emoji_sequence = { defined in [Emoji-Seq] } 147 base-emojis = thumbs-up / thumbs-down / grinning-face / frowning-face / crying-face 149 thumbs-up = {U+1F44D} 150 thumbs-down = {U+1F44E} 151 grinning-face = {U+1F600} 152 frowning-face = {U+2639} 153 crying-face = {U+1F622} 155 The rule emoji_sequence is inherited from [Emoji-Seq]. It permits 156 one or more bytes to form a single presentation image. 158 The rule base-emojis MAY be used as a simple, common list, or 159 'vocabulary' of emojis. It was developed from some existing 160 practice, in social networking, and is therefore intended for use. 161 However support for it is not required. Having providers and 162 consumers employ a common set will facilitate user interoperability, 163 but different sets of users might want to have different, common 164 (shared) sets. 166 The emoji(s) express a recipient's summary reaction to the specific 167 message referenced by the accompanying In-Reply-To header field. 168 [Mail-Fmt]. 170 Reference to unallocated code points SHOULD NOT be treated as an 171 error; associated bytes SHOULD be processed using the system default 172 method for denoting an unallocated or undisplayable code point. 174 3. Reaction Message Processing 176 The presentation aspects of reaction processing are necessarily MUA- 177 specific and beyond the scope of this specification. In terms of the 178 message itself, a recipient MUA that supports this mechanism operates 179 as follows: 181 1. If a received message R contains an In-Reply-To: header-field, 182 check to see if it references a previous message the MUA has sent 183 or received. 185 2. If R's In-Reply-To: does reference one, then check R's message 186 content for a part with a "reaction" content-disposition at 187 either the outermost level or as part of a multipart at the 188 outermost level. 190 3. If such a part is found, and the content of the part conforms to 191 the restrictions outlined above, remove the part from the message 192 and process the part as a reaction. 194 4. Processing terminates if no parts remain in the message. If 195 parts remain process the remaining message content as a reply. 197 Again, the handling of a message that has been successfully processed 198 is MUA-specific and beyond the scope of this specification. 200 4. Usability Considerations 202 This specification defines a mechanism for the structuring and 203 carriage of information. It does not define any user-level details 204 of use. However the design of the user-level mechanisms associated 205 with this facility is paramount. This section discusses some issues 206 to consider. 208 Creation: Because an email environment is different from a typical 209 social media platform, there are significant -- and potentially 210 challenging -- choices in the design of the user interface, to 211 support indication of a reaction. Is the reaction to be sent only 212 to the original author, or should it be sent to all recipients? 213 Should the reaction always be sent in a discrete message 214 containing only the reaction, or should the user also be able to 215 include other message content? (Note that carriage of the 216 reaction in a normal email message enables inclusion of this other 217 content.) 219 Display: Reaction indications might be more useful when displayed in 220 close visual proximity to the original message, rather than merely 221 as part of an email response thread. The handling of multiple 222 reactions, from the same person, is also an opportunity for 223 possibly-interesting user experience design choice. 225 4.1. Example Message 227 A simple message exchange might be: 229 To: recipient@example.com 230 From: author@example.com 231 Date: Today, 29 February 2021 00:00:00 -800 232 Message-id: 12345@example.com 233 Subject: Meeting 235 Can we chat at 1pm pacific, today? 237 with a thumbs-up, affirmative response of: 239 To: author@example.com 240 From: recipient@example.com 241 Date: Today, 29 February 2021 00:00:10 -800 242 Message-id: 12345@example.com 243 Subject: Meeting 244 Mime-Version: 1.0 (1.0) 245 Content-Type: text/plain; charset=utf-8 246 Content-Disposition: Reaction 248 {U+1F44E} 250 It could, of course, be more elaborate, such as the first of a MIME 251 multipart sequence. 253 4.2. Example Display 255 Repeating the caution that actual use of this capability requires 256 careful usability design and testing, this section offers simple 257 examples -- which have not been tested -- of how the reaction 258 response might be displayed in a summary list of messages : 260 Summary: Summary listings of messages in a folder include columns 261 such as Subject, From, and Date. Another might be added, to show 262 common reactions and a count of how many of them have been 263 received. 265 Message: A complete message is often displayed with a tailored 266 section for header-fields, enhancing the format and showing only 267 selected header fields. It might include one for reactions, again 268 showing the symbol and a count. 270 5. Security Considerations 272 This specification employs message content that is a strict subset of 273 existing content, and thus introduces no new content-specific 274 security considerations. The fact that this content is structured 275 might seem to make it a new threat surface, but there is no analysis 276 demonstrating that it does. 278 This specification defines a distinct label for specialized message 279 content. Processing that handles the content differently from other 280 content in the message body might introduce vulnerabilities. 282 6. IANA Considerations 284 The React MIME Content-Disposition parameter is registered, per 285 [RFC2183] 287 Content-Disposition parameter name: Reaction 289 Allowable values for this parameter: (none) 291 Description: Permit a recipient to respond by signaling basic 292 reactions to an author's posting, such as with a 'thumbs up' or 293 'smiley' graphic 295 7. Experimental Goals 297 The basic, email-specific mechanics for this capability are well- 298 established and well-understood. Points of concern, therefore, are 299 with market interest and with usability. So the questions to answer, 300 while the header field has experimental status are: 302 o Is there demonstrated interest by MUA developers? 304 o If MUA developers add this capability, is it used by authors? 306 o Does the presence of the Reaction capability create any 307 operational problems for recipients? 309 o Does the presence of the Reaction capability demonstrate 310 additional security issues? 312 8. Normative References 314 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 315 Specifications: ABNF", RFC 5234, January 2008. 317 [Emoji-Seq] 318 Davis, M., Ed. and P. Edberg., Ed., "Unicode(R) Technical 319 Standard #51: Unicode Emoji", WEB 320 http://www.unicode.org/reports/tr51/#def_emoji_sequence, 321 September 2020. 323 [Mail-Arch] 324 Crocker, D., "Internet Mail Architecture", RFC 5598, July 325 2009. 327 [Mail-Fmt] 328 Resnick, P., Ed., "Internet Message Format", RFC 5322, 329 October 2008. 331 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 332 Extensions (MIME) Part One: Format of Internet Message 333 Bodies", RFC 2045, November 1996. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating 341 Presentation Information in Internet Messages: The 342 Content-Disposition Header Field", RFC 2183, 343 DOI 10.17487/RFC2183, August 1997, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 Appendix A. Acknowledgements 352 This specification has had substantive commentary on the ietf-822, 353 dispatch, and last-call mailing lists. Active commentary and 354 suggestions were offered by: Nathaniel Borenstein, Richard Clayton, 355 Bron Gondwana, Nick Hilliard, Valdis Klētnieks, Eliot Lear, 356 Barry Leiba, John Levine, Brandon Long, Keith Moore, Pete Resnick, 357 Michael Richardson, Alessandro Vesely. 359 Authors' Addresses 361 Dave Crocker 362 Brandenburg InternetWorking 364 Email: dcrocker@bbiw.net 366 Ricardo Signes 367 Fastmail 369 Email: rjbs@semiotic.systems 370 Ned Freed 371 Oracle 373 Email: ned.freed@mrochek.com