Subject: Re: [ietf-822] A "Reaction" strawman to throw into the mix

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Nov 2020 09:24:02 -0800

On 10/29/2020 10:49 PM, Pete Resnick wrote:
> it reuses existing pieces of infrastructure that seem to fit this use,

Except that, really, this use is semantically quite different from the 
intended use of MDN (RFC 8098):

>    "...used by a Mail User
>    Agent (MUA) or electronic mail gateway to report the disposition of a
>    message after it has been successfully delivered to a recipient."

The goal of indicating a recipient's reaction is quite different from 
indicating disposition of a message.  The term "laying violation" comes 
to mind, in spite of this not quite being a matter of layers.

In structural terms, the MDN is also a more constrained environment than 
a general email message.  Hence, using it for reactions limits the 
context for including reactions.

Adding the ability to have a reply message include content tagged as a 
reaction adds to the semantics of email exchange.

Having a message designed for signaling information, about message 
handling, be modified to include end-user reactions distorts its 
original purpose and limits the added function.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Nov 2020 10:00:00 -0800

On 11/2/2020 9:24 AM, Dave Crocker wrote:
> term "laying violation"

sigh.  challenging pronunciation apparently infected my typing (and my 
proofreading)...

    laying -> layering

of course.

d/

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2020 16:00:04 -0500

In article <[email-masked]> you write:
>    disposition-modifier /= reaction-word / reaction-emoji
>    reaction-word = Atom
>    reaction-emoji = emoji_sequence ; defined in [Emoji-Seq]

Urrgh. That seems overly clever. I like Ned's design because in MUAs
that don't know about reactions, it is a message containing the
reaction, which is not awful. MUAs that know about reactions can do UI
tricks to tie the reaction to the original message.

R's,
John

PS: By the way, if we're accreting features, I demand to be able to
add snippets of Emojicode, like I can add Javascript to HTML pages.

https://www.emojicode.org/

---

From: "Pete Resnick" <[email-masked]>
Date: Mon, 02 Nov 2020 15:19:14 -0600

On 2 Nov 2020, at 11:24, Dave Crocker wrote:

> indicating disposition of a message.

I don't disagree. However, the semantics provided by MDN is that of 
associating a disposition with a particular message, and it has all of 
the machinery to do that association. Associating a reaction with the 
original messages seems to me much the same as associating an indication 
that a message was "read" or "dispatched" or "deleted". Yes, it 
definitely extends the purpose of MDNs, but it doesn't seem like a huge 
stretch.

> In structural terms, the MDN is also a more constrained environment 
> than a general email message.  Hence, using it for reactions limits 
> the context for including reactions.

How so? You do have a user-readable part to include a message to the 
user, which can be any sort of content type.

> reaction adds to the semantics of email exchange.

When I think of reactions, I think of providing a UI to add a "Like" 
button or similar. That seems separate to me from replies, and in some 
cases replaces it. Having the the user readable part allows you to do a 
reply should you desire, but I suspect the primary kind of 
implementation for this kind of feature is a one-hit button for 
indicating a reaction to a message, similar to the sort that I've seen 
for implementing "I read this." Both MDNs and a reaction strike me as 
"add this adornment to the sender's message" rather than "send this 
message as a reply to the sender's message". MDNs seems semantically 
closer to the purpose, and the implementation of adding a reaction, both 
on the sender's side and the receiver's side, seems closer to MDNs.

> original purpose and limits the added function.

As I said, I agree that this is a change in purpose for MDNs, but I 
don't see it as particularly horrible distortion.

But as I said at the beginning, I can certainly live with Ned's 
proposal. MDNs just struck me as cleaner.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 3 Nov 2020 18:03:43 +0100

On Mon 02/Nov/2020 22:19:14 +0100 Pete Resnick wrote:
> When I think of reactions, I think of providing a UI to add a "Like" button or 
> similar. That seems separate to me from replies, and in some cases replaces it. 
> Having the the user readable part allows you to do a reply should you desire, 
> but I suspect the primary kind of implementation for this kind of feature is a 
> one-hit button for indicating a reaction to a message, similar to the sort that 
> I've seen for implementing "I read this." Both MDNs and a reaction strike me as 
> "add this adornment to the sender's message" rather than "send this message as 
> a reply to the sender's message". MDNs seems semantically closer to the 
> purpose, and the implementation of adding a reaction, both on the sender's side 
> and the receiver's side, seems closer to MDNs.

+1, this seems similar to the return receipt behavior.  My MUA is configured to 
always ask whether to acknowledge or ignore a Disposition-Notification-To: 
request.  It is a kind of reaction indeed.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Nov 2020 09:12:18 -0800

> associating a disposition with a particular message,

That's what In-Reply-To: does, more generally.

> and it has all of 
> the machinery to do that association.

That's what MUA use of In-Reply-To: for threading does.

> Associating a reaction with the 
> that a message was "read" or "dispatched" or "deleted".

I don't recall seeing a discussion here (or elsewhere) that looked for 
support of MDNs, that way, in MUAs.

> Yes, it 

Whereas going from a handling semantic to substantive recipient content 
semantic does seem like quite a basic change to me.

> button or similar. That seems separate to me from replies, and in some 

That's the problem with focusing on a particular, user-level 
implementation choice, rather than the underlying semantics -- the 
'nature' -- of what is being done.

> reply should you desire,

Except that that's not the nature of MDNs.  And it's not how they are 
(typically?  Ever?) implemented.

d/