React: Indicating Summary Reaction to a MessageBrandenburg InternetWorkingdcrocker@bbiw.netFastmailrjbs@semiotic.systemsOraclened.freed@mrochek.com
Applications and Real-Time
reactionemojisocial 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.The popularity of social media has led to user comfort with easily signaling summary reactions
to an author's posting, by using basic 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 defines a similar facility for 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 signalling 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 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 be
treated as a summary reaction to a previous message.Unless provided here, terminology, architecture and specification notation used in this
document are incorporated from , , , and . The ABNF rule Emoji-Seq is inherited from
.Normative language, per : 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 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.A message sent as a reply MAY include a part containing: If such a field is specified the Content-Type of the part MUST be:
The rule emoji_sequence is inherited from . It defines a set of octet
sequences, each of which forms a single pictograph.The rule base-emojis MAY be used 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 emoji(s) express a recipient's summary reaction to the specific message referenced by the
accompanying In-Reply-To header field, for the message in which they both are present. . For processing details, see .Reference to unallocated code points SHOULD NOT be treated as an error; the corresponding
octets SHOULD be processed using the system default method for denoting an unallocated or
undisplayable code point. The 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 contains an In-Reply-To: header-field, check to see if it
references a previous message 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. Processing terminates if no parts remain in the message. If parts remain process the
remaining message content as a reply.Again, the handling of a message that has been successfully processed is MUA-specific
and beyond the scope of this specification.This 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.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.)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 possibly-interesting user experience design choice.A simple message exchange might be: with a thumbs-up, affirmative response of: It could, of course, be more elaborate, such as the first of a MIME multipart
sequence.Repeating the caution that actual use of this capability requires careful usability design
and testing, this section offers simple examples -- which have not been tested -- of how
the reaction response might be displayed in a summary list of messages :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.A complete message is often displayed with a tailored section
for header-fields, enhancing the format and showing only selected header fields.
It might add a field for reactions, again showing the symbol and a count.This specification employs message content that is a strict subset of existing 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.The IANA is request to register the React MIME Content-Disposition parameter, per React(none)Permit a recipient to respond by signaling basic reactions to
an author's posting, such as with a 'thumbs up' or 'smiley' graphicThe basic, email-specific mechanics for this capability are well-established and
well-understood. Points of concern, therefore, are with market interest and with usability. So
the questions to answer, while the header field has experimental status 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? Key words for use in RFCs to Indicate Requirement Levels In 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 Field This 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] Augmented BNF for Syntax Specifications: ABNFBrandenburg InternetWorkingTHUS plc Unicode® Technical Standard #51: Unicode EmojiGoogle, Inc.Apple, IncInternet Message Format Qualcomm Incorporated Internet Mail ArchitectureBrandenburg InternetWorkingMultipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
BodiesInnosoftFirst Virtual Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 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. This specification has had substantive commentary on the ietf-822, dispatch, and last-call
mailing lists. Active commentary and suggestions were offered by: Nathaniel Borenstein,
Richard Clayton, Bron Gondwana, Nick Hilliard, Kjetil Torgrim Homme, Barry Leiba, Valdis
Klētnieks, Eliot Lear, Barry Leiba, John Levine, Brandon Long, Keith Moore, Pete Resnick,
Michael Richardson, Alessandro Vesely.