[Top] [All Lists]

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

2020-10-22 11:17:14
On 10/8/2020 2:13 PM, Dave Crocker wrote:


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?


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?

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,

ietf-822 mailing list