Brandenburg InternetWorking

dcrocker@bbiw.net

Fastmail

rjbs@semiotic.systems

Oracle

ned.freed@mrochek.com

Applications and Real-Time reaction emoji social networking email affect messaging The 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 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.

A 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 single line of emoji. The is: part-content = emoji *(lwsp emoji) CRLF emoji = emoji_sequence emoji_sequence = { defined in [Emoji-Seq] } base-emojis = thumbs-up / thumbs-down / grinning-face / frowning-face / crying-face thumbs-up = {U+1F44D} thumbs-down = {U+1F44E} grinning-face = {U+1F600} frowning-face = {U+2639} crying-face = {U+1F622}

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.

New Content-Disposition Parameter Registrations This document specifies a new "reaction" content disposition and its handling that should be added to the IANA registry.

Brandenburg InternetWorking THUS plc Google, Inc. Apple, Inc Qualcomm Incorporated Brandenburg InternetWorking Innosoft First Virtual

This 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