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 marking 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 used in this
document are incorporated from , , , and . The ABNF rule Emoji-Seq is
inherited from .Discussion of this specification should take place on the ietf-822@ietf.org mailing
list.Normative language: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in .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 permits one
or more bytes to form a single presentation image.The emoji(s) express a recipient's summary reaction to the specific message
referenced by the accompanying In-Reply-To header field. .Reference to unallocated code points SHOULD NOT be treated as an error; associated
bytes 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, recipient
MUAs that support this mechanism operate as follows: If an In-Reply-To field is present check to see if it references a previous
message the MUA has received. If a reference to an existing message is found check for a part with a
"reaction" content-disposition 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 it
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. This specification employs message content that is a strict subset of existing
content, and thus introduces no new content-specific security considerations.This specification defines a distinct label for specialized message content.
Processing that handles the content differently from other content in the message
body might introduce vulnerabilities.The React MIME Content-Disposition parameter is registered, per Reaction(none)Permit a recipient to respond by signaling basic
reactions to an author's posting, such as with a 'thumbs up' or 'smiley'
graphicThe email mechanics for this capability use the long-standing
are 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 VirtualThis specification has been discussed in the ietf-822 mailing list. Active commentary
and suggestions were offered by: Nathaniel Borenstein, Richard Clayton, Ned Freed,
Bron Gondwana, Valdis Klētnieks, John Levine, Brandon Long, Keith Moore, Pete
Resnick, Michael Richardson, Alessandro Vesely