On 22.10.20 17:05, Dave Crocker wrote:
Ned's MIME-based approach, for carrying the raction emoji's, is better
than using a new header-field, which had some significant drawbacks.
Simply put, a reaction is a form of content, so carry it as content.
Is the ability to compose a reply message with meaningful text *and* an
emoji reaction really an important feature of this proposal? It feels
like this adds a lot of complexity for a case that's unlikely to be very
I propose the following: Return to the header-field. Reaction messages
should only contain a textual representation of the header value in the
body for compatibility reasons.
Not conflating reply text with a summary reaction makes a lot of things
easier for clients and users.
1. There will be users who won't care about emoji reactions and will be
annoyed by them. Being able to filter out messages by header-field is a
fairly common feature of email clients. If reaction messages are not
supposed to contain additional text there's no harm in filtering out
2. Using a header-field would make it easy to perform a server-side
search to find all reactions to a given message. IMAP, for example,
supports search by header-field. Using a body part would make this a lot
3. Clients would most likely want to hide reaction messages and only
display the reactions on the original message. By using a header-field
clients that in a first step only download a set of interesting
header-fields can identify such messages and never have to download the
actual body (or body structure).
To my knowledge social networks don't support "comment carrying an emoji
reaction to the original message" either. Yes, we are able to do this
using email. But should we? As a client author I would be very annoyed
if I had to deal with reaction-only messages that should be hidden and
messages containing text and also a reaction.
ietf-822 mailing list