On the process issue, the reason for Experimental is that we don’t know the practical aspects of implementing this in MUAs and having users actually use them, both in sending reactions and in viewing the reactions we get back. I’m very pleased that this document actually contains Section 7, which describes what the experiment needs to answer (thanks, Dave!), and wish all Experimental drafts did that.
Given the uncertainty about when this is actually practical, but the necessity of having a standard protocol to try in order to find out, I think Experimental is the right approach.
Barry
On Sat, Jan 16, 2021 at 4:28 PM Eliot Lear <lear@xxxxxxxxx> wrote:
IMHO Email has been missing these reactions for years, and this is a great idea. I have several comments about the text, and one process comment. Let me start with the latter: was there a discussion about whether to make this PS rather than experimental? I see one really substantial issue with the draft that isn’t discussed, but I don’t know that it is insurmountable (discussed below).On the text, one issue in Section 2, in the ABNF:part-content = emoji *(lwsp emoji) CRLF emoji = emoji_sequence emoji_sequence = { defined in [Emoji-Seq] } base-emojis = thumbs-up / thumbs-down / grinning-face / frowning-face / crying-face thumbs-up = {U+1F44D} thumbs-down = {U+1F44E} grinning-face = {U+1F600} frowning-face = {U+2639} crying-face = {U+1F622}I don’t understand where base-emojis are used. Was “emoji" meant to be "emoji_sequence / base-emojis”?In Security Considerations in Section 5, I think it’s probably useful to talk about the risk of spoofed messages creating spoofed reactions, perhaps a lot of them. What mitigation techniques should be employed? One might be to look for a valid Authentication-Results header.Finally, what happens if the same source sends two reactions in two separate emails? Can one send a blank message to remove a reaction?In Section 3, one nit:... 1. If a received message R contains an In-Reply-To: header-field, check to see if it references a previous message the MUA has sent or received. 2. If R's In-Reply-To: does reference one, then check R's message content for a part with a "reaction" content-disposition at either the outermost level or as part of a multipart at the outermost level.As “R” is only ever referenced here, my suggestion is to either lose the variable, or to refer to the other message with a variable, for consistency.Again, thanks for the draft, and I look forward to its approval, preferably as a PS ;-)EliotOn 16 Jan 2021, at 02:14, The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from an individual submitter to consider the
following document: - 'React: Indicating Summary Reaction to a Message'
<draft-crocker-inreply-react-06.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2021-02-12. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
The popularity of social media has led to user comfort with easily
signaling basic reactions to an author's posting, such as with a
'thumbs up' or 'smiley' graphic. This specification permits a
similar facility for Internet Mail.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
