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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822