RFC 9078

Reaction: Indicating Summary Reaction to a Message

📅 published August 2021, from ietf

Reaction: Indicating Summary Reaction to a Message 💖

  • RFC number: 9078, an IETF Request for Comments
  • Authors: D. Crocker (Brandenburg InternetWorking), R. Signes (Fastmail), N. Freed (Oracle)
  • Category: Experimental, so this is for trying things out and seeing what happens 🧪
  • Date: August 2021
  • ISSN: 2070-1721
  • Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates

Abstract ✨

okay so social media already made us all fluent in tapping a thumbs up or a smiley face on a post 🫶 this spec brings that same vibe to Internet Mail, so you can react to an email without typing a whole reply 💌

Status of This Memo 📜

bestie, this one is not an Internet Standards Track spec. It's published so people can examine it, implement it experimentally, and evaluate it 🧪

It's still an Experimental Protocol for the Internet community 🌈 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review before the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved document is a candidate for any level of Internet Standard, though. Check Section 2 of RFC 7841 for the details 🧐

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9078 🔗

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) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📚 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License explains 💅

Table of Contents 🗂️

1.  Introduction
2.  Terminology
3.  Reaction Content-Disposition
4.  Reaction Message Processing
5.  Usability Considerations
  5.1.  Example Message
  5.2.  Example Display
6.  Security Considerations
7.  IANA Considerations
8.  Experimental Goals
9.  Normative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

so you know how everyone on social media taps a thumbs up, a heart, or a smiley to quickly say "I see this and I'm into it" 🥹 That's a summary reaction, and people are super comfortable with it. Some platforms only let you pick from a small menu, and others let you use a whole big set of indicators 🌸

This spec takes that whole social media and instant messaging habit and brings it into Internet Mail 📨

Now, you can already drop emoji into the body of an email reply, no problem. The thing is, there's been no established way to say "this emoji is a summary reaction to that specific message," as opposed to just being random text in a reply 🤷‍♀️ This structured approach lets the recipient's Mail User Agents (MUAs) link the reaction to the original message, and maybe show it in a fancy, distinctive way 🎀

The whole facility is a brand-new MIME Content-Disposition. You use it together with the In-Reply-To header field, and it says that a part of the message holding one or more emojis can be treated as a summary reaction to an earlier message 🦋

2. Terminology 📖

unless this doc says otherwise, the terminology, architecture, and spec notation come from these:

  • [Mail-Arch]
  • [Mail-Fmt]
  • [MIME]

Syntax is written in [ABNF] 🧩

The ABNF rule emoji-sequence comes from [Emoji-Seq]. You can read more about it in Section 3 🌈

Now for the normative language, which follows [RFC2119] and [RFC8174]. These are the BCP 14 key words, and they're the magic words that carry real weight 🪄 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read as BCP 14 [RFC2119] [RFC8174] describes, but only when they show up in all capitals, exactly like they do here 💜

3. Reaction Content-Disposition 🎀

okay the core of it: a message sent as a reply MAY include a part that contains this:

Content-Disposition: reaction

If that field is specified, the part's Content-Type MUST be this:

Content-Type: text/plain; charset=utf-8

The content of this part is limited to a single line of emoji 🍓 Here's the [ABNF]:

part-content    = emoji *(WSP emoji) CRLF

emoji           = emoji-sequence
emoji-sequence  = { defined in [Emoji-Seq] }

base-emojis     = thumbs-up / thumbs-down / grinning-face /
                  frowning-face / crying-face
                  ; Basic set of emojis, drawn from [Emoji-Seq]

; thumbs-up       = {U+1F44D}
; thumbs-down     = {U+1F44E}
; grinning-face   = {U+1F600}
; frowning-face   = {U+2639}
; crying-face     = {U+1F622}

The part-content is either the message's single MIME body or the content portion of the first MIME multipart body part 🧁

