Re: [ietf-822] What about doing more?

[Hector Santos <[e-mail]>]

On 10/8/2020 2:13 PM, Dave Crocker wrote:
>
> <plea>
>
> What will make the basic mechanism useful to its specific goal,
> sufficient as a specification, reasonable to implement, and as simple
> as possible without defeating its other goals?
>
> </plea>

There would be many implementation and design questions.   First 
thought to mind, email has too much RFC5322 creation and reply 
overhead for simplistic, small footprint "dynamic notification" 
reaction reply concepts.

Should reactions also come with Body content?   Akin to some MUA will 
popup a "No Subject. Continue to send?" dialog. To react to a message 
with no new content also popup a dialog?

Could there be a minimum reply set of just sending headers without 
resending/quoting body content?

From:
To:
Subject:
In-reply-react:
Message-ID:  <-- key anchor of threads where reaction apply.

Also, does it have to be resign? DKIM?  ARC?  DMARC, DMARC-Reports? 
Serious more overhead just for reaction.

Finally, consider what Twitter is doing with "retweet?"   It has two 
option:

- Retweet (No comment necessary)
- Retweet with comment

It is my understanding, for lack of a better term, lets call it the 
"Trump Rule" change, Twitter is now "testing" eliminating the 
"retweet" because of the abuse seen with just retweeting (a form of a 
reaction) controversial (fake news) tweets without adding any comment. 
I have a feeling it is enabled on a per user profile basis which would 
be without a doubt something I would add to our mail user profile 
system "[_] Allow Email Reaction" a group profile concept.

Overall, I like the concept. Its applies well at the local mail level, 
but in a network form, it has a high overhead concern due to the 
nature of IMF and SMTP.  It can be unintentionally and intentionally 
abused when some of the above concerns are not considered and addressed.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos