Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9078.
Authors Dave Crocker , Ricardo Signes
Last updated 2020-10-16
RFC stream (None)
Formats
Reviews
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 9078 (Experimental)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-crocker-inreply-react-02
Network Working Group                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Intended status: Informational                                 R. Signes
Expires: April 19, 2021                                 Semiotic Systems
                                                        October 16, 2020

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

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 19, 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 & Signes         Expires April 19, 2021                 [Page 1]
Internet-Draft                    react                     October 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  In-Reply-React  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Usability Considerations  . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   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].  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.

Crocker & Signes         Expires April 19, 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 = 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].

   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
   [MIME-Enc].

   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.  [MIME] By making the text be the full header field,

Crocker & Signes         Expires April 19, 2021                 [Page 3]
Internet-Draft                    react                     October 2020

   it also allows MUAs that do support the mechanism to identify this
   redundant information and possibly remove it from display.

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 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.  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.

5.  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 & Signes         Expires April 19, 2021                 [Page 4]
Internet-Draft                    react                     October 2020

      Related information:    None

6.  References

6.1.  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-Enc]
              Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

6.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.

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

Crocker & Signes         Expires April 19, 2021                 [Page 5]
Internet-Draft                    react                     October 2020

   R. Signes
   Semiotic Systems

   Email: rjbs@semiotic.systems

Crocker & Signes         Expires April 19, 2021                 [Page 6]