Subject: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-03.txt

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Oct 2020 08:05:02 -0700

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.

d/

-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-inreply-react-03.txt
Date: Thu, 22 Oct 2020 08:00:14 -0700
From: [email-masked]
To: Ricardo Signes <[email-masked]>, R. Signes 
<[email-masked]>, Dave Crocker <[email-masked]>, Ned Freed 
<[email-masked]>

A new version of I-D, draft-crocker-inreply-react-03.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-crocker-inreply-react
Revision:	03
Title:		React: Indicating Summary Reaction to a Message
Document date:	2020-10-22
Group:		Individual Submission
Pages:		6
URL: 
https://www.ietf.org/archive/id/draft-crocker-inreply-react-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-inreply-react
Htmlized:       https://tools.ietf.org/html/draft-crocker-inreply-react-03
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-03

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: cketti <[email-masked]>
Date: Fri, 23 Oct 2020 16:29:38 +0200

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

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

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

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.

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Oct 2020 07:46:31 -0700 (PDT)

> like this adds a lot of complexity for a case that's unlikely to be very

It more or less falls out of the design, so I don't see a reason not to
provide it.

> body for compatibility reasons.

And now you've created an unnecessary silly state. Given that you have
to put the reaction in the body in order to maintain backwards compatibility,
why not take advantage of that fact and *only* put it in the body?

> easier for clients and users.

There's no such conflation in the present proposal. A part that's
marked as a reaction is a reaction only. The fallback to being
treated as a reply is just that: A fallback.

That said, I suppose we could restrict things to reactions having to be a
separate message with a single part. In practice this isn't as much of a
restriction as it appears since an ever-increasing percentage of messages are
structured objects, which can't be combined with a reaction. But there's
already been feedback objecting to the additional message traffic, so I think
this needs to be a decision made by the group.

> supposed to contain additional text there's no harm in filtering out

They can do that by filtering on the content-disposition field.

> supports search by header-field. Using a body part would make this a lot

Once again, this can be done by looking for the content-disposition.

> actual body (or body structure).

Absolutely. But someting is very wrong with your IMAP server if the
cost of downloading a body part only a few characters long is an issue.

> messages containing text and also a reaction.

I fail to see the relevance of what's incide the social media sausage factory.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 23 Oct 2020 08:32:42 -0700

>> easier for clients and users.

It's not obvious to me that this is true. (In fact, I suspect it isn't.) 
  So feel free to provide a comparison between the two approaches, in 
terms of affects on clients and users.

> this needs to be a decision made by the group.

There is an appeal of 'purity' in having a reaction be in a message 
containing only a reaction.  The downside is that email is relatively 
slow and there is an appeal in permitting commentary to be carried in 
the same message as the reaction.  (It isn't uncommon in social media to 
mark a reaction and then write a comment.)

>> annoyed by them. 

For any action, there is an equal and opposite reaction.  In this case 
that means doing anything is certain to result in someone, somewhere 
being unhappy about the action.  Ultimately, this is a user-to-user 
issue, not something to fix in the software...

>  Being able to filter out messages by header-field is a
>> fairly common feature of email clients. 

Yes, but it's one of many features that average users do not know about 
and have no motivation to learn.

>If reaction messages are not

+1

> Once again, this can be done by looking for the content-disposition.

+1

>> 3. Clients would most likely want to hide reaction messages

Why?

  and only
>> reaction to the original message" either. 

They don't have the construct of 'carrying' anything.  But it's common 
to be able to mark a reaction AND post a comment.

d/

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Oct 2020 08:43:37 -0700 (PDT)

> and have no motivation to learn.

It occurs to me that the best solution for such users is to use a
reaction-enabled client and disable display of reactions.

I agree that asking such users to configure elaborate filters in their email
client in order to be able to avoid seeing reactions, regardless of the
specifics, is asking much too much.

Of course nothing here prevents the use of emojis in regular message content,
although adoption of this mechanism might reduce their use a bit. So this isn't
going to satisfy the true emojiphobic - and yes, such people do exist...

				Ned

---

