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:
I don’t understand where base-emojis are used. Was “emoji" meant to be "emoji_sequence / base-emojis”?
base-emojis is intended to sit there, as an available set, if an implementer wants to use it. It is an offer of core commonality among systems, if they want to adopt it, and encouragement that developers have a core, common set, if this isn't it.
It's similar to the Section B.1 Core Rules in the ABNF RFC
(5234). Available, but not required.
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.
Security Considerations is an opportunity with infinite possibilities. If anyone wants to supply text to add and others like it, then it should be added...
Finally, what happens if the same source sends two reactions in two separate emails? Can one send a blank message to remove a reaction?
What happens if the source provides two reactions in the /same/ email? Is that different from this? Because both are supported.
Trivial technical answer in the scope of this specification: Both are entirely legal.
Difficult usability answer, outside the scope of this specification: It will be interesting to see how and whether UI implementers support either or both of these.
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.
The 'R' construct was added here, to resolve some language ambiguity. No, it isn't elegant writing. Yes, I'd be delighted for someone to supply alternative text that is clear, accurate and more appealing.
And thank /you/ for the detailed feedback.
d/
-- Dave Crocker dcrocker@xxxxxxxxx 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@xxxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
