| 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 ;-) Eliot
|
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
