Internet-Draft reaction April 2021
Crocker, et al. Expires 16 October 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-crocker-inreply-react-13
Published:
Intended Status:
Experimental
Expires:
Authors:
D. Crocker
Brandenburg InternetWorking
R. Signes
Fastmail
N. Freed
Oracle

Reaction: Indicating Summary Reaction to a Message

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 16 October 2021.

▲

Table of Contents

1. Introduction

The popularity of social media has led to user comfort with easily signaling summary reactions to an author's posting, by using 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 extends this existing practice in social media and instant messaging into 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 can be be treated as a summary reaction to a previous message.

2. Terminology

Unless provided here, terminology, architecture and specification notation used in this document are incorporated from:

, and syntax is specified with

The ABNF rule Emoji-Seq is inherited from [Emoji-Seq]; details are in Section 3.

Normative language, per [RFC8174]:

3. 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 part-content is either the entire content portion of a message's single MIME body or it is the content portion of the first MIME multi-part body-part that constitute a message's body.

The ABNF rule emoji_sequence is inherited from [Emoji-Seq]. It defines a set of Unicode code point sequences, which must then be encoded as UTF-8. Each sequence forms a single pictograph. The BNF syntax used in [Emoji-Seq] differs from [ABNF], and MUST be interpreted as used in Unicode documentation. The referenced document describes these as sequences of code points.

Note:
The part-content can first be parsed into candidate reactions, separated by WSP. Each candidate reaction that does not constitute a single emoji-sequence (as per [Emoji-Seq]) is invalid. Invalid candidates can be treated individually, rather than affecting the remainder of the part-content's processing. The remaining candidates form the set of reactions to be processed. This approach assumes use of a mechanism for emoji sequence validation that is not specified here.

The rule base-emojis is provided 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.

The reaction emoji(s) are linked to the current message's In-Reply-To: field, which references an earlier message, and provides a summary reaction to that earlier message. [Mail-Fmt]. For processing details, see Section 4.

Reference to unallocated code points SHOULD NOT be treated as an error; the corresponding UTF-8 encoded code points SHOULD be processed using the system default method for denoting an unallocated or undisplayable code point.

Note:
The "emoji" token looks simple. It isn't. Implementers are well-advised not to assume that emoji sequences are trivial to parse or validate. Among other concerns, an implementation of the Unicode Character Database is required. An emoji is more than a stand-in for a simple alternation of characters. Similarly, one emoji sequence is not interchangeable with, or equivalent to, another one, and comparisons require detailed understanding of the relevant Unicode mechanisms. Use of an existing Unicode implementation will typically prove extremely helpful, as will an understanding of the error modes that may arise with a chosen implementation.

4. 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's header contains an In-Reply-To: field, check to see if it references a previous message that 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.
Note:
A message's content might include other, nested messages. These can be analyzed for reactions, independently of the containing message, applying the above algorithm for each contained message, separately.

Again, the handling of a message that has been successfully processed is MUA-specific and beyond the scope of this specification.

5. 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. The handling of multiple reactions, from the same person, is also an opportunity for possibly interesting user experience design choice.
Culture:
The use of an image, intended to serve as a semantic signal, is determined and affected by cultural factors, which differ in complexity and nuance. It is important to remain aware that an author's intent when sending a particular emoji might not match how the recipient interprets it. Even simple, commonly used emojis can be be subject to these cultural differences.

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

The Unicode character, represented here as "{U+1F44E}" for readability, would actually be sent as the UTF-8-encoded character.

The example could, of course, be more elaborate, such as the first of a MIME multipart sequence.

5.2. Example Display

Repeating the caution that actual use of this capability requires careful usability design and testing, this section describes 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. A pseudo-field might be added, for reactions, again showing the symbol and a count.

6. Security Considerations

This specification employs message content that is a strict subset of existing possible 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. Since this capability is likely to produce new user interaction features, that might also produce new social engineering vulnerabilities.

7. IANA Considerations

The IANA is requested to register the Reaction MIME Content-Disposition Parameter, per [RFC2183]

Content-Disposition parameter name:
reaction
Description:
Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic
Reference:
[this document]

8. Experimental Goals

The basic, email-specific mechanics for this capability are well-established and well-understood. Points of concern, therefore, are:

So the questions to answer for this Experimental specification are:

Please send comments to ietf-822@ietf.org.

9. Normative References

[ABNF]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
[Emoji-Seq]
Davis, M., Ed. and P. Edberg., Ed., "Unicode® Technical Standard #51: Unicode Emoji", WEB http://www.unicode.org/reports/tr51/#def_emoji_sequence, .
[Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, , <https://www.rfc-editor.org/rfc/rfc5598>.
[Mail-Fmt]
Resnick, P., Ed., "Internet Message Format", RFC 5322, , <https://www.rfc-editor.org/rfc/rfc5322>.
[MIME]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, , <https://www.rfc-editor.org/rfc/rfc2045>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

Appendix A. Acknowledgements

This specification had substantive commentary on three IETF mailing lists.

This work began as a private exercise, in July 2020, with private discussion, for draft-crocker-reply-emoji. It morphed into draft-crocker-inreply-react, with significant discussion on the ietf-822 mailing list, September through November 2020. The discussion produced a fundamental change from proposing a new header field to instead defining a new Content-Disposition type, as well as significantly enhancing its text concerning Unicode. It also produced two additional co-authors.

In November 2020, the Dispatch list was queried about the draft, but produced no discussion, though it did garner one statement of interest.

A 4-week Last Call was issued on the document, January 2021, resulting in quite a bit of fresh discussion on the last-call mailing list, and producing further changes to the draft. After Last Call completed, additional concerns were surfaced, about the Unicode-related details, producing yet more changes to the draft. It also produced a challenge that prompted the current version of the Acknowledgements section.

Readers who are interested in the detail of the document's history are encouraged to peruse the archives for the three lists, searching Subject fields for "-react".

Authors' Addresses

Dave Crocker
Brandenburg InternetWorking
Ricardo Signes
Fastmail
Ned Freed
Oracle