From: cketti <[email-masked]>
Date: Fri, 23 Oct 2020 18:24:29 +0200

> treated as a reply is just that: A fallback.

The proposal doesn't mandate it. But currently it's certainly an option
to have a text part containing a reply and a reaction part in the same
message.

> this needs to be a decision made by the group.

Isn't not wanting additional traffic an additional reason to limit
reaction messages to only a reaction? That way people who don't like
them, say on their mailing list, can easily reject those messages
without users being annoyed that they have to resend the text without a
reaction or mailing list software having to rewrite the message to
remove the reaction part.

> They can do that by filtering on the content-disposition field.

This is only true if the reaction part is the only part and the
header-field is part of the top-level header.

> Once again, this can be done by looking for the content-disposition.

Again, I believe this is only true if we don't allow multiparts.

> cost of downloading a body part only a few characters long is an issue.

It would be a client-side optimization. Not having to issue an
additional command to fetch message bodies certainly doesn't hurt, both
bandwidth- and latency-wise.

But I'm not hung up on this. The restriction to the reaction part being
the only part would be fine for me, too.

> I fail to see the relevance of what's incide the social media sausage factory.

I guess I wanted to say that users are used to this limitation and don't
seem to be bothered by it. You can add a reaction and write a comment.
It's two UI operations, it could easily be two different emails.

---

From: cketti <[email-masked]>
Date: Fri, 23 Oct 2020 19:20:04 +0200

On 23.10.20 17:32, Dave Crocker wrote:
> It's not obvious to me that this is true. (In fact, I suspect it
> isn't.)  So feel free to provide a comparison between the two
> approaches, in terms of affects on clients and users.

Let's just take the filter example. It's quite easy to write one that
checks for the existence of a certain header field (I don't care much if
it's "In-Reply-React" or "Content-Disposition: Reaction" in the
outermost header).

It's quite another thing to write one for:

> check for a part with a "reaction" content-disposition at either the
outermost level or as part of a multipart at the outermost level.

>> 3. Clients would most likely want to hide reaction messages

Maybe you're the type of person who prefers this:

Original message

3 👍  1 👎  1 🤔

User A reacted with 👍
User B reacted with 👍
User C reacted with 👎
User C: I don't like this because…
User D reacted with 👍 🤔

There's nothing wrong with that and (minus the summary) it's more or
less what you get with clients that don't support reactions.

However, I prefer a UI where reactions are summarized and displayed on
the original message. Who reacted how can still be displayed as a popup
or in an additional screen. But I don't want to see that information by
default. Seeing this is how popular social media/chat sites do things
I'm guessing I'm not alone in wanting this.

Original message

3 👍  1 👎  1 🤔

User C: I don't like this because…

This is the main reason why I believe recognizing reaction messages
should be as easy as possible. Combining reactions and comments in one
message adds complexity without any meaningful advantage I can see.

---

From: Ned Freed <[email-masked]>
Date: Fri, 23 Oct 2020 09:54:19 -0700 (PDT)

> to have a text part containing a reply and a reaction part in the same

Which means they are separate and not conflated.

> reaction messages to only a reaction?

Forcing separate messages is funny way to define less traffic,

> That way people who don't like

First, as I previously noted, the best way for those not interested in seeing
reactions to achieve that goal is to use a reaction-enabled client and disable
display of reactions.

Second, I am *extremely* skeptical that people who dislike reactions
specifically exist in such numbers to justify mailing list support for
reaction-stripping, let alone torquing the protocol itself in such a fashion as
to cater to their interests.

Third, even if they do exist, mailing lists already commonly provide the
ability to strip attachments, so this just isnt that big of a reach.

> header-field is part of the top-level header.

Yes, which is why I suggested seeing if there is general agreement this and
similar use-cases is worth catering to by restricting the protocol to only be 
used in this way.

The bottom line is this entire line of argument hinges on there being
sufficient need to limit the protocol in order to support easier suppression of
reactions. If there's general agreement that there is then I guess I'm OK with
limiting the protocol, but I haven't seen anything like that so far.

				Ned

---

From: cketti <[email-masked]>
Date: Fri, 23 Oct 2020 20:41:17 +0200