The ABNF rule emoji-sequence comes from [Emoji-Seq]. It defines a set of Unicode code point sequences, which must then be encoded as UTF-8. Each sequence forms one single pictograph 🖼️ The BNF syntax in [Emoji-Seq] is different from [ABNF], and it MUST be read the way Unicode documentation uses it. That referenced doc describes these things as sequences of code points 🤓

Note: the part-content can first get parsed into candidate reactions, split by WSP. Any candidate that isn't a single emoji-sequence (per [Emoji-Seq]) is invalid 🚫 Invalid candidates can be handled one at a time, so they don't mess up the rest of the part-content's processing. The leftover candidates form the set of reactions to process. This approach assumes you have some emoji sequence validation mechanism, and this spec doesn't define one.

The rule base-emojis is a simple, common list, or "vocabulary," of emojis 💅 It came from existing practice in social networking and it's meant for similar use. However, supporting it as a base vocabulary is not required. When providers and consumers use a shared set, users interoperate more smoothly, but different groups of users might want their own shared sets instead ✨

The reaction emoji (or emojis) gets linked to the current message's In-Reply-To field. That field points to an earlier message and gives a summary reaction to it [Mail-Fmt]. For the processing details, see Section 4 🦋

Reference to unallocated code points SHOULD NOT be treated as an error. The matching UTF-8-encoded code points SHOULD be processed with the system's default way of showing an unallocated or undisplayable code point 🙈

Note: the "emoji" token looks simple. It is NOT simple 😭 Implementers are well advised not to assume emoji sequences are easy to parse or validate. Among other concerns, an implementation of the Unicode Character Database is required. An emoji is way more than a stand-in for a simple run of characters. One emoji sequence isn't interchangeable with, or equivalent to, another one, and comparing them takes a detailed understanding of the Unicode mechanisms involved. Using an existing Unicode implementation will usually help a ton, and so will understanding the error modes that a chosen implementation might hit 🧠

4. Reaction Message Processing 🔍

The presentation side of reaction processing is MUA-specific and outside the scope of this spec, so each client gets to do its own thing there 💅 As far as the message itself goes, a recipient MUA that supports this mechanism works like this:

  1. If a received message R's header has an In-Reply-To field, check whether it references a previous message that the MUA has sent or received 👀
  2. If R's In-Reply-To: does reference one, check R's message content for a part with a "reaction" Content-Disposition header field. That part can sit at the outermost level or inside a multipart at the outermost level 🪆
  3. If such a part is found and its content follows the restrictions above, remove the part from the message and process it as a reaction ✅
Note: a message's content might include other nested messages. Those can be checked for reactions on their own, separately from the containing message, by running the algorithm above on each contained message 🧚

Again, what happens after a message has been processed successfully is MUA-specific and outside the scope of this spec 🌸

5. Usability Considerations 💭

This spec is about how the information gets structured and carried. It doesn't define any user-level details of use. Still, the design of the user-level stuff around this is everything, so here are some things to think about 🧁

Creation: an email environment is not like a typical social media platform, so there are big, potentially tricky choices in the user interface for signaling a reaction 🤔 Should the reaction go only to the original author, or to everyone? Should it always be its own discrete message with nothing but the reaction, or should the user be able to add other content too? (Heads up: sending the reaction in a normal email message lets you include that other content.) 💌

Display: reaction indications might feel more useful when they're shown close to the original message, rather than just buried in the email response thread 👑 Handling multiple reactions from the same person is also a chance for an interesting user experience design choice 🎨

Culture: an image meant to act as a semantic signal is shaped by cultural factors, and those vary a lot in complexity and nuance 🌍 It's important to remember that the author's intent when sending a particular emoji might not match how the recipient reads it. Even simple, super common emojis can have these cultural differences 🙈

More of this (the examples, the security stuff, the references, all of it) is coming in part 2 🦋💖

5.1. Example Message

okay so here's a super simple exchange 💌 Someone asks a question and the reply is just a thumbs-up 👍

