React: Indicating Summary Reaction to a MessageBrandenburg InternetWorkingdcrocker@bbiw.netSemiotic Systemsrjbs@semiotic.systems
Applications and Real-Time
reactionemojisocial networkingemailaffectmessagingThe 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
indication. 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 header field, to be used in junction with the In-Reply-To
header field, to link one or more emojis 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.A message sent as a reply MAY indicate the responder's summary reaction to the
original message by including an In-Reply-React header field: 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. .Fully interoperable email uses 7-bit ASCII, although some email handling paths
directly support 8-bit data. Emoji characters are drawn from the space outside of
7-bit ASCII. For email handling paths that are 8-bit clean, the an emoji character
does not need special encoding. If the path from author to recipients is not known
to be 8-bit clean, The emoji character SHOULD be encoded using .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.For recipient MUAs that do not support this mechanism, the header field might not be
displayed to the recipient. To ensure that the reaction is presented to the
recipient, the responding MUA MAY automatically include a second copy of the header
field in the message body. This might be as the first line of the body or as the
first mime-part. By making the text be the full header field,
it also allows MUAs that do support the mechanism to identify this redundant
information and possibly remove it from display.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 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 defines a distinct location for specialized message content.
Processing that handles the content differently from content in the message body
might introduce vulnerabilities. However the mere definition or use of this
mechanism does not create new vulnerabilities.Add to "Permanent Message Header Field Registry":In-Reply-ReactMail (RFC 2822)ExperimentalIETFThis specification.NoneAugmented BNF for Syntax Specifications: ABNFBrandenburg InternetWorkingTHUS plc Unicode® Technical Standard #51: Unicode EmojiGoogle, Inc.Apple, IncInternet Message Format Qualcomm Incorporated Internet Mail ArchitectureBrandenburg InternetWorkingMIME (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII TextUniversity of TennesseeMultipurpose 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