> limiting the protocol, but I haven't seen anything like that so far.

I mainly look at this through the lens of a client author with a
particular UI in mind. I don't really care about filtering reactions
because people don't want to see them. But the same mechanism that would
make such filtering easy also enables a less complex implementation in
the code base I'm working on (mobile client, a message is rarely
downloaded in its entirety).

As mentioned in another email I'd like to not include reaction messages
in the message list displayed to the user (just imagine regularly
getting 10+ emoji-only reactions per message; seeing all individual
messages would get annoying pretty fast). Instead I'd like to display a
"reaction summary" on the original message.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Oct 2020 05:48:36 -0700

> than using a new header-field, which had some significant drawbacks.

There have been some postings about the original version of the draft, 
but not much on the latest revision, which adopted Ned's MIME-based 
approach.

Any comments, criticisms, or suggested revisions on it?

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Oct 2020 18:31:07 -0700

Just saw a list of additional emojis to consider...

https://www.facebook.com/photo/?fbid=10224265847616475&set=a.10213545030042736

d/

---

From: Francesco Gennai <[email-masked]>
Date: Thu, 29 Oct 2020 07:22:04 +0100

> https://www.facebook.com/photo/?fbid=10224265847616475&set=a.10213545030042736
😷
I'm laughing.
Can you see?
If not, I think it needs an additional text part in the reaction
message.... 😂

/Francesco

---

From: Francesco Gennai <[email-masked]>
Date: Thu, 29 Oct 2020 08:33:55 +0100

On Wed, Oct 28, 2020 at 1:50 PM Dave Crocker <[email-masked]> wrote:

> I like the simpler solution, where the reaction message is only composed
by the top level MIME part.
I think it is more flexible and scalable than a multipart message structure
(mainly by a point of view of a client developer).
But, I was thinking:
this nice idea came from the socials where (in some cases like facebook)
the reaction can be an emoji or a comment (or both).
So, why not to define two types of reaction:
- emoji
- short text (comment)
The short text reaction is similar to a reply by a text message, but will
have a different semantics so that clients developers could use it
in a different way than a reply message.
Emoji reactions and short-text reactions should be carried by two simple
reaction message types. "Simple" is for: a message with only the top level
MIME part.

/Francesco

---

From: Ned Freed <[email-masked]>
Date: Thu, 29 Oct 2020 04:00:45 -0700 (PDT)

Francesco Gennai <[email-masked]> wrote:

Nice to hear from you Francesco!

> (mainly by a point of view of a client developer).

Thanks for the feedback.

> in a different way than a reply message.

It's not clear to me how this differs from a regular response, or perhaps
more to the point, how a client would handle it differently.

> reaction message types. "Simple" is for: a message with only the top level

Well, one of the nice things about this proposal is as long as we make it clear
that the current content-disposition is only defined in conjuction with an
"emoji", we can always extende it later to other uses. But for now I think
keeping the ask we're making of client developers small is a good idea.

				Ned

---

From: [email-masked]
Date: Thu, 29 Oct 2020 14:28:21 +0100

Hi, Ned.

> Nice to hear from you Francesco!
:-)

... ..
   ...
> more to the point, how a client would handle it differently.

The user reading a message could select an emoji or insert a comment in 
a short reaction text field.
For both cases a reaction email will be sent by the client.
For the comments (reaction text) the user doesn’t need to pass through 
the “standard” path to compose a reply message.

On the opposite, when a client displays a message it can “add” a view of 
the reactions (emoji, text or both). The reaction text is not threated 
like a reply message.

I think that we can see the benefits mainly on small displays, like 
smartphone.

That said...

> keeping the ask we're making of client developers small is a good idea.

.... I agree with you that keeping the ask small is a good idea and that 
we can always extend the specification in the future.

/Francesco

-- 
Istituto di Scienza e Tecnologie dell'Informazione (ISTI)
National Research Council (CNR)
Area della Ricerca CNR di Pisa
Via G. Moruzzi 1, 56124 Pisa ITALY
phone: +39 050 315 2592
email: [email-masked]