React: Indicating Summary Reaction to a Message
draft-crocker-inreply-react-08

Network Working Group                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Intended status: Experimental                                  R. Signes
Expires: August 16, 2021                                        Fastmail
                                                                N. Freed
                                                                  Oracle
                                                       February 12, 2021

            React: Indicating Summary Reaction to a Message
                     draft-crocker-inreply-react-08

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 August 16, 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 August 16, 2021                [Page 1]
Internet-Draft                    react                    February 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  . . . . . . . . . . . . . . . . . .   4
     4.1.  Example Message . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Example Display . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Experimental Goals  . . . . . . . . . . . . . . . . . . . . .   6
   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 using 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
   notation used in this document are incorporated from [Mail-Arch],

Crocker, et al.          Expires August 16, 2021                [Page 2]
Internet-Draft                    react                    February 2021

   [Mail-Fmt], [MIME], and [ABNF].  The ABNF rule Emoji-Seq is inherited
   from [Emoji-Seq].

   Normative language, per [RFC8174]:

      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

   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 defines a
   set of octet sequences, each of which forms a single pictograph.

   The rule base-emojis MAY be used as a simple, common list, or
   'vocabulary' of emojis.  It was developed from some existing
   practice, in social networking, and is intended for similar use.
   However support for it as a base vocabulary is not required.  Having
   providers and consumers employ a common set will facilitate user
   interoperability, but different sets of users might want to have
   different, common (shared) sets.

Crocker, et al.          Expires August 16, 2021                [Page 3]
Internet-Draft                    react                    February 2021

   The emoji(s) express a recipient's summary reaction to the specific
   message referenced by the accompanying In-Reply-To header field, for
   the message in which they both are present.  [Mail-Fmt].  For
   processing details, see Section 3.

   Reference to unallocated code points SHOULD NOT be treated as an
   error; the corresponding octets 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 header
       field, 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.

   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

Crocker, et al.          Expires August 16, 2021                [Page 4]
Internet-Draft                    react                    February 2021

      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.  The handling of multiple
      reactions, from the same person, is also an opportunity for
      possibly-interesting user experience design choice.

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:

   To: author@example.com
   From: recipient@example.org
   Date: Today, 29 February 2021 00:00:10 -800
   Message-id: 56789@example.org
   In-Reply-To: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 :

Crocker, et al.          Expires August 16, 2021                [Page 5]
Internet-Draft                    react                    February 2021

   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 add a field 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.  The fact that this content is structured
   might seem to make it a new threat surface, but there is no analysis
   demonstrating that it does.

   This specification defines a distinct Content-Disposition value, for
   specialized message content.  Processing that handles the content
   differently from other content in the message body might introduce
   vulnerabilities.

6.  IANA Considerations

   The IANA is request to register the React MIME Content-Disposition
   parameter, per [RFC2183]

    Content-Disposition parameter name:    React

   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?

Crocker, et al.          Expires August 16, 2021                [Page 6]
Internet-Draft                    react                    February 2021

   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.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc2183>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Crocker, et al.          Expires August 16, 2021                [Page 7]
Internet-Draft                    react                    February 2021

Appendix A.  Acknowledgements

   This specification has had substantive commentary on the ietf-822,
   dispatch, and last-call mailing lists.  Active commentary and
   suggestions were offered by: Nathaniel Borenstein, Richard Clayton,
   Bron Gondwana, Nick Hilliard, Kjetil Torgrim Homme, Barry Leiba,
   Valdis Kl&#275;tnieks, Eliot Lear, Barry Leiba, 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 August 16, 2021                [Page 8]