Network Working Group D. Crocker Internet-Draft Brandenburg InternetWorking Intended status: Experimental R. Signes Expires: July 19, 2021 Fastmail N. Freed Oracle January 15, 2021 React: Indicating Summary Reaction to a Message draft-crocker-inreply-react-06 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. 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 July 19, 2021. Copyright Notice Copyright (c) 2021 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 Crocker, et al. Expires July 19, 2021 [Page 1] Internet-Draft react January 2021 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Reaction Content-Disposition . . . . . . . . . . . . . . . . 3 3. Reaction Message Processing . . . . . . . . . . . . . . . . . 4 4. Usability Considerations . . . . . . . . . . . . . . . . . . 5 4.1. Example Message . . . . . . . . . . . . . . . . . . . . . 5 4.2. Example Display . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 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 [Mail-Arch], [Mail-Fmt], Crocker, et al. Expires July 19, 2021 [Page 2] Internet-Draft react January 2021 [MIME], and [ABNF]. The ABNF rule Emoji-Seq is inherited from [Emoji-Seq]. Discussion of this specification should take place on the ietf- 822@ietf.org mailing list. Normative language, per [RFC8174]: In many IETF documents, several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. These capitalized words can bring significant clarity and consistency to documents because their meanings are well defined. This document defines how those words are interpreted in IETF documents when the words are in all capitals. * These words can be used as defined here, but using them is not required. Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative. * The words have the meanings specified herein only when they are in all capitals. * When these words are not capitalized, they have their normal English meanings and are not affected by this document. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. 2. Reaction Content-Disposition 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 Crocker, et al. Expires July 19, 2021 [Page 3] Internet-Draft react January 2021 The content of this part is restricted to single line of emoji. The [ABNF] 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 [Emoji-Seq]. 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. [Mail-Fmt]. 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. 3. Reaction Message Processing 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: 1. 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. 2. If R's In-Reply-To: does reference one, then check R's message content for a part with a "reaction" content-disposition at either the outermost level or as part of a multipart at the outermost level. 3. 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. Crocker, et al. Expires July 19, 2021 [Page 4] Internet-Draft react January 2021 4. 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. 4. 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 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.) Display: 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. 4.1. Example Message A simple message exchange might be: To: recipient@example.com From: author@example.com Date: Today, 29 February 2021 00:00:00 -800 Message-id: 12345@example.com Subject: Meeting Can we chat at 1pm pacific, today? with a thumbs-up, affirmative response of: Crocker, et al. Expires July 19, 2021 [Page 5] Internet-Draft react January 2021 To: author@example.com From: recipient@example.com Date: Today, 29 February 2021 00:00:10 -800 Message-id: 12345@example.com Subject: Meeting Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Disposition: Reaction {U+1F44E} It could, of course, be more elaborate, such as the first of a MIME multipart sequence. 4.2. Example Display 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: 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. Message: A complete message is often displayed with a tailored section for header-fields, enhancing the format and showing only selected header fields. It might include one for reactions, again showing the symbol and a count. 5. Security Considerations 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. 6. IANA Considerations The React MIME Content-Disposition parameter is registered, per [RFC2183] Content-Disposition parameter name: Reaction Crocker, et al. Expires July 19, 2021 [Page 6] Internet-Draft react January 2021 Allowable values for this parameter: (none) Description: Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic 7. Experimental Goals The 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: o Is there demonstrated interest by MUA developers? o If MUA developers add this capability, is it used by authors? o Does the presence of the Reaction capability create any operational problems for recipients? o Does the presence of the Reaction capability demonstrate additional security issues? 8. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [Emoji-Seq] Davis, M., Ed. and P. Edberg., Ed., "Unicode(R) Technical Standard #51: Unicode Emoji", WEB http://www.unicode.org/reports/tr51/#def_emoji_sequence, September 2020. [Mail-Arch] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Crocker, et al. Expires July 19, 2021 [Page 7] Internet-Draft react January 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Acknowledgements 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 Authors' Addresses Dave Crocker Brandenburg InternetWorking Email: dcrocker@bbiw.net Ricardo Signes Fastmail Email: rjbs@semiotic.systems Ned Freed Oracle Email: ned.freed@mrochek.com Crocker, et al. Expires July 19, 2021 [Page 8]