Again thanks for this draft. I definitely think it should go forward. See below for some replies.
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.
I don’t know enough to know the prevalence of the unicode emoji set and whether base-emojis are needed. I leave that to you. I would just add a few words to indicate
why you defined the set and when you would expect it be used. That’s all.
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...
Here’s what I would suggest:
An attacker may transmit one, several, or many messages that lack any form of authentication, indicating one or more reactions, thus causing the MUA to mislead the reader into believing a general sentiment to be something other than what it is, or that a specific reaction is other than what it is. The ultimate appropriate remediation is to authenticate the sender of a reaction against a trusted authority. Short of that, MUA designers are advised to consider only processing reactions that pass a heuristic test as to their likely authenticity.
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.
There are really two possibilities: reactions are additive, or reactions are replacements. I don’t see any real case for additive, and quite a number for replacements. For instance, one wants to avoid the case where the same sender is being counted as multiple +1s, as it were.
I agree that there are some interesting UI aspects to this, but I myself find that I first initially react on one common platform with a “like”, and then I get more specific, leading to two separate reactions. By having a little bit of text here, one can establish some common expectations.
Here’s my suggestion:
When a subsequent message containing a reaction is received from the same source regarding the same original message, it is said to have superseded the previous reaction.
Also:
A blank reaction, a reaction containing containing no “emoji” as defined in the ABNF in Section 2, is said to have cleared any previously received reaction from the source.
That way, one can change one’s mind or correct a mistake.
I think these suggestions follow the principle of least astonishment, but I readily admit I could be wrong. I recognize that this requires a reaction database to implement. Yeah, that’s a small pain. THAT to me may be the real experiment here.
Eliot
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
