5Internet Engineering Task Force (IETF) D. Crocker
6Request for Comments: 9078 Brandenburg InternetWorking
7Category: Experimental R. Signes
8ISSN: 2070-1721 Fastmail
14 Reaction: Indicating Summary Reaction to a Message
18 The popularity of social media has led to user comfort with easily
19 signaling basic reactions to an author's posting, such as with a
20 'thumbs up' or 'smiley' graphic. This specification permits a
21 similar facility for Internet Mail.
25 This document is not an Internet Standards Track specification; it is
26 published for examination, experimental implementation, and
29 This document defines an Experimental Protocol for the Internet
30 community. This document is a product of the Internet Engineering
31 Task Force (IETF). It represents the consensus of the IETF
32 community. It has received public review and has been approved for
33 publication by the Internet Engineering Steering Group (IESG). Not
34 all documents approved by the IESG are candidates for any level of
35 Internet Standard; see Section 2 of RFC 7841.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 https://www.rfc-editor.org/info/rfc9078.
43 Copyright (c) 2021 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
60 3. Reaction Content-Disposition
61 4. Reaction Message Processing
62 5. Usability Considerations
65 6. Security Considerations
66 7. IANA Considerations
68 9. Normative References
74 The popularity of social media has led to user comfort with easily
75 signaling summary reactions to an author's posting, by using emoji
76 graphics, such as with a 'thumbs up', 'heart', or 'smiley'
77 indication. Sometimes the permitted repertoire is constrained to a
78 small set, and sometimes a more extensive range of indicators is
81 This specification extends this existing practice in social media and
82 instant messaging into Internet Mail.
84 While it is already possible to include symbols and graphics as part
85 of an email reply's content, there has not been an established means
86 of signaling the semantic substance that such data are to be taken as
87 a summary 'reaction' to the original message -- that is, a mechanism
88 to identify symbols as specifically providing a summary reaction to
89 the cited message rather than merely being part of the free text in
90 the body of a response. Such a structured use of the symbol(s)
91 allows recipient Mail User Agents (MUAs) to correlate this reaction
92 to the original message and possibly to display the information
95 This facility defines a new MIME Content-Disposition, to be used in
96 conjunction with the In-Reply-To header field, to specify that a part
97 of a message containing one or more emojis can be treated as a
98 summary reaction to a previous message.
102 Unless provided here, terminology, architecture, and specification
103 notation used in this document are incorporated from:
111 Syntax is specified with
115 The ABNF rule emoji-sequence is inherited from [Emoji-Seq]; details
118 Normative language, per [RFC2119] and [RFC8174]:
120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
122 "OPTIONAL" in this document are to be interpreted as described in
123 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
124 capitals, as shown here.
1263. Reaction Content-Disposition
128 A message sent as a reply MAY include a part containing:
130 Content-Disposition: reaction
132 If such a field is specified, the Content-Type of the part MUST be:
134 Content-Type: text/plain; charset=utf-8
136 The content of this part is restricted to a single line of emoji.
139 part-content = emoji *(WSP emoji) CRLF
141 emoji = emoji-sequence
142 emoji-sequence = { defined in [Emoji-Seq] }
144 base-emojis = thumbs-up / thumbs-down / grinning-face /
145 frowning-face / crying-face
146 ; Basic set of emojis, drawn from [Emoji-Seq]
148 ; thumbs-up = {U+1F44D}
149 ; thumbs-down = {U+1F44E}
150 ; grinning-face = {U+1F600}
151 ; frowning-face = {U+2639}
152 ; crying-face = {U+1F622}
154 The part-content is either the message's single MIME body or the
155 content portion of the first MIME multipart body part.
157 The ABNF rule emoji-sequence is inherited from [Emoji-Seq]. It
158 defines a set of Unicode code point sequences, which must then be
159 encoded as UTF-8. Each sequence forms a single pictograph. The BNF
160 syntax used in [Emoji-Seq] differs from [ABNF] and MUST be
161 interpreted as used in Unicode documentation. The referenced
162 document describes these as sequences of code points.
164 | Note: The part-content can first be parsed into candidate
165 | reactions, separated by WSP. Each candidate reaction that does
166 | not constitute a single emoji-sequence (as per [Emoji-Seq]) is
167 | invalid. Invalid candidates can be treated individually,
168 | rather than affecting the remainder of the part-content's
169 | processing. The remaining candidates form the set of reactions
170 | to be processed. This approach assumes use of a mechanism for
171 | emoji sequence validation that is not specified here.
173 The rule base-emojis is provided as a simple, common list, or
174 'vocabulary' of emojis. It was developed from some existing practice
175 in social networking and is intended for similar use. However,
176 support for it as a base vocabulary is not required. Having
177 providers and consumers employ a common set will facilitate user
178 interoperability, but different sets of users might want to have
179 different, common (shared) sets.
181 The reaction emoji or emojis are linked to the current message's In-
182 Reply-To field, which references an earlier message and provides a
183 summary reaction to that earlier message [Mail-Fmt]. For processing
184 details, see Section 4.
186 Reference to unallocated code points SHOULD NOT be treated as an
187 error; the corresponding UTF-8-encoded code points SHOULD be
188 processed using the system default method for denoting an unallocated
189 or undisplayable code point.
191 | Note: The "emoji" token looks simple. It isn't. Implementers
192 | are well advised not to assume that emoji sequences are trivial
193 | to parse or validate. Among other concerns, an implementation
194 | of the Unicode Character Database is required. An emoji is
195 | more than a stand-in for a simple alternation of characters.
196 | Similarly, one emoji sequence is not interchangeable with, or
197 | equivalent to, another one, and comparisons require detailed
198 | understanding of the relevant Unicode mechanisms. Use of an
199 | existing Unicode implementation will typically prove extremely
200 | helpful, as will an understanding of the error modes that may
201 | arise with a chosen implementation.
2034. Reaction Message Processing
205 The presentation aspects of reaction processing are necessarily MUA
206 specific and beyond the scope of this specification. In terms of the
207 message itself, a recipient MUA that supports this mechanism operates
210 1. If a received message R's header contains an In-Reply-To field,
211 check to see if it references a previous message that the MUA has
214 2. If R's In-Reply-To: does reference one, then check R's message
215 content for a part with a "reaction" Content-Disposition header
216 field, at either the outermost level or as part of a multipart at
219 3. If such a part is found and the content of the part conforms to
220 the restrictions outlined above, remove the part from the message
221 and process the part as a reaction.
223 | Note: A message's content might include other, nested messages.
224 | These can be analyzed for reactions, independently of the
225 | containing message, applying the above algorithm for each
226 | contained message, separately.
228 Again, the handling of a message that has been successfully processed
229 is MUA specific and beyond the scope of this specification.
2315. Usability Considerations
233 This specification defines a mechanism for the structuring and
234 carriage of information. It does not define any user-level details
235 of use. However, the design of the user-level mechanisms associated
236 with this facility is paramount. This section discusses some issues
239 Creation: Because an email environment is different from a typical
240 social media platform, there are significant -- and potentially
241 challenging -- choices in the design of the user interface, to
242 support indication of a reaction. Is the reaction to be sent only
243 to the original author, or should it be sent to all recipients?
244 Should the reaction always be sent in a discrete message
245 containing only the reaction, or should the user also be able to
246 include other message content? (Note that carriage of the
247 reaction in a normal email message enables inclusion of this other
250 Display: Reaction indications might be more useful when displayed in
251 close visual proximity to the original message, rather than merely
252 as part of an email response thread. The handling of multiple
253 reactions, from the same person, is also an opportunity for making
254 a user experience design choice that could be interesting.
256 Culture: The use of an image, intended to serve as a semantic
257 signal, is determined and affected by cultural factors, which
258 differ in complexity and nuance. It is important to remain aware
259 that an author's intent when sending a particular emoji might not
260 match how the recipient interprets it. Even simple, commonly used
261 emojis can be subject to these cultural differences.
265 A simple message exchange might be:
267 To: recipient@example.org
268 From: author@example.com
269 Date: Today, 29 February 2021 00:00:00 -800
270 Message-ID: 12345@example.com
273 Can we chat at 1pm pacific, today?
275 with a thumbs-up, affirmative response of:
277 To: author@example.com
278 From: recipient@example.org
279 Date: Today, 29 February 2021 00:00:10 -800
280 Message-ID: 56789@example.org
281 In-Reply-To: 12345@example.com
283 Mime-Version: 1.0 (1.0)
284 Content-Type: text/plain; charset=utf-8
285 Content-Disposition: reaction
289 The Unicode character, represented here as "{U+1F44D}" for
290 readability, would actually be sent as the UTF-8-encoded character.
292 The example could, of course, be more elaborate, such as the first of
293 a MIME multipart sequence.
297 Repeating the caution that actual use of this capability requires
298 careful usability design and testing, this section describes simple
299 examples -- which have not been tested -- of how the reaction
300 response might be displayed in a summary list of messages:
302 Summary: Summary listings of messages in a folder include columns
303 such as Subject, From, and Date. Another might be added to show
304 common reactions and a count of how many of them have been
307 Message: A complete message is often displayed with a tailored
308 section for header fields, enhancing the format and showing only
309 selected header fields. A pseudo-field might be added for
310 reactions, again showing the symbol and a count.
3126. Security Considerations
314 This specification employs message content that is a strict subset of
315 existing possible content and thus introduces no new content-specific
316 security considerations. The fact that this content is structured
317 might seem to make it a new threat surface, but there is no analysis
318 demonstrating that it does.
320 This specification defines a distinct Content-Disposition value for
321 specialized message content. Processing that handles the content
322 differently from other content in the message body might introduce
323 vulnerabilities. Since this capability is likely to produce new user
324 interaction features, that might also produce new social engineering
3277. IANA Considerations
329 IANA has registered the Reaction MIME Content-Disposition parameter,
332 Content-Disposition parameter name: reaction
334 Allowable values for this parameter: (none)
336 Description: Permit a recipient to respond by signaling basic
337 reactions to an author's posting, such as with a 'thumbs up' or
342 The basic, email-specific mechanics for this capability are well
343 established and well understood. Points of concern, therefore, are:
345 * Technical issues in using emojis within a message body
351 So the questions to answer for this Experimental specification are:
353 * Is there demonstrated interest by MUA developers?
355 * If MUA developers add this capability, is it used by authors?
357 * Does the presence of the Reaction capability create any
358 operational problems for recipients?
360 * Does the presence of the Reaction capability demonstrate
361 additional security issues?
363 * What specific changes to the specification are needed?
365 * What other comments will aid in use of this mechanism?
367 Please send comments to ietf-822@ietf.org.
3699. Normative References
371 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
372 Specifications: ABNF", STD 68, RFC 5234,
373 DOI 10.17487/RFC5234, January 2008,
374 <https://www.rfc-editor.org/info/rfc5234>.
377 Davis, M., Ed. and P. Edberg, Ed., "Unicode Technical
378 Standard #51: Unicode Emoji", September 2020,
379 <https://www.unicode.org/reports/
380 tr51/#def_emoji_sequence>.
383 Crocker, D., "Internet Mail Architecture", RFC 5598,
384 DOI 10.17487/RFC5598, July 2009,
385 <https://www.rfc-editor.org/info/rfc5598>.
387 [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
388 DOI 10.17487/RFC5322, October 2008,
389 <https://www.rfc-editor.org/info/rfc5322>.
391 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
392 Extensions (MIME) Part One: Format of Internet Message
393 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
394 <https://www.rfc-editor.org/info/rfc2045>.
396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
397 Requirement Levels", BCP 14, RFC 2119,
398 DOI 10.17487/RFC2119, March 1997,
399 <https://www.rfc-editor.org/info/rfc2119>.
401 [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
402 Presentation Information in Internet Messages: The
403 Content-Disposition Header Field", RFC 2183,
404 DOI 10.17487/RFC2183, August 1997,
405 <https://www.rfc-editor.org/info/rfc2183>.
407 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
408 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
409 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
413 This specification had substantive commentary on three IETF mailing
416 This work began as a private exercise, in July 2020, with private
417 discussion, for draft-crocker-reply-emoji. It morphed into draft-
418 crocker-inreply-react, with significant discussion on the ietf-822
419 mailing list <https://www.ietf.org/mailman/listinfo/ietf-822>,
420 September through November 2020. The discussion produced a
421 fundamental change from proposing a new header field to instead
422 defining a new Content-Disposition type, as well as significantly
423 enhancing its text concerning Unicode. It also produced two
424 additional coauthors.
426 In November 2020, the Dispatch mailing list
427 <https://www.ietf.org/mailman/listinfo/dispatch> was queried about
428 the draft, but it produced no discussion, though it did garner one
429 statement of interest.
431 A 4-week Last Call was issued on this document, January 2021,
432 resulting in quite a bit of fresh discussion on the last-call mailing
433 list <https://www.ietf.org/mailman/listinfo/last-call> and producing
434 further changes to this document. After Last Call completed,
435 additional concerns regarding the Unicode-related details surfaced,
436 producing yet more changes to the document. It also produced a
437 challenge that prompted the current version of this Acknowledgements
440 Readers who are interested in the details of the document's history
441 are encouraged to peruse the archives for the three lists, searching
442 Subject fields for "react".
447 Brandenburg InternetWorking
449 Email: dcrocker@bbiw.net
455 Email: rjbs@semiotic.systems
461 Email: ned.freed@mrochek.com