To: recipient@example.org
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?

and then the recipient reacts with a thumbs-up, the affirmative response, which looks like this 🥹

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+1F44D}

The {U+1F44D} thing is just a placeholder so humans can read it 🙈 What actually gets sent is the UTF-8-encoded character itself, so the wire has the real 👍 in it.

And of course this could get way fancier, like being the first part of a MIME multipart sequence ✨

5.2. Example Display

Okay, real talk, the most important thing here is that actually using this feature needs really careful usability design and testing 🧐 The examples below are simple ones that have not been tested, just little sketches of how a reaction could show up in a summary list.

  • Summary: Message lists in a folder already have columns like Subject, From, and Date 📋 You could add one more column for common reactions, plus a count of how many of each you've gotten. Cute, right? 🍓
  • Message: A full message usually gets its own fancy section for header fields, showing only the ones that matter. You could add a pseudo-field for reactions too, showing the symbol and a count 💅

6. Security Considerations

Okay, this part is serious bestie, so listen up 🫶 This spec only uses message content that's a strict subset of what's already possible, so it doesn't introduce any new content-specific security issues. People might think that because the content is structured it's suddenly a brand new threat surface 😬 but nobody has actually shown that it is.

Now, this spec does define its own Content-Disposition value for specialized message content, and handling that content differently from everything else in the body could bring in vulnerabilities 🚨 And since this feature will probably lead to brand new user interaction features, it might also open the door to new social engineering attacks. Be careful out there, fr fr 💀

7. IANA Considerations

IANA has registered the Reaction MIME Content-Disposition parameter, per [RFC2183] 🎀 Here's the registration:

Content-Disposition parameter name:  reaction

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

8. Experimental Goals

The basic, email-specific mechanics for this are already well established and well understood, so the real question marks are a few specific things 🤔

  • Technical issues in using emojis within a message body
  • Market interest
  • Usability

So for this Experimental spec, the questions to answer are:

  • Is there demonstrated interest by MUA developers?
  • If MUA developers add this capability, is it used by authors?
  • Does the presence of the Reaction capability create any operational problems for recipients?
  • Does the presence of the Reaction capability demonstrate additional security issues?
  • What specific changes to the specification are needed?
  • What other comments will aid in use of this mechanism?

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

9. Normative References

Here are all the references this spec leans on, bestie 📚

Acknowledgements

Okay, the people-thanks part 🫶 This spec got substantive commentary on three IETF mailing lists, and the history is kind of iconic 🌈

It started as a private exercise in July 2020, with private discussion, under the name draft-crocker-reply-emoji. Then it morphed into draft-crocker-inreply-react, with lots of great discussion on the ietf-822 mailing list (https://www.ietf.org/mailman/listinfo/ietf-822) from September through November 2020. That discussion led to a huge change: instead of proposing a new header field, it became a new Content-Disposition type. It also made the text about Unicode way better, and two more coauthors joined the party 👑

In November 2020, the Dispatch mailing list (https://www.ietf.org/mailman/listinfo/dispatch) was asked about the draft. It didn't get any discussion, but it did get one statement of interest 👀

A 4-week Last Call went out on this document in January 2021 💅 It sparked a ton of fresh discussion on the last-call mailing list (https://www.ietf.org/mailman/listinfo/last-call) and more changes to the document. After Last Call wrapped up, extra concerns about the Unicode-related details came up, so even more changes happened 🌸 A challenge also came in that prompted the current version of this Acknowledgements section.

If you want the full tea on the document's history, go dig through the archives for those three lists and search the Subject fields for "react" 🍵

Authors' Addresses

Meet the authors 💜

Dave Crocker
Brandenburg InternetWorking

Email: dcrocker@bbiw.net


Ricardo Signes
Fastmail

Email: rjbs@semiotic.systems


Ned Freed
Oracle

Email: ned.freed@mrochek.com
📦 where this page comes from