Reaction: Indicating Summary Reaction to a MessageBrandenburg InternetWorkingdcrocker@bbiw.netFastmailrjbs@semiotic.systemsOraclened.freed@mrochek.comreactionemojisocial networkingemailaffectmessagingemoticonsmileyslikemimereplyThe popularity of social media has led to user comfort with easily signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' graphic. This specification
permits a similar facility for Internet Mail.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF community.
It has received public review and has been approved for publication
by the Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Terminology
. Reaction Content-Disposition
. Reaction Message Processing
. Usability Considerations
. Example Message
. Example Display
. Security Considerations
. IANA Considerations
. Experimental Goals
. Normative References
Acknowledgements
Authors' Addresses
IntroductionThe popularity of social media has led to user comfort with easily signaling summary reactions
to an author's posting, by using emoji graphics, such as with a 'thumbs up', 'heart', or
'smiley' indication. Sometimes the permitted repertoire is constrained to a small set, and
sometimes a more extensive range of indicators is supported. This specification extends this existing practice in social media and instant messaging into
Internet Mail.While it is already possible to include symbols and graphics as part of an email reply's
content, there has not been an established means of signaling the semantic substance that
such data are to be taken as a summary 'reaction' to the original message -- that is, a
mechanism to identify symbols as specifically providing a summary reaction to the cited
message rather than merely being part of the free text in the body of a response. Such a
structured use of the symbol(s) allows recipient Mail User Agents (MUAs) to correlate this reaction to the
original message and possibly to display the information distinctively.This facility defines a new MIME Content-Disposition, to be used in conjunction with the
In-Reply-To header field, to specify that a part of a message containing one or more emojis
can be treated as a summary reaction to a previous message.TerminologyUnless provided here, terminology, architecture, and specification notation used in this
document are incorporated from:
Syntax is specified with
The ABNF rule emoji-sequence is inherited from ; details are in
.Normative language, per and :The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.Reaction Content-DispositionA message sent as a reply MAY include a part containing: Content-Disposition: reaction
If such a field is specified, the Content-Type of the part MUST be:Content-Type: text/plain; charset=utf-8
The content of this part is restricted to a single line of emoji. The
is: part-content = emoji *(WSP emoji) CRLF
emoji = emoji-sequence
emoji-sequence = { defined in [Emoji-Seq] }
base-emojis = thumbs-up / thumbs-down / grinning-face /
frowning-face / crying-face
; Basic set of emojis, drawn from [Emoji-Seq]
; thumbs-up = {U+1F44D}
; thumbs-down = {U+1F44E}
; grinning-face = {U+1F600}
; frowning-face = {U+2639}
; crying-face = {U+1F622}
The part-content is either the message's single MIME body or the content portion of the first MIME multipart body part.The ABNF rule emoji-sequence is inherited from . It defines a set of
Unicode code point sequences, which must then be encoded as UTF-8. Each sequence forms a
single pictograph. The BNF syntax used in differs from and
MUST be interpreted as used in Unicode documentation. The referenced document describes these
as sequences of code points.The rule base-emojis is provided as a simple, common list, or 'vocabulary' of emojis. It was
developed from some existing practice in social networking and is intended for similar use.
However, support for it as a base vocabulary is not required. Having providers and consumers
employ a common set will facilitate user interoperability, but different sets of users might
want to have different, common (shared) sets.The reaction emoji or emojis are linked to the current message's In-Reply-To field, which references
an earlier message and provides a summary reaction to that earlier message . For processing details, see .Reference to unallocated code points SHOULD NOT be treated as an error; the corresponding UTF-8-encoded code points SHOULD be processed using the system default method for denoting an
unallocated or undisplayable code point. Reaction Message ProcessingThe presentation aspects of reaction processing are necessarily MUA specific and beyond the
scope of this specification. In terms of the message itself, a recipient MUA that supports
this mechanism operates as follows:
If a received message R's header contains an In-Reply-To field, check to see if it
references a previous message that the MUA has sent or received.
If R's In-Reply-To: does reference one, then check R's message content for a part with
a "reaction" Content-Disposition header field, at either the outermost level or as
part of a multipart at the outermost level.
If such a part is found and the content of the part conforms to the restrictions
outlined above, remove the part from the message and process the part as a reaction.
Again, the handling of a message that has been successfully processed is MUA specific and
beyond the scope of this specification.Usability ConsiderationsThis specification defines a mechanism for the structuring and carriage of information. It does
not define any user-level details of use. However, the design of the user-level mechanisms
associated with this facility is paramount. This section discusses some issues to
consider.
Creation:
Because an email environment is different from a typical social
media platform, there are significant -- and potentially challenging -- choices in the
design of the user interface, to support indication of a reaction. Is the reaction to
be sent only to the original author, or should it be sent to all recipients? Should
the reaction always be sent in a discrete message containing only the reaction, or
should the user also be able to include other message content? (Note that carriage of
the reaction in a normal email message enables inclusion of this other content.)
Display:
Reaction indications might be more useful when displayed in close
visual proximity to the original message, rather than merely as part of an email
response thread.
The handling of
multiple reactions, from the same person, is also an opportunity
for making a user experience design choice that could be interesting.
Culture:
The use of an image, intended to serve as a semantic signal, is
determined and affected by cultural factors, which differ in complexity and nuance. It
is important to remain aware that an author's intent when sending a particular emoji
might not match how the recipient interprets it. Even simple, commonly used emojis can
be subject to these cultural differences.
Example MessageA simple message exchange might be:To: recipient@example.org
From: author@example.com
Date: Today, 29 February 2021 00:00:00 -800
Message-ID: 12345@example.com
Subject: Meeting
Can we chat at 1pm pacific, today?
with a thumbs-up, affirmative response of:To: author@example.com
From: recipient@example.org
Date: Today, 29 February 2021 00:00:10 -800
Message-ID: 56789@example.org
In-Reply-To: 12345@example.com
Subject: Meeting
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Disposition: reaction
{U+1F44D}
The Unicode character, represented here as "{U+1F44D}" for readability, would actually be sent as the UTF-8-encoded character.The example could, of course, be more elaborate, such as the first of a MIME multipart sequence.Example DisplayRepeating the caution that actual use of this capability requires careful usability design
and testing, this section describes simple examples -- which have not been tested -- of
how the reaction response might be displayed in a summary list of messages:
Summary:
Summary listings of messages in a folder include columns such
as Subject, From, and Date. Another might be added to show common reactions and a
count of how many of them have been received.
Message:
A complete message is often displayed with a tailored section
for header fields, enhancing the format and showing only selected header fields. A
pseudo-field might be added for reactions, again showing the symbol and a
count.
Security ConsiderationsThis specification employs message content that is a strict subset of existing possible
content and thus introduces no new content-specific security considerations. The fact that
this content is structured might seem to make it a new threat surface, but there is no
analysis demonstrating that it does.This specification defines a distinct Content-Disposition value for specialized message
content. Processing that handles the content differently from other content in the message
body might introduce vulnerabilities. Since this capability is likely to produce new user
interaction features, that might also produce new social engineering vulnerabilities.IANA ConsiderationsIANA has registered the Reaction MIME Content-Disposition parameter, per .
Content-Disposition parameter name:
reaction
Allowable values for this parameter:
(none)
Description:
Permit a recipient to respond by signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' graphic
Experimental GoalsThe basic, email-specific mechanics for this capability are well established and
well understood. Points of concern, therefore, are:
Technical issues in using emojis within a message body
Market interest
Usability
So the questions to answer for this Experimental specification are:
Is there demonstrated interest by MUA developers?
If MUA developers add this capability, is it used by authors?
Does the presence of the Reaction capability create any operational problems for
recipients?
Does the presence of the Reaction capability demonstrate additional security
issues?
What specific changes to the specification are needed?
What other comments will aid in use of this mechanism?
Please send comments to ietf-822@ietf.org.Normative ReferencesAugmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Unicode Technical Standard #51: Unicode EmojiGoogle, Inc.Apple, IncInternet Mail ArchitectureOver its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.Internet Message FormatThis document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesThis initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Communicating Presentation Information in Internet Messages: The Content-Disposition Header FieldThis memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.AcknowledgementsThis specification had substantive commentary on three IETF mailing lists.This work began as a private exercise, in July 2020, with private discussion, for draft-crocker-reply-emoji. It morphed into draft-crocker-inreply-react, with significant discussion on the ietf-822 mailing list , September through November 2020. The discussion
produced a fundamental change from proposing a new header field to instead defining a new
Content-Disposition type, as well as significantly enhancing its text concerning Unicode. It
also produced two additional coauthors.In November 2020, the Dispatch mailing list was queried about the draft, but it produced no discussion,
though it did garner one statement of interest.A 4-week Last Call was issued on this document, January 2021, resulting in quite a bit of fresh
discussion on the last-call mailing list and producing further changes to this document. After
Last Call completed, additional concerns regarding the Unicode-related details surfaced, producing yet more changes to the document. It also produced a challenge that prompted the
current version of this Acknowledgements section.Readers who are interested in the details of the document's history are encouraged to peruse the
archives for the three lists, searching Subject fields for "react".Authors' AddressesBrandenburg InternetWorkingdcrocker@bbiw.netFastmailrjbs@semiotic.systemsOraclened.freed@mrochek.com