Network Working Group D. Crocker Internet-Draft Brandenburg InternetWorking Intended status: Informational October 6, 2020 Expires: April 9, 2021 React: Indicating Summary Reaction to a Message draft-crocker-inreply-react-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 9, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) 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. Crocker Expires April 9, 2021 [Page 1] Internet-Draft react October 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. In-Reply-React . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usability Considerations . . . . . . . . . . . . . . . . . . 4 4. Possible Issues . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 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 [Mail-Arch], [Mail-Fmt] and [ABNF]. Discussion of this specification should take place on the ietf- 822@ietf.org mailing list. Crocker Expires April 9, 2021 [Page 2] Internet-Draft react October 2020 2. In-Reply-React 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 [ABNF] for the header field is: in-reply-react = "In-Reply-React:" emoji *(lwsp emoji) CRLF emoji = {character from Unicode Emoji List} emoji-core = 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} An emoji character is taken from [Emoji-List]. The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field. [Mail-Fmt]. Fully interoperable email uses 7-bit ASCII, although some email handling paths directly support 8-bit ASCII. 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 [MIMEencode]. 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 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. [MIME] 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. Crocker Expires April 9, 2021 [Page 3] Internet-Draft react October 2020 3. Usability Considerations 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 . Creation: Because an email environment is different from a typical social media platform, there are some choices needed 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 this specification permits the inclusion of this other content.) Display: Reaction indications are likely to be most useful when displayed in close visual proximity to the original message, rather than merely as part of an email response thread. 4. Possible Issues o Should the specification permit only one emoji? Why (not)? 5. Security Considerations 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. 6. IANA Considerations Add to "Permanent Message Header Field Registry": Header field name: In-Reply-React Applicable protocol: mail (RFC 2822) Status: experimental Author/Change controller: IETF Specification document(s): This specification. Crocker Expires April 9, 2021 [Page 4] Internet-Draft react October 2020 Related information: none 7. References 7.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [Emoji-List] Unicode Consortium, "Full Emoji List, v13.0", WEB https://unicode.org/emoji/charts/full-emoji-list.html. [Mail-Arch] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [MIMEencode] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 7.2. Informative References [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Author's Address Dave Crocker Brandenburg InternetWorking Email: dcrocker@bbiw.net Crocker Expires April 9, 2021 [Page